aboutsummaryrefslogtreecommitdiff
path: root/files/ru/web/media
diff options
context:
space:
mode:
Diffstat (limited to 'files/ru/web/media')
-rw-r--r--files/ru/web/media/formats/codecs_parameter/index.html973
-rw-r--r--files/ru/web/media/formats/index.html88
-rw-r--r--files/ru/web/media/formats/webrtc_кодеки/index.html483
-rw-r--r--files/ru/web/media/index.html89
4 files changed, 1633 insertions, 0 deletions
diff --git a/files/ru/web/media/formats/codecs_parameter/index.html b/files/ru/web/media/formats/codecs_parameter/index.html
new file mode 100644
index 0000000000..a7eed92590
--- /dev/null
+++ b/files/ru/web/media/formats/codecs_parameter/index.html
@@ -0,0 +1,973 @@
+---
+title: Параметр "codecs" для распространенных типов носителей
+slug: Web/Media/Formats/codecs_parameter
+translation_of: Web/Media/Formats/codecs_parameter
+---
+<div>{{QuickLinksWithSubpages("/en-US/docs/Web/Media")}}</div>
+
+<div>На базовом уровне, можно задать тип медиа файла, используя простой</div>
+
+<p>{{Glossary("MIME")}} тип, такой как  <code>video/mp4</code> или <code>audio/mpeg</code>. Однако, многие медиа типы, особенно те, которые поддерживают видео дорожки, более привлекательные из-за способности более точного описания содержащегося формата данных. Например, просто описывая видео в  файле <a href="/en-US/docs/Web/Media/Formats/Containers#MP4">MPEG-4</a>  с  MIME типом <code>video/mp4</code> ничего не скажет о том, какой формат в действительности он содержит.</p>
+
+<p>По этой причине в MIME тип может быть добавлен параметр  <code>codecs</code> , описывающий медиа контент, предоставляя более подробную информацию о содержимом. Эта информация может содержать, к примеру, профиль видео кодека, или тип, используемый аудио треками, и так далее.</p>
+
+<p>В этом руководстве кратко рассматривается синтаксис параметра <code>codecs </code>мультимедийного типа и его использование со строкой, описывающей  MIME тип, для предоставления подробных сведений о содержимом аудио- или видеоматериалов, помимо простого указания типа</p>
+
+<h2 id="Общий_синтаксис">Общий синтаксис</h2>
+
+<p>Основной медиатип определяется установкой строкового значения  (<code>audio</code>, <code>video</code>, и т.д.), после которого идет символ слеша (<code>/</code>), затем указывается формат контейнера, который будет содержать информацию:</p>
+
+<dl>
+ <dt><code>audio/mpeg</code></dt>
+ <dd>Аудио файл, использующий тип файла <a href="/en-US/docs/Web/Media/Formats/Containers#MPEG">MPEG</a> , к примеру, MP3.</dd>
+ <dt><code>video/ogg</code></dt>
+ <dd>Видео файл, использующий тип файла  <a href="/en-US/docs/Web/Media/Formats/Containers#Ogg">Ogg</a>.</dd>
+ <dt><code>video/mp4</code></dt>
+ <dd>Видео файл, использующий тип файла  <a href="/en-US/docs/Web/Media/Formats/Containers#MP4">MPEG-4</a>.</dd>
+ <dt><code>video/quicktime</code></dt>
+ <dd>Видео файл, Apple формата <a href="/en-US/docs/Web/Media/Formats/Containers#QuickTime">QuickTime</a>. Как уже отмечалось, этот формат обычно  используется в Сети, поскольку требует использования плпгинов.</dd>
+</dl>
+
+<p>Однако эти MIME являются не прозрачными. Все эти типы поддерживают несколько кодеков, и эти кодеки могут содержать несколько профилей, уровней , и других факторов конфигурирования. По этой причине указывается строковый параметр медиа типа <code>codecs</code>.</p>
+
+<p>Для его добавления, перед ним ставиться точка с запятой (<code>;</code>) , за которой следует строка  <code>codecs=</code> , в значении указывается формат содержимого файла. Некоторые типы носителей позволяют указывать только имена используемых кодеков, в то время как другие позволяют также указывать различные ограничения для этих кодеков. Вы можете указать несколько кодеков, разделяя их запятыми.</p>
+
+<dl>
+ <dt><code>audio/ogg; codecs=vorbis</code></dt>
+ <dd>Файл <a href="/en-US/docs/Web/Media/Formats/Containers#Ogg">Ogg</a> содержит  <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Vorbis">Vorbis</a> аудио трек.</dd>
+ <dt><code>video/webm; codecs="vp8, vorbis"</code></dt>
+ <dd>Файл <a href="/en-US/docs/Web/Media/Formats/Containers#WebM">WebM</a> , содержащий <a href="/en-US/docs/Web/Media/Formats/Video_codecs#VP8">VP8</a> видео и/или <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Vorbis">Vorbis</a> аудио.</dd>
+ <dt><code>video/mp4; codecs="avc1.4d002a"</code></dt>
+ <dd>Файл <a href="/en-US/docs/Web/Media/Formats/Containers#MP4">MPEG-4</a> , содержащий  <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">AVC</a> (H.264) видео, Основной профиль, Уровень 4.2.</dd>
+</dl>
+
+<p>Как и вслучае с  любым параметром MIME типа , <code>codecs</code> должен заменяться на <code>codecs*</code> (обратите внимание на символ звездочки, <code>*</code>) , если какое-либо из свойств кодека использует специальные символы для указания допонительной информации (языковые отметки, кодировка байтов в шестнадцатиричные значения и т.д.), входящие в {{RFC(2231, "MIME Parameter Value and Encoded Word Extensions", 4)}}. Можно использовать функции JavaScript {{jsxref("Global_Objects/encodeURI", "encodeURI()")}} для кодирования списка параметров, можно использовать   {{jsxref("Global_Objects/decodeURI", "decodeURI()")}} для декодирования предварительно закодированного списка параметров.</p>
+
+<div class="blockIndicator note">
+<p> Когда используется параметр <code>codecs</code>, указанный список кодеков должен включать каждый кодек, используемый для содержимого файлаю Список также может содержать кодеки, которых нет в файле.</p>
+</div>
+
+<h2 id="Свойства_кодеков_для_контейнеров">Свойства кодеков для контейнеров</h2>
+
+<p>Контейнеры ниже поддерживают расширенные свойства кодеков в своих параметрах <code>codecs</code> :</p>
+
+<div class="index">
+<ul>
+ <li>{{anch("ISO-BMFF", "3GP")}}</li>
+ <li>{{anch("AV1")}}</li>
+ <li>{{anch("ISO-BMFF", "ISO BMFF")}}</li>
+ <li>{{anch("ISO-BMFF", "MPEG-4")}}</li>
+ <li>{{anch("ISO-BMFF", "QuickTime")}}</li>
+ <li>{{anch("WebM")}}</li>
+</ul>
+</div>
+
+<p>Несколько ссылок выше входят в одину и то же секцию, потому, что все медиатипы основаны на файловом формате  ISO Base Media File Format (ISO BMFF), поэтому они  используют тот же синикаксис.</p>
+
+<h3 id="AV1">AV1</h3>
+
+<p>Синтаксис параметра <code>codecs</code> для AV1 определяется спецификацией <a href="https://aomediacodec.github.io/av1-isobmff">AV1 Codec ISO Media File Format Binding</a> , секция 5: <a href="https://aomediacodec.github.io/av1-isobmff/#codecsparam">Строки параметра codecs </a>.</p>
+
+<pre>av01.P.LLT.DD[.M[.CCC[.cp[.tc[.mc[.F]]]]]]</pre>
+
+<p>Компоненты строковых параметров кодеков описываются более подробно в таблице ниже. Каждый компонент имеет фиксированное количество символов, и если значение меньше этой длины, оно должно быть дополнено начальными нулями.</p>
+
+<table class="standard-table">
+ <caption>AV1 компоненты строковых параметров кодека</caption>
+ <thead>
+ <tr>
+ <th scope="col">Компонент</th>
+ <th scope="col">Описание</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>P</code></td>
+ <td>
+ <p>Однознаковый номер профиля:</p>
+
+ <table class="standard-table">
+ <caption>AV1 номера профилей</caption>
+ <thead>
+ <tr>
+ <th scope="col">Номер профиля</th>
+ <th scope="col">Описание</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>"Основной" профиль; поддерживает  YUV 4:2:0 или одноцветный поток битов с глубиной  8 или 10 бит на компонент.</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>"Высокий" профиль добавляет поддержку выбора цветности  4:4:4.</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>"Профессиональный" профиль добавляет поддержку выбора цветности 4:2:2 и 12 бит на один цвет компонента.</td>
+ </tr>
+ </tbody>
+ </table>
+ </td>
+ </tr>
+ <tr>
+ <td><code>LL</code></td>
+ <td>Двухзначный номер уровня, который преобразуется в формат X.Y, где<code>X = 2 + (LL &gt;&gt; 2)</code> , и  <code>Y = LL &amp; 3</code>. Подробнее <a href="https://aomediacodec.github.io/av1-spec/#levels">Дополнение A, секция 3</a> в спецификации  AV1 .</td>
+ </tr>
+ <tr>
+ <td><code>T</code></td>
+ <td>The one-character tier indicator. For the Main tier (<code>seq_tier</code> equals 0), this character is the letter <code>M</code>. For the High tier (<code>seq_tier</code> is 1), this character is the letter <code>H</code>. The High tier is only available for level 4.0 and up.</td>
+ </tr>
+ <tr>
+ <td><code>DD</code></td>
+ <td>The two-digit component bit depth. This value must be one of 8, 10, or 12; which values are valid varies depending on the profile and other properties.</td>
+ </tr>
+ <tr>
+ <td><code>M</code></td>
+ <td>The one-digit monochrome flag; if this is 0, the video includes the U and V planes in addition to the Y plane. Otherwise, the video data is entirely in the Y plane and is therefore monochromatic. See {{SectionOnPage("/en-US/docs/Web/Media/Formats/Video_concepts", "YUV")}} for details on how the YUV color system works. The default value is 0 (not monochrome).</td>
+ </tr>
+ <tr>
+ <td><code>CCC</code></td>
+ <td>
+ <p><code>CCC</code> indicates the chroma subsampling as three digits. The first digit is <code>subsampling_x</code>, the second is <code>subsampling_y</code>. If both of those are 1, the third is the value of <code>chroma_sample_position</code>; otherwise, the third digit is always 0. This, combined with the <code>M</code> component, can be used to construct the chroma subsampling format:</p>
+
+ <table class="standard-table">
+ <caption>Determining the chroma subsampling format</caption>
+ <thead>
+ <tr>
+ <th scope="col">subsampling_x</th>
+ <th scope="col">subsampling_y</th>
+ <th scope="col">Monochrome flag</th>
+ <th scope="col">Chroma subsampling format</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>0</td>
+ <td>0</td>
+ <td>YUV 4:4:4</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>0</td>
+ <td>0</td>
+ <td>YUV 4:2:2</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1</td>
+ <td>0</td>
+ <td>YUV 4:2:0</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1</td>
+ <td>1</td>
+ <td>YUV 4:0:0 (Monochrome)</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>The third digit in <code>CCC</code> indicates the chroma sample position, with a value of 0 indicating that the position is unknown and must be separately provided during decoding; a value of 1 indicating that the sample position is horizontally colocated with the (0, 0) luma sample; and a value of 2 indicating that the sample position is colocated with (0, 0) luma.</p>
+
+ <p>The default value is <code>110</code> (4:2:0 chroma subsampling).</p>
+ </td>
+ </tr>
+ <tr>
+ <td><code>cp</code></td>
+ <td>The two-digit <code>color_primaries</code> value indicates the color system used by the media. For example, BT.2020/BT.2100 color, as used for HDR video, is <code>09</code>. The information for this—and for each of the remaining components—is found in the <a href="https://aomediacodec.github.io/av1-spec/#color-config-semantics">Color config semantics section</a> of the AV1 specification. The default value is <code>01</code> (ITU-R BT.709).</td>
+ </tr>
+ <tr>
+ <td><code>tc</code></td>
+ <td>The two-digit <code>transfer_characteristics</code> value. This value defines the function used to map the gamma (delightfully called the "opto-electrical transfer function" in technical parlance) from the source to the display. For example, 10-bit BT.2020 is <code>14</code>. The default value is <code>01</code> (ITU-R BT.709).</td>
+ </tr>
+ <tr>
+ <td><code>mc</code></td>
+ <td>The two-digit <code>matrix_coefficients</code> constant selects the matrix coefficients used to convert the red, blue, and green channels into luma and chroma signals. For example, the standard coefficients used for BT.709 are indicated using the value <code>01</code>. The default value is <code>01</code> (ITU-R BT.709).</td>
+ </tr>
+ <tr>
+ <td><code>F</code></td>
+ <td>A one-digit flag indicating whether the color should be allowed to use the full range of possible values (<code>1</code>), or should be constrained to those values considered legal for the specified color configuration (that is, the <strong>studio swing representation</strong>). The default is 0 (use the studio swing representation).</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>All fields from <code>M</code> (monochrome flag) onward are optional; you may stop including fields at any point (but can't arbitrarily leave out fields). The default values are included in the table above. Some example AV1 codec strings:</p>
+
+<dl>
+ <dt><code>av01.2.15M.10.0.100.09.16.09.0</code></dt>
+ <dd>AV1 Professional Profile, level 5.3, Main tier, 10 bits per color component, 4:2:2 chroma subsampling using ITU-R BT.2100 color primaries, transfer characteristics, and YCbCr color matrix. The studio swing representation is indicated.</dd>
+ <dt><code>av01.0.15M.10</code></dt>
+ <dd>AV1 Main Profile, level 5.3, Main tier, 10 bits per color component. The remaining properties are taken from the defaults: 4:2:0 chroma subsampling, BT.709 color primaries, transfer characteristics, and matrix coefficients. Studio swing representation.</dd>
+</dl>
+
+<h3 id="ISO_Base_Media_File_Format_MP4_QuickTime_and_3GP"><a id="ISO-BMFF" name="ISO-BMFF">ISO Base Media File Format: MP4, QuickTime, and 3GP</a></h3>
+
+<p>All media types based upon the {{interwiki("wikipedia", "ISO Base Media File Format")}} (ISO BMFF) share the same syntax for the <code>codecs</code> parameter. These media types include <a href="/en-US/docs/Web/Media/Formats/Containers#MP4">MPEG-4</a> (and, in fact, the <a href="/en-US/docs/Web/Media/Formats/Containers#QuickTime">QuickTime</a> file format upon which MPEG-4 is based) as well as <a href="/en-US/docs/Web/Media/Formats/Containers#3GP">3GP</a>. Both video and audio tracks can be described using the <code>codecs</code> parameter with the following MIME types:</p>
+
+<table class="standard-table">
+ <caption>Base MIME types supporting the ISO BMFF codecs parameter</caption>
+ <thead>
+ <tr>
+ <th scope="col">MIME type</th>
+ <th scope="col">Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>audio/3gpp</code></td>
+ <td>3GP audio ({{RFC(3839, "MIME Type Registrations for 3rd generation Partnership Project (3GP) Multimedia files")}})</td>
+ </tr>
+ <tr>
+ <td><code>video/3gpp</code></td>
+ <td>3GP video ({{RFC(3839, "MIME Type Registrations for 3rd generation Partnership Project (3GP) Multimedia files")}})</td>
+ </tr>
+ <tr>
+ <td><code>audio/3gp2</code></td>
+ <td>3GP2 audio ({{RFC(4393, "MIME Type Registrations for 3GPP2 Multimedia files")}})</td>
+ </tr>
+ <tr>
+ <td><code>video/3gp2</code></td>
+ <td>3GP2 video ({{RFC(4393, "MIME Type Registrations for 3GPP2 Multimedia files")}})</td>
+ </tr>
+ <tr>
+ <td><code>audio/mp4</code></td>
+ <td>MP4 audio ({{RFC(4337, "MIME Type Registration for MPEG-4")}})</td>
+ </tr>
+ <tr>
+ <td><code>video/mp4</code></td>
+ <td>MP4 audio ({{RFC(4337, "MIME Type Registration for MPEG-4")}})</td>
+ </tr>
+ <tr>
+ <td><code>application/mp4</code></td>
+ <td>Non-audiovisual media encapsulated in MPEG-4</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Each codec described by the <code>codecs</code> parameter can be specified either as simply the container's name (<code>3gp</code>, <code>mp4</code>, <code>quicktime</code>, etc.) or as the container name plus additional parameters to specify the codec and its configuration. Each entry in the codec list may contain some number of components, separated by periods (<code>.</code>).</p>
+
+<p>The syntax for the value of <code>codecs</code> varies by codec; however, it always starts with the codec's four-character identifier, a period separator (<code>.</code>), followed by the Object Type Indication (OTI) value for the specific data format. For most codecs, the OTI is a two-digit hexadecimal number; however, it's six hexadecimal digits for <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">AVC (H.264)</a>.</p>
+
+<p>Thus, the syntaxes for each of the supported codecs look like this:</p>
+
+<dl>
+ <dt><code>cccc[.pp]*</code> (Generic ISO BMFF)</dt>
+ <dd>Where <code>cccc</code> is the four-character ID for the codec and <code>pp</code> is where zero or more two-character encoded property values go.</dd>
+ <dt><code>mp4a.oo[.A]</code> (MPEG-4 audio)</dt>
+ <dd>Where <code>oo</code> is the Object Type Indication value describing the contents of the media more precisely and <code>A</code> is the one-digit <em>audio</em> OTI. The possible values for the OTI can be found on the MP4 Registration Authority web site's <a href="http://mp4ra.org/#/object_types">Object Types page</a>. For example, Opus audio in an MP4 file is <code>mp4a.ad</code>. For further details, see {{anch("MPEG-4 audio")}}.</dd>
+ <dt><code>mp4v.oo[.V]</code> (MPEG-4 video)</dt>
+ <dd>Here, <code>oo</code> is again the OTI describing the contents more precisely, while <code>V</code> is the one-digit <em>video</em> OTI.</dd>
+ <dt><code>avc1.oo[.PPCCLL]</code> (AVC video)</dt>
+ <dd>
+ <p><code>oo</code> is the OTI describing the contents, while <code>PPCCLL</code> is six hexadecimal digits specifying the profile number (<code>PP</code>), constraint set flags (<code>CC</code>), and level (<code>LL</code>). See {{anch("AVC profiles")}} for the possible values of <code>PP</code>.</p>
+
+ <p>The constraint set flags byte is comprised of one-bit Boolean flags, with the most significant bit being referred to as flag 0 (or <code>constraint_set0_flag</code>, in some resources), and each successive bit being numbered one higher. Currently, only flags 0 through 2 are used; the other five bits <em>must</em> be zero. The meanings of the flags vary depending on the profile being used.</p>
+
+ <p>The level is a fixed-point number, so a value of <code>14</code> (decimal 20) means level 2.0 while a value of <code>3D</code> (decimal 61) means level 6.1. Generally speaking, the higher the level number, the more bandwidth the stream will use and the higher the maximum video dimensions are supported.</p>
+ </dd>
+</dl>
+
+<h4 id="AVC_profiles">AVC profiles</h4>
+
+<p>The following are the AVC profiles and their profile numbers for use in the <code>codecs</code> parameter, as well as the value to specify for the constraints component, <code>CC</code>.</p>
+
+<table class="standard-table">
+ <caption>Specifying an AVC profiles using the profile ID and constraints components of the <code>codecs</code> parameter</caption>
+ <thead>
+ <tr>
+ <th scope="col">Profile</th>
+ <th scope="col">Number (Hex)</th>
+ <th scope="col">Constraints byte</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><strong>Constrained Baseline Profile (CBP)</strong><br>
+ CBP is primarily a solution for scenarios in which resources are constrained, or resource use needs to be controlled to minimize the odds of the media performing poorly.</td>
+ <td><code>42</code></td>
+ <td><code>40</code></td>
+ </tr>
+ <tr>
+ <td><strong>Baseline Profile (BP)</strong><br>
+ Similar to CBP but with more data loss protections and recovery capabilities. This is not as widely used as it was before CBP was introduced. All CBP streams are considered to also be BP streams.</td>
+ <td><code>42</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Extended Profile (XP)</strong><br>
+ Designed for streaming video over the network, with high compression capability and further improvements to data robustness and stream switching.</td>
+ <td><code>58</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Main Profile (MP)</strong><br>
+ The profile used for standard-definition digital television being broadcast in MPEG-4 format. <em>Not</em> used for high-definition television broadcasts. This profile's importance has faded since the introduction of the High Profile—which was added for HDTV use—in 2004.</td>
+ <td><code>4D</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>High Profile (HiP)</strong><br>
+ Currently, HiP is the primary profile used for broadcast and disc-based HD video; it's used both for HD TV broadcasts and for  Blu-Ray video.</td>
+ <td><code>64</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Progressive High Profile (PHiP)</strong><br>
+ Essentially High Profile without support for field coding.</td>
+ <td><code>64</code></td>
+ <td><code>08</code></td>
+ </tr>
+ <tr>
+ <td><strong>Constrained High Profile</strong><br>
+ PHiP, but without support for bi-predictive slices ("B-slices").</td>
+ <td><code>64</code></td>
+ <td><code>0C</code></td>
+ </tr>
+ <tr>
+ <td><strong>High 10 Profile (Hi10P)</strong><br>
+ High Profile, but with support for up to 10 bits per color component.</td>
+ <td><code>6E</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>High 4:2:2 Profile (Hi422P)</strong><br>
+ Expands upon Hi10P by adding support for 4:2:2 chroma subsampling along with up to10 bits per color component.</td>
+ <td><code>7A</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>High 4:4:4 Predictive Profile (Hi444PP)</strong><br>
+ In addition to the capabilities included in Hi422P, Hi444PP adds support for 4:4:4 chroma subsampling (in which no color information is discarded). Also includes support for up to 14 bits per color sample and efficient lossless region coding. The option to encode each frame as three separate color planes (that is, each color's data is stored as if it were a single monochrome frame).</td>
+ <td><code>F4</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>High 10 Intra Profile</strong><br>
+ High 10 constrained to all-intra-frame use. Primarily used for professional apps.</td>
+ <td><code>6E</code></td>
+ <td><code>10</code></td>
+ </tr>
+ <tr>
+ <td><strong>High 4:2:2 Intra Profile</strong><br>
+ The Hi422 Profile with all-intra-frame use.</td>
+ <td><code>7A</code></td>
+ <td><code>10</code></td>
+ </tr>
+ <tr>
+ <td><strong>High 4:4:4 Intra Profile</strong><br>
+ The High 4:4:4 Profile constrained to use only intra frames.</td>
+ <td><code>F4</code></td>
+ <td><code>10</code></td>
+ </tr>
+ <tr>
+ <td><strong>CAVLC 4:4:4 Intra Profile</strong><br>
+ The High 4:4:4 Profile constrained to all-intra use, and to using only CAVLC entropy coding.</td>
+ <td><code>44</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Scalable Baseline Profile</strong><br>
+ Intended for use with video conferencing as well as surveillance and mobile uses, the {{interwiki("wikipedia", "SVC")}} Baseline Profile is based on AVC's Constrained Baseline profile. The base layer within the stream is provided at a high quality level, with some number of secondary substreams that offer alternative forms of the same video for use in various constrained environments. These may include any combination of reduced resolution, reduced frame rate, or increased compression levels.</td>
+ <td><code>53</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Scalable Constrained Baseline Profile</strong><br>
+ Primarily used for real-time communication applications. Not yet supported by WebRTC, but an extension to the WebRTC API <a href="https://github.com/w3c/webrtc-svc">to allow SVC</a> is in development.</td>
+ <td><code>53</code></td>
+ <td><code>04</code></td>
+ </tr>
+ <tr>
+ <td><strong>Scalable High Profile</strong><br>
+ Meant mostly for use in broadcast and streaming applications. The base (or highest quality) layer must conform to the AVC High Profile.</td>
+ <td><code>56</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Scalable Constrained High Profile</strong><br>
+ A subset of the Scalable High Profile designed mainly for real-time communticions.</td>
+ <td><code>56</code></td>
+ <td><code>04</code></td>
+ </tr>
+ <tr>
+ <td><strong>Scalable High Intra Profile</strong><br>
+ Primarily useful only for production applications, this profile supports only all-intra usage.</td>
+ <td><code>56</code></td>
+ <td><code>20</code></td>
+ </tr>
+ <tr>
+ <td><strong>Stereo High Profile</strong><br>
+ The Stereo High Profile provides stereoscopic video using two renderings of the scene (left eye and right eye). Otherwise, provides the same features as the High profile.</td>
+ <td><code>80</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Multiview High Profile</strong><br>
+ Supports two or more views using both temporal and MVC inter-view prediction. <em>Does not support</em> field pictures or macroblock-adaptive frame-field coding.</td>
+ <td><code>76</code></td>
+ <td><code>00</code></td>
+ </tr>
+ <tr>
+ <td><strong>Multiview Depth High Profile</strong><br>
+ Based on the High Profile, to which the main substream must adhere. The remaining substreams must match the Stereo High Profile.</td>
+ <td><code>8A</code></td>
+ <td><code>00</code></td>
+ </tr>
+ </tbody>
+</table>
+
+<h4 id="MPEG-4_audio">MPEG-4 audio</h4>
+
+<p>When the value of an entry in the <code>codecs</code> list begins with <code>mp4a</code>, the syntax of the value should be:</p>
+
+<pre>mp4a.oo[.A]</pre>
+
+<p>Here, <code>oo</code> is the two-digit hexadecimal Object Type Indication which specifies the codec class being used for the media. The OTIs are assigned by the <a href="http://mp4ra.org/">MP4 Registration Authority</a>, which maintains a <a href="http://mp4ra.org/#/object_types">list of the possible OTI values</a>. A special value is <code>40</code>; this indicates that the media is MPEG-4 audio (ISO/IEC 14496 Part 3). In order to be more specific still, a third component—the Audio Object Type—is added for OTI <code>40</code> to narrow the type down to a specific subtype of MPEG-4.</p>
+
+<p>The Audio Object Type is specified as a one or two digit <em>decimal</em> value (unlike most other values in the <code>codecs</code> parameter, which use hexadecimal). For example, MPEG-4's AAC-LC has an audio object type number of <code>2</code>, so the full <code>codecs</code> value representing AAC-LC is <code>mp4a.40.2</code>.</p>
+
+<p>Thus, ER AAC LC, whose Audio Object Type is 17, can be represented using the full <code>codecs</code> value <code>mp4a.40.17</code>. Single digit values can be given either as one digit (which is the best choice, since it will be the most broadly compatible) or with a leading zero padding it to two digits, such as <code>mp4a.40.02</code>.</p>
+
+<div class="blockIndicator note">
+<p><strong>Note:</strong> The specification originally mandated that the Audio Object Type number in the third component be only one decimal digit. However, amendments to the specification over time extended the range of these values well beyond one decimal digit, so now the third parameter may be either one or two digits. Padding values below 10 with a leading <code>0</code> is optional. Older implementations of MPEG-4 codecs may not support two-digit values, however, so using a single digit when possible will maximize compatibility.</p>
+</div>
+
+<p>The Audio Object Types are defined in ISO/IEC 14496-3 subpart 1, section 1.5.1. The table below provides a basic list of the Audio Object Types and in the case of the more common object ypes provides a list of the profiles supporting it, but you should refer to the specification for details if you need to know more about the inner workings of any given MPEG-4 audio type.</p>
+
+<table class="standard-table">
+ <caption>MPEG-4 audio object types</caption>
+ <thead>
+ <tr>
+ <th scope="col">ID</th>
+ <th scope="col">Audio Object Type</th>
+ <th scope="col">Profile support</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>0</code></td>
+ <td>NULL</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>1</code></td>
+ <td>AAC Main</td>
+ <td>Main</td>
+ </tr>
+ <tr>
+ <td><code>2</code></td>
+ <td>AAC LC (Low Complexity)</td>
+ <td>Main, Scalable, HQ, LD v2, AAC, HE-AAC, HE-AAC v2</td>
+ </tr>
+ <tr>
+ <td><code>3</code></td>
+ <td>AAC SSR (Scalable Sampling Rate)</td>
+ <td>Main</td>
+ </tr>
+ <tr>
+ <td><code>4</code></td>
+ <td>AAC LTP (Long Term Prediction)</td>
+ <td>Main, Scalable, HQ</td>
+ </tr>
+ <tr>
+ <td><code>5</code></td>
+ <td>SBR (Spectral Band Replication)</td>
+ <td>HE-AAC, HE-AAC v2</td>
+ </tr>
+ <tr>
+ <td><code>6</code></td>
+ <td>AAC Scalable</td>
+ <td>Main, Scalable, HQ</td>
+ </tr>
+ <tr>
+ <td><code>7</code></td>
+ <td>TwinVQ (Coding for ultra-low bit rates)</td>
+ <td>Main, Scalable</td>
+ </tr>
+ <tr>
+ <td><code>8</code></td>
+ <td>CELP (Code-Excited Linear Prediction)</td>
+ <td>Main, Scalable, Speech, HQ, LD</td>
+ </tr>
+ <tr>
+ <td><code>9</code></td>
+ <td>HVXC (Harmonic Vector Excitation Coding)</td>
+ <td>Main, Scalable, Speech, LD</td>
+ </tr>
+ <tr>
+ <td><code>10</code> – <code>11</code></td>
+ <td><em>Reserved</em></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>12</code></td>
+ <td>TTSI (Text to Speech Interface)</td>
+ <td>Main, Scalable, Speech, Synthetic, LD</td>
+ </tr>
+ <tr>
+ <td><code>13</code></td>
+ <td>Main Synthetic</td>
+ <td>Main, Synthetic</td>
+ </tr>
+ <tr>
+ <td><code>14</code></td>
+ <td>Wavetable Synthesis</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>15</code></td>
+ <td>General MIDI</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>16</code></td>
+ <td>Algorithmic Synthesis and Audio Effects</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>17</code></td>
+ <td>ER AAC LC (Error Resilient AAC Low-Complexity)</td>
+ <td>HQ, Mobile Internetworking</td>
+ </tr>
+ <tr>
+ <td><code>18</code></td>
+ <td><em>Reserved</em></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>19</code></td>
+ <td>ER AAC LTP (Error Resilient AAC Long Term Prediction)</td>
+ <td>HQ</td>
+ </tr>
+ <tr>
+ <td><code>20</code></td>
+ <td>ER AAC Scalable (Error Resilient AAC Scalable)</td>
+ <td>Mobile Internetworking</td>
+ </tr>
+ <tr>
+ <td><code>21</code></td>
+ <td>ER TwinVQ (Error Resilient TwinVQ)</td>
+ <td>Mobile Internetworking</td>
+ </tr>
+ <tr>
+ <td><code>22</code></td>
+ <td>ER BSAC (Error Reslient Bit-Sliced Arithmetic Coding)</td>
+ <td>Mobile Internetworking</td>
+ </tr>
+ <tr>
+ <td><code>23</code></td>
+ <td>ER AAC LD (Error Resilient AAC Low-Delay; used for two-way communication)</td>
+ <td>LD, Mobile Internetworking</td>
+ </tr>
+ <tr>
+ <td><code>24</code></td>
+ <td>ER CELP (Error Resilient Code-Excited Linear Prediction)</td>
+ <td>HQ, LD</td>
+ </tr>
+ <tr>
+ <td><code>25</code></td>
+ <td>ER HVXC (Error Resilient Harmonic Vector Excitation Coding)</td>
+ <td>LD</td>
+ </tr>
+ <tr>
+ <td><code>26</code></td>
+ <td>ER HILN (Error Resilient Harmonic and Individual Line plus Noise)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>27</code></td>
+ <td>ER Parametric (Error Resilient Parametric)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>28</code></td>
+ <td>SSC (Sinusoidal Coding)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>29</code></td>
+ <td>PS (Parametric Stereo)</td>
+ <td>HE-AAC v2</td>
+ </tr>
+ <tr>
+ <td><code>30</code></td>
+ <td>MPEG Surround</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>31</code></td>
+ <td><em>Escape</em></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>32</code></td>
+ <td>MPEG-1 Layer-1</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>33</code></td>
+ <td>MPEG-1 Layer-2 (MP2)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>34</code></td>
+ <td>MPEG-1 Layer-3 (MP3)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>35</code></td>
+ <td>DST (Direct Stream Transfer)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>36</code></td>
+ <td>ALS (Audio Lossless)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>37</code></td>
+ <td>SLS (Scalable Lossless)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>38</code></td>
+ <td>SLS Non-core (Scalable Lossless Non-core)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>39</code></td>
+ <td>ER AAC ELD (Error Resilient AAC Enhanced Low Delay)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>40</code></td>
+ <td>SMR Simple (Symbolic Music Representation Simple)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>41</code></td>
+ <td>SMR Main (Symbolic Music Representation Main)</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>42</code></td>
+ <td><em>Reserved</em></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>43</code></td>
+ <td>SAOC (Spatial Audio Object Coding)<sup><a href="#audio-object-types-foot-1">[1]</a></sup></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>44</code></td>
+ <td>LD MPEG Surround (Low Delay MPEG Surround)<sup><a href="#audio-object-types-foot-1">[1]</a></sup></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>45</code> and up</td>
+ <td><em>Reserved</em></td>
+ <td></td>
+ </tr>
+ </tbody>
+</table>
+
+<p><a name="audio-object-types-foot-1">[1]</a> SAOC and LD MPEG Surround are defined in <a href="https://www.iso.org/standard/54838.html">ISO/IEC 14496-3:2009/Amd.2:2010(E)</a>.</p>
+
+<h3 id="WebM">WebM</h3>
+
+<p>The basic form for a WebM <code>codecs</code> parameter is to simply list one or more of the four WebM codecs by name, separated by commas. The table below shows some examples:</p>
+
+<table class="standard-table">
+ <caption>Examples of classic WebM MIME types with <code>codecs</code> parameter</caption>
+ <thead>
+ <tr>
+ <th scope="col">MIME type</th>
+ <th scope="col">Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>video/webm;codecs="vp8"</code></td>
+ <td>A WebM video with VP8 video in it; no audio is specified.</td>
+ </tr>
+ <tr>
+ <td><code>video/webm;codecs="vp9"</code></td>
+ <td>A WebM video with VP9 video in it.</td>
+ </tr>
+ <tr>
+ <td><code>audio/webm;codecs="vorbis"</code></td>
+ <td>Vorbis audio in a WebM container.</td>
+ </tr>
+ <tr>
+ <td><code>audio/webm;codecs="opus"</code></td>
+ <td>Opus audio in a WebM container.</td>
+ </tr>
+ <tr>
+ <td><code>video/webm;codecs="vp8,vorbis"</code></td>
+ <td>A WebM container with VP8 video and Vorbis audio.</td>
+ </tr>
+ <tr>
+ <td><code>video/webm;codecs="vp9,opus"</code></td>
+ <td>A WebM container with VP9 video and Opus audio.</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>The strings <code>vp8.0</code> and <code>vp9.0</code> also work, but are not recommended.</p>
+
+<h4 id="ISO_Base_Media_File_Format_syntax">ISO Base Media File Format syntax</h4>
+
+<p>As part of a move toward a standardized and powerful format for the <code>codecs</code> parameter, WebM is moving toward describing <em>video</em> content using a syntax based on that defined by the <a href="#ISO-BMFF">ISO Base Media File Format</a>. This syntax is defined in <a href="https://www.webmproject.org/vp9/mp4">VP Codec ISO Media File Format Binding</a>, in the section <a href="https://www.webmproject.org/vp9/mp4/#codecs-parameter-string">Codecs Parameter String</a>. The audio codec continues to be indicated as either <code>vorbis</code> or <code>opus</code>.</p>
+
+<p>In this format, the <code>codecs</code> parameter's value begins with a four-character code identifying the codec being used in the container, which is then followed by a series of period (<code>.</code>) separated two-digit values.</p>
+
+<pre>cccc.PP.LL.DD.CC[.cp[.tc[.mc[.FF]]]]</pre>
+
+<p>The first five components are required; everything from <code>cp</code> (color primaries) onward is optional; you can stop including components at any point from then onward. Each of these components is described in the following table. Following the table are some examples.</p>
+
+<table class="standard-table">
+ <caption>WebM codecs parameter components</caption>
+ <thead>
+ <tr>
+ <th scope="col">Component</th>
+ <th scope="col">Details</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>cccc</code></td>
+ <td>
+ <p>A four-character code indicating which indicates which of the possible codecs is being described. Potential values are:</p>
+
+ <table class="standard-table">
+ <caption>Four-character codes for WebM-supported codecs</caption>
+ <thead>
+ <tr>
+ <th scope="col">Four-character code</th>
+ <th scope="col">Codec</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>vp08</code></td>
+ <td>VP8</td>
+ </tr>
+ <tr>
+ <td><code>vp09</code></td>
+ <td>VP9</td>
+ </tr>
+ <tr>
+ <td><code>vp10</code></td>
+ <td>VP10</td>
+ </tr>
+ </tbody>
+ </table>
+ </td>
+ </tr>
+ <tr>
+ <td><code>PP</code></td>
+ <td>
+ <p>The two-digit profile number, padded with leading zeroes if necessary to be exactly two digits.</p>
+
+ <table class="standard-table">
+ <caption>WebM profile numbers</caption>
+ <thead>
+ <tr>
+ <th scope="col">Profile</th>
+ <th scope="col">Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>00</code></td>
+ <td>Only 4:2:0 (chroma subsampled both horizontally and vertically). Allows only 8 bits per color component.</td>
+ </tr>
+ <tr>
+ <td><code>01</code></td>
+ <td>All chroma subsampling formats are allowed. Allows only 8 bits per color component.</td>
+ </tr>
+ <tr>
+ <td><code>02</code></td>
+ <td>Only 4:2:0 (chroma subsampled both horizontally and vertically). Supports 8, 10, or 12 bits per color sample component.</td>
+ </tr>
+ <tr>
+ <td><code>03</code></td>
+ <td>All chroma subsampling formats are allowed. Supports 8, 10, or 12 bits per color sample component.</td>
+ </tr>
+ </tbody>
+ </table>
+ </td>
+ </tr>
+ <tr>
+ <td><code>LL</code></td>
+ <td>The two-digit level number. The level number is a fixed-point notation, where the first digit is the ones digit, and the second digit represents tenths. For example, level 3 is <code>30</code> and level 6.1 is <code>61</code>.</td>
+ </tr>
+ <tr>
+ <td><code>DD</code></td>
+ <td>The bit depth of the luma and color component values; permitted values are 8, 10, and 12.</td>
+ </tr>
+ <tr>
+ <td><code>CC</code></td>
+ <td>
+ <p>A two-digit value indicating which chroma subsampling format to use. The following table lists permitted values; see {{SectionOnPage("en-US/docs/Web/Media/Formats/Video_concepts", "Chroma subsampling")}} for additional information about this topic and others.</p>
+
+ <table class="standard-table">
+ <caption>WebM chroma subsampling identifiers</caption>
+ <thead>
+ <tr>
+ <th scope="col">Value</th>
+ <th scope="col">Chroma subsampling format</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>00</code></td>
+ <td>4:2:0 with the chroma samples sited interstitially between the pixels</td>
+ </tr>
+ <tr>
+ <td><code>01</code></td>
+ <td>4:2:0 chroma subsampling with the samples colocated with luma (0, 0)</td>
+ </tr>
+ <tr>
+ <td><code>02</code></td>
+ <td>4:2:2 chroma subsampling (4 out of each 4 horizontal pixels' luminance are used)</td>
+ </tr>
+ <tr>
+ <td><code>03</code></td>
+ <td>4:4:4 chroma subsampling (every pixel's luminance and chrominance are both retained)</td>
+ </tr>
+ <tr>
+ <td><code>04</code></td>
+ <td><em>Reserved</em></td>
+ </tr>
+ </tbody>
+ </table>
+ </td>
+ </tr>
+ <tr>
+ <td><code>cp</code></td>
+ <td>
+ <p>A two-digit integer specifying which of the color primaries from Section 8.1 of the <a href="https://www.itu.int/rec/T-REC-H.273/en">ISO/IEC 23001-8:2016</a> standard. This component, and every component after it, is optional.</p>
+
+ <p>The possible values of the color primaries component are:</p>
+
+ <table class="standard-table">
+ <caption>ISO/IEC Color primary identifiers</caption>
+ <thead>
+ <tr>
+ <th scope="col">Value</th>
+ <th scope="col">Details</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>00</code></td>
+ <td><em>Reserved for future use by ITU or ISO/IEC</em></td>
+ </tr>
+ <tr>
+ <td><code>01</code></td>
+ <td>BT.709, sRGB, sYCC. BT.709 is the standard for high definition (HD) television; sRGB is the most common color space used for computer displays. Broadcast BT.709 uses 8-bit color depth with the legal range being from 16 (black) to 235 (white).</td>
+ </tr>
+ <tr>
+ <td><code>02</code></td>
+ <td>Image characteristics are unknown, or are to be determined by the application</td>
+ </tr>
+ <tr>
+ <td><code>03</code></td>
+ <td><em>Reserved for future use by ITU or ISO/IEC</em></td>
+ </tr>
+ <tr>
+ <td><code>04</code></td>
+ <td>BT.470 System M, NTSC (standard definition television in the United States)</td>
+ </tr>
+ <tr>
+ <td><code>05</code></td>
+ <td>BT.470 System B, G; BT.601; BT.1358 625; BT.1700 625 PAL and 625 SECAM</td>
+ </tr>
+ <tr>
+ <td><code>06</code></td>
+ <td>BT.601 525; BT.1358 525 or 625; BT.1700 NTSC; SMPTE 170M. <em>Functionally identical to <code>7</code>.</em></td>
+ </tr>
+ <tr>
+ <td><code>70</code></td>
+ <td>{{Glossary("SMPTE")}} 240M (historical). <em>Functionally identical to <code>6</code>.</em></td>
+ </tr>
+ <tr>
+ <td><code>08</code></td>
+ <td>Generic film</td>
+ </tr>
+ <tr>
+ <td><code>09</code></td>
+ <td>BT.2020; BT.2100. Used for ultra-high definition (4K) High Dynamic Range (HDR) video, these have a very wide color gamut and support 10-bit and 12-bit color component depths.</td>
+ </tr>
+ <tr>
+ <td><code>10</code></td>
+ <td>SMPTE ST 428 (D-Cinema Distribution Master: Image characteristics). Defines the uncompressed image characteristics for DCDM.</td>
+ </tr>
+ <tr>
+ <td><code>11</code></td>
+ <td>SMPTE RP 431 (D-Cinema Quality: Reference projector and environment). Describes the reference projector and environment conditions that provide a consistent film presentation experience.</td>
+ </tr>
+ <tr>
+ <td><code>12</code></td>
+ <td>SMPTE EG 432 (Digital Source Processing: Color Processing for D-Cinema). Engineering guideline making color signal decoding recommendations for digital movies.</td>
+ </tr>
+ <tr>
+ <td><code>13</code> – <code>21</code></td>
+ <td><em>Reserved for future use by ITU-T or ISO/IEC</em></td>
+ </tr>
+ <tr>
+ <td><code>22</code></td>
+ <td>EBU Tech 3213-E</td>
+ </tr>
+ <tr>
+ <td><code>23</code> – <code>255</code></td>
+ <td><em>Reserved for future use by ITU-T or ISO/IEC</em></td>
+ </tr>
+ </tbody>
+ </table>
+ </td>
+ </tr>
+ <tr>
+ <td><code>tc</code></td>
+ <td>A two-digit integer indicating the <code>transferCharacteristics</code> for the video. This value is from Section 8.2 of <a href="https://www.itu.int/rec/T-REC-H.273/en">ISO/IEC 23001-8:2016</a>, and indicates the transfer characteristics to be used when adapting the decoded color to the render target.</td>
+ </tr>
+ <tr>
+ <td><code>mc</code></td>
+ <td>The two-digit value for the <code>matrixCoefficients</code> property. This value comes from the table in Section 8.3 of the <a href="https://www.itu.int/rec/T-REC-H.273/en">ISO/IEC 23001-8:2016</a> specification. This value indicates which set of coefficients to use when mapping from the native red, blue, and green primaries to the luma and chroma signals. These coefficients are in turn used with the equations found in that same section.</td>
+ </tr>
+ <tr>
+ <td><code>FF</code></td>
+ <td>Indicates whether to restrict the black level and color range of each color component to the legal range. For 8 bit color samples, the legal range is 16-235. A value of <code>00</code> indicates that these limitations should be enforced, while a value of <code>01</code> allows the full range of possible values for each component, even if the resulting color is out of bounds for the color system.</td>
+ </tr>
+ </tbody>
+</table>
+
+<h4 id="WebM_media_type_examples">WebM media type examples</h4>
+
+<dl>
+ <dt><code>video/webm;codecs="vp08.00.41.08,vorbis"</code></dt>
+ <dd>VP8 video, profile 0 level 4.1, using 8-bit YUV with 4:2:0 chroma subsampling, using BT.709 color primaries, transfer function, and matrix coefficients, with the luminance and chroma values encoded within the legal ("studio") range. The video is Vorbis.</dd>
+ <dt><code>video/webm;codecs="vp09.02.10.10.01.09.16.09.01,opus"</code></dt>
+ <dd>VP9 video, profile 2 level 1.0, with 10-bit YUV content using 4:2:0 chroma subsampling, BT.2020 primaries, ST 2084 EOTF (HDR SMPTE), BT.2020 non-constant luminance color matrix, and full-range chroma and luma encoding. The audio is in Opus format.</dd>
+</dl>
+
+<h2 id="Using_the_codecs_parameter">Using the codecs parameter</h2>
+
+<p>You can use the <code>codecs</code> parameter in a few situations. Firstly, you can use it with the {{HTMLElement("source")}} element when creating an {{HTMLElement("audio")}} or {{HTMLElement("video")}} element, in order to establish a group of options for the browser to choose from when selecting the format of the media to present to the user in the element.</p>
+
+<p>You can also use the codecs parameter when specifying a MIME media type to the {{domxref("MediaSource.isTypeSupported()")}} method; this method returns a Boolean which indicates whether or not the media is likely to work on the current device.</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Media">Web media technologies</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats">Guide to media types and formats on the web</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/Audio_codecs">Guide to audio codecs used on the web</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/Video_codecs">Guide to video codecs used on the web</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/WebRTC_codecs">Codecs used by WebRTC</a></li>
+</ul>
diff --git a/files/ru/web/media/formats/index.html b/files/ru/web/media/formats/index.html
new file mode 100644
index 0000000000..9d4f181ae7
--- /dev/null
+++ b/files/ru/web/media/formats/index.html
@@ -0,0 +1,88 @@
+---
+title: 'Media type and format guide: image, audio, and video content'
+slug: Web/Media/Formats
+tags:
+ - API
+ - Audio
+ - Codecs
+ - Containers
+ - File Types
+ - Files
+ - Filetypes
+ - Landing
+ - Media
+ - NeedsTranslation
+ - TopicStub
+ - Types
+ - Video
+ - Web
+ - formats
+translation_of: Web/Media/Formats
+---
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Media")}}</p>
+
+<p>Since nearly its beginning, the web has included support for some form of visual media presentation. Originally, these capabilities were limited, and were expanded organically, with different browsers finding their own solutions to the problems around including still and video imagery on the web. The modern web has powerful features to support the presentation and manipulation of media, with several media-related APIs supporting various types of content. Generally, the media formats supported by a browser are entirely up to the browser's creators, which can complicate the work of a web developer.</p>
+
+<p><span class="seoSummary">This guide provides an overview of the media file types, {{Glossary("codec", "codecs")}}, and algorithms that may comprise media used on the web.</span> It also provides browser support information for various combinations of these, and suggestions for prioritization of formats, as well as which formats excel at specific types of content.</p>
+
+<div class="row topicpage-table">
+<div class="section">
+<h2 class="Documentation" id="References">References</h2>
+
+<h3 id="Images">Images</h3>
+
+<dl>
+ <dt><span style="display: none;"> </span><a href="/en-US/docs/Web/Media/Formats/Image_types">Image file type and format guide</a></dt>
+ <dd>Covers support of image file types and content formats across the major web browsers, as well as providing basic information about each type: benefits, limitations, and use cases of interest to web designers and developers.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Images_for_web_designers">Image file types for web designers</a></dt>
+ <dd>Fundamental information about the various image file types that may be useful for web designers, including best practices and use cases for each type, and guidelines for choosing the right image file format for specific types of content.</dd>
+</dl>
+
+<h3 id="Media_file_types_and_codecs">Media file types and codecs</h3>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Containers">Media containers (file types)</a></dt>
+ <dd>A guide to the file types that contain media data. Some are audio-specific, while others may be used for either audio or combined audiovisual content such as movies. Includes overviews of each of the file types supported by the major web browsers, along with browser support information and supported features.</dd>
+</dl>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Audio_codecs">Web audio codec guide</a></dt>
+ <dd>A guide to the audio codecs allowed for by the common media containers, as well as by the major browsers. Includes benefits, limitations, key specifications and capabilities, and use cases. It also covers each browser's support for using the codec in given containers.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Video_codecs">Web video codec guide</a></dt>
+ <dd>This article provides basic information about the video codecs supported by the major browsers, as well as some that are not commonly supported but that you might still run into. It also covers codec capabilities, benefits, limitations, and browser support levels and restrictions.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats/codecs_parameter">The "codecs" parameter in common media types</a></dt>
+ <dd>When specifying the MIME type describing a media format, you can provide details using the <code>codecs</code> parameter as part of the type string. This guide describes the format and possible values of the <code>codecs</code> parameter for the common media types.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats/WebRTC_codecs">Codecs used by WebRTC</a></dt>
+ <dd><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC</a> doesn't use a container, but instead streams the encoded media itself from peer to peer using {{domxref("MediaStreamTrack")}} objects to represent each audio or video track. This guide discusses the codecs commonly used with WebRTC.</dd>
+</dl>
+</div>
+
+<div class="section">
+<h2 class="Documentation" id="Guides">Guides</h2>
+
+<h3 id="Concepts">Concepts</h3>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Audio_concepts">Digital audio concepts</a></dt>
+ <dd>An introduction to how audio is converted into digital form and stored for use by computers. It explains basic concepts about how audio is sampled, as well as concepts such as sample rate, audio frames, and audio compression.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Video_concepts">Digital video concepts</a></dt>
+ <dd>A guide to fundamental concepts involved with digital video as used on the web, including basics about color formats, chroma subsampling, how human perception influences video coding, and so forth.</dd>
+</dl>
+
+<h3 id="Tutorials_and_how-tos">Tutorials and how-tos</h3>
+
+<dl>
+ <dt><a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Video_and_audio_content">Learning: Video and audio content</a></dt>
+ <dd>This tutorial introduces and details the use of media on the web.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats/Support_issues">Handling media support issues in web content</a></dt>
+ <dd>In this guide, we look at how to build web content that maximizes quality or performance while providing the broadest possible compatibility, by choosing media formats wisely, and offering fallbacks and alternate formats where it would be helpful.</dd>
+</dl>
+
+<h2 id="Other_topics">Other topics</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/API/Media_Capabilities_API">Media Capabilities API</a></dt>
+ <dd>The Media Capabilities API lets you discover the encoding and decoding capabilities of the device your app or site is running on. This lets you make real-time decisions about what formats to use and when.</dd>
+</dl>
+</div>
+</div>
diff --git a/files/ru/web/media/formats/webrtc_кодеки/index.html b/files/ru/web/media/formats/webrtc_кодеки/index.html
new file mode 100644
index 0000000000..4643eb9ccd
--- /dev/null
+++ b/files/ru/web/media/formats/webrtc_кодеки/index.html
@@ -0,0 +1,483 @@
+---
+title: 'Кодеки, используемые WebRTC'
+slug: Web/Media/Formats/WebRTC_кодеки
+tags:
+ - Кодеки WebRTC
+translation_of: Web/Media/Formats/WebRTC_codecs
+---
+<div>{{QuickLinksWithSubpages("/en-US/docs/Web/Media")}}</div>
+
+<p>С <a href="/en-US/docs/Web/API/WebRTC_API">WebRTC API</a> возможно создание сайтов и приложений, позволяющих пользователям общаться в реальном времени, используя аудио и/или видео, а также передавать данные или другую информацию. Для общения, двум устройствам необходима возможность согласования использования кодеков, для каждой дорожки в потоке данных, для успешного взаимодействия и обмена медиаданными. В этом руководстве рассматриваются кодеки, которые требуются браузерам для этого, а также другие кодеки, которые поддерживаются некоторыми или всеми браузерами, поддерживающими <span class="seoSummary">WebRTC.</span></p>
+
+<h2 id="Безконтейнерные_медиаданные">Безконтейнерные медиаданные</h2>
+
+<p>WebRTC использует объект типа {{domxref("MediaStreamTrack")}} для представления каждого трека, передающегося между узлами соединения без использования контейнера или объекта типа {{domxref("MediaStream")}} , объединяющего треки. Какие кодеки моут быть в этих треках, спецификацией  WebRTC не определяется. Однако, {{RFC(7742)}} определяет, что все браузеры, поддерживающие WebRTC, должны поддерживать <a href="/en-US/docs/Web/Media/Formats/Video_codecs#VP8">VP8</a> и <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">H.264</a> ограниченный базовый профиль для видео; и {{RFC(7874)}} , определяющая, что браузеры должны поддерживать, по меньшей мере, кодеки <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Opus">Opus</a> и <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#G.711">G.711</a>  форматов PCMA и PCMU.</p>
+
+<p>Эти две спецификации определяют свойства, которые должны поддерживаться каждым кодеком, а так же определенные функции для удобства использования, к примеру, функция эхоподавления. В этом руководстве происходит обзор кодеков, поддержка которых обязательна браузерам для реализации WebRTC, а так же иные (не обязательные) кодеки, поддерживаемые отдельными или всеми браузерами,.</p>
+
+<p>Хоть сжатие всегда и необходимо при работе со средствами массовой информации в Интернете, оно имеет дополнительное значение при проведении видеоконференций, чтобы участники могли общаться без задержек и перерывов. Второстепенное значение имеет необходимость синхронизации видео и звука, чтобы движения и любая вспомогательная информация (например, слайды или проекция) были представлены одновременно с соответствующим звуком</p>
+
+<h2 id="Общие_требования_к_кодекам">Общие требования к кодекам</h2>
+
+<p>Прежде чем рассматривать возможности и требования, специфичные для кодеков, необходимо выполнить несколько общих требований, которые должны быть выполнены при любой конфигурации кодеков, используемой с WebRTC</p>
+
+<p>Если {{Glossary ("SDP")}} специально не указывает иное, веб-браузер, принимающий видеопоток WebRTC, должен иметь возможность обрабатывать видео со скоростью не менее 20 кадров в секунду при минимальном разрешении 320 пикселей в ширину и 240 пикселей в высоту. Рекомендуется, чтобы видео кодировалось с частотой кадров и размером не ниже этого, поскольку это, по сути, нижняя граница того, что WebRTC обычно должен обрабатывать.</p>
+
+<p>SDP поддерживает независимый от кодеков способ указания предпочтительных разрешений видео ({{RFC (6236)}}). Это делается путем отправки <code>a=imageattr</code> атрибута SDP для указания максимально допустимого разрешения. Однако отправителю не требуется поддерживать этот механизм, поэтому вы должны быть готовы получать носители с другим разрешением, чем вы запрашивали. Помимо этого простого запроса максимального разрешения, определенные кодеки могут предлагать дополнительные способы запроса конкретных конфигураций мультимедиа.</p>
+
+<h2 id="Поддерживаемые_видео_кодеки">Поддерживаемые видео кодеки</h2>
+
+<p>WebRTC устанавливает набор базовых кодеков, которые требуются браузерам для работы. Некоторые браузеры могут поддерживать дополнительный набор кодеков.</p>
+
+<p>Ниже приведены видеокодеки, которые требуются в любом полностью совместимом с WebRTC браузере, а также требуемые профили и браузеры, которые фактически соответствуют требованиям</p>
+
+<table class="standard-table">
+ <caption>
+ <p>Обязательные видеокодеки</p>
+ </caption>
+ <thead>
+ <tr>
+ <th scope="row">Наименование кодека</th>
+ <th scope="col">Профиль</th>
+ <th scope="col">Совместимость с браузерами</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <th scope="row">{{anch("VP8")}}</th>
+ <td>—</td>
+ <td>Chrome, Edge, Firefox, Safari (12.1+)</td>
+ </tr>
+ <tr>
+ <th scope="row">{{anch("AVC", "AVC / H.264")}}</th>
+ <td>Constrained Baseline (CB)</td>
+ <td>Chrome (52+), Edge, Firefox<sup><a href="#supported-foot-1">[1]</a></sup>, Safari</td>
+ </tr>
+ </tbody>
+</table>
+
+<p><a name="supported-foot-1">[1]</a>  Firefox для Android 68 и более поздних версий больше не поддерживает AVC (H.264). Это связано с изменением требований магазина Google Play, которые не позволяют Firefox загружать и устанавливать кодек OpenH264, необходимый для обработки H.264 в соединениях WebRTC. Смотрим подробности в <a href="https://support.mozilla.org/en-US/kb/firefox-android-openh264"> статье о SUMO</a> .</p>
+
+<p>Для получения дополнительной информации о соображениях, связанных с WebRTC для каждого кодека, см. Подразделы ниже, перейдя по ссылкам на название каждого кодека.</p>
+
+<p>Полную информацию о том, какие видеокодеки и конфигурации требуется для поддержки WebRTC, можно найти в {{RFC (7742, "Требования к обработке видео и кодекам WebRTC")}}. Стоит отметить, что RFC охватывает множество требований, связанных с видео, включая цветовые пространства (sRGB является предпочтительным, но не обязательным цветовым пространством по умолчанию), рекомендации по функциям обработки веб-камеры (автоматическая фокусировка, автоматический баланс белого, автоматический уровень освещения) и так далее.</p>
+
+<div class="blockIndicator note">
+<p><strong> Предупреждение :</strong>  Эти требования относятся к веб-браузерам и другим продуктам, полностью совместимым с WebRTC. Продукты, не относящиеся к WebRTC, которые в некоторой степени могут взаимодействовать с WebRTC, могут поддерживать или не поддерживать эти кодеки, хотя это рекомендуется в технических документах</p>
+</div>
+
+<p>В дополнение к обязательным кодекам, некоторые браузеры также поддерживают дополнительные кодеки. Они перечисленны в таблице ниже</p>
+
+<table class="standard-table">
+ <caption>
+ <p>Другие видео кодеки</p>
+ </caption>
+ <thead>
+ <tr>
+ <th scope="row">Наименование кодека</th>
+ <th scope="col">Профили</th>
+ <th scope="col">Совместимость с браузерами</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <th scope="row">VP9</th>
+ <td>—</td>
+ <td>Chrome (48+), Firefox</td>
+ </tr>
+ </tbody>
+</table>
+
+<h3 id="Кодек_VP8">Кодек VP8</h3>
+
+<p>VP8, который мы  <a href="/en-US/docs/Web/Media/Formats/Video_codecs#VP8">описывали в общем</a>  в основной статье  <a href="/en-US/docs/Web/Media/Formats/Video_codecs">руководства по сетевым видеокодекам</a>, имеет специфические требования, которым необходимо следовать при кодировании видео треков WebRTC соединения.</p>
+
+<p>По умолчанию, VP8 будет использовать квадратные пиксели (то есть, пиксели с соотношением сторон 1: 1).</p>
+
+<h4 id="Дополнительное_замечание">Дополнительное замечание</h4>
+
+<p>Формат полезной нагрузки сети для совместного использования VP8 с помощью {{Glossary("RTP")}} (например, при использовании WebRTC) описано в {{RFC(7741, "RTP Payload Format for VP8 Video")}}.</p>
+
+<h3 id="Кодек_AVC_H.264"><a id="AVC" name="AVC"> Кодек AVC / H.264</a></h3>
+
+<p>Поддержка профиля AVC Constrained Baseline (<code>CB</code>) требуется во всех полностью совместимых реализациях WebRTC. <code>CB</code> является подмножеством основного профиля и специально разработан для приложений с низкой сложностью и малой задержкой, таких как мобильное видео и видеоконференции, а также для платформ с более низкими возможностями обработки видео..</p>
+
+<p>Наш <a href="/en-US/docs/Web/Media/Formats/Video_codecs#AVC_(H.264)">обзор  AVC</a> и его функциональности найдете в основном руководстве по видиокодекам.</p>
+
+<h4 id="Требования_поддержки_специальных_параметров">Требования поддержки специальных параметров</h4>
+
+<p>AVC предлагает широкий спектр параметров для управления дополнительными значениями. Чтобы повысить надежность совместного использования мультимедиа WebRTC на нескольких платформах и в разных браузерах, необходимо, чтобы конечные точки WebRTC, поддерживающие AVC, обрабатывали определенные параметры определенным образом. Иногда это просто означает, что параметр должен (или не должен) поддерживаться. Иногда это означает, что необходимо указать конкретное значение для параметра или разрешить определенный набор значений. А иногда требования более сложны.</p>
+
+<h5 id="Полезные_но_необязательные_параметры">Полезные, но необязательные параметры</h5>
+
+<p>Эти параметры не обязаны поддерживаться конечной точкой WebRTC, и их использование также не обязательно. Их использование, некоторым образом, может улучшить пользовательское впечатление , но к использованию не обязательно. Некоторые из них довольно сложны в использовании.</p>
+
+<dl>
+ <dt><code>max-br</code></dt>
+ <dd>Если параметр определен и поддерживается , он определяет максимальную скорость передачи видеоданных в  единицах 1,000 bps (бит в секунду) для VCL и 1,200 bps (бит в секунду) для NAL. Подробности на  <a href="https://tools.ietf.org/html/rfc6184#page-47">странице 47 спецификации RFC 6184</a>.</dd>
+ <dt><code>max-cpb</code></dt>
+ <dd>Если параметр определен и поддерживается, он определяет максимальный размер буфера, кодируемых данных. Немного усложненный параметр, размер которого может варьироваться. Смотрим на <a href="https://tools.ietf.org/html/rfc6184#page-45">страницу  45 спецификации RFC 6184</a> о подробностях.</dd>
+ <dt><code>max-dpb</code></dt>
+ <dd>Определяет максимальный размер буфера  декодированных данных, выраженных в единицах  8/3 макроблоков. Подробности в спецификации <a href="https://tools.ietf.org/html/rfc6184#page-46">RFC 6184, страница 46</a>.</dd>
+ <dt><code>max-fs</code></dt>
+ <dd>Определяет максимальный размер видеокадра, выраженный в колисестве макроблоков.</dd>
+ <dt><code>max-mbps</code></dt>
+ <dd>Определяет максимальную скорость обработки макроблоков в секунду. Значение является целым числом..</dd>
+ <dt><code>max-smbps</code></dt>
+ <dd>Определяет максимальную скорость обработки статических макроблоков в секунду (используя гипотетическое предположение, что все макроблоки являются статическими макроблоками).</dd>
+</dl>
+
+<h5 id="Пареметры_с_определенными_требованиями">Пареметры с определенными требованиями</h5>
+
+<p>Эти параметры являются необязательными, но имеют специальные требования при их использовании.</p>
+
+<dl>
+ <dt><code>packetization-mode</code></dt>
+ <dd>Все конечные точки обязательны для поддержания режима  1 (не чередующийся режим). Поддержка иных режимов пакетизации не обязательна, и сам параметр не обязателен для определения.</dd>
+ <dt><code>sprop-parameter-sets</code></dt>
+ <dd>Информация о последовательности и изображении для AVC может передаваться как внутри канала, так и вне его. При использовании AVC  с WebRTC, информация должна передаваться в канале, поэтому значение параметра не включается в SDP.</dd>
+</dl>
+
+<h5 id="Обязательные_для_определения_параметры">Обязательные для определения параметры</h5>
+
+<p>Эти параметры обязательны к определению, при использовании AVC в WebRTC соединении.</p>
+
+<dl>
+ <dt><code>profile-level-id</code></dt>
+</dl>
+
+<p>Все реализации WebRTC обязательно определяют и передают  в своих  SDP, определяя суб  - профиль используемого кодека (подмножество инструментов кодирования, которые могут быть использованы для генерации потока или того, что поддерживает получатель) и уровня потока по умолчанию, или уровня поддержки получателя.</p>
+
+<p> Конкретное значение разработчику не известно, используется одно на всех, и устанавливается  WebRTC. Начиная с {{RFC(6184)}} ("RTP Payload Format for H.264 Video"), наличие <code>profile-level-id</code> необязательно.</p>
+
+<h4 id="Прочие_требования">Прочие требования</h4>
+
+<p>В целях поддержки переключения между книжной и альбомной ориентацией можно использовать два метода. Первый - это расширение заголовка видеоориентации (CVO) для протокола RTP. Однако, если это не сигнализируется как поддерживаемое в SDP, тогда рекомендуется, чтобы браузеры поддерживали сообщения Display Orientation SEI, хотя и не обязательно</p>
+
+<p>Если не указано иное, соотношение сторон пикселя составляет 1: 1, что указывает на то, что пиксели являются квадратными</p>
+
+<h4 id="Прочие_замечания">Прочие замечания</h4>
+
+<p>Формат полезной нагрузки, используемый для AVC в WebRTC, описан в {{RFC(6184, "RTP Payload Format for H.264 Video")}}. Реализации AVC для WebRTC необходимы для поддержки специальных сообщений SEI :  «заполнитель нагрузки» и «полное замораживание кадра», они используются для плавного переключения между несколькими входными потоками.</p>
+
+<h2 id="Поддерживаемые_аудио_кодеки">Поддерживаемые аудио кодеки</h2>
+
+<p>Спецификация  {{RFC(7874)}} предписывает всем браузерам поддержку аудиокодеков, перечисленных в таблице :</p>
+
+<table class="standard-table">
+ <caption>
+ <p>Обязательные аудиокодеки</p>
+ </caption>
+ <thead>
+ <tr>
+ <th scope="row">Наименование кодека</th>
+ <th scope="col">Совместимость с браузерами</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <th scope="row"><a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Opus">Opus</a></th>
+ <td>Edge, Firefox, Safari</td>
+ </tr>
+ <tr>
+ <th scope="row"><a href="/en-US/docs/Web/Media/Formats/Audio_codecs#G.711">G.711 PCM (A-law)</a></th>
+ <td>Chrome, Firefox, Safari</td>
+ </tr>
+ <tr>
+ <th scope="row"><a href="/en-US/docs/Web/Media/Formats/Audio_codecs#G.711">G.711 PCM (µ-law)</a></th>
+ <td>Chrome, Firefox, Safari</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Более подробное обсуждение использования кодеков в WebRTC следует ниже.</p>
+
+<p>Спецификация  {{RFC(7874)}} определяет список аудио кодеков, которые браузеры, реализующие WebRTC обязаны поддерживать; так же предоставляются рекомендации и требования для специфических аудио функциональностей, таких как удаление эхоподавление, шумоподавление и выравнивание звука.</p>
+
+<div class="blockIndicator note">
+<p><strong> Примечание :</strong>  Список выше указывает на минимальный набор кодеков, который требуется реализовать браузерам (браузерному окружению), поддерживающих  WebRTC. Такие браузеры могут поддерживать также и другие кодеки, что подвергает риску межплатформенной совместимости при использовании этих кодеков без проверки гарантированной работоспособности в часто используемых браузерах.</p>
+</div>
+
+<p>В дополнение к обязательным видеокодекам, некоторые браузеры поддерживают дополнительные кодеки, перечисленные в таблице:</p>
+
+<table class="standard-table">
+ <caption>Дополнительные аудио кодеки</caption>
+ <thead>
+ <tr>
+ <th scope="row">Наименование кодека</th>
+ <th scope="col">Совместимость с браузерами</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <th scope="row">G.722</th>
+ <td>Chrome, Firefox, Safari</td>
+ </tr>
+ <tr>
+ <th scope="row">iLBC<sup><a href="#other-audio-foot-1">[1]</a></sup></th>
+ <td>Chrome, Safari</td>
+ </tr>
+ <tr>
+ <th scope="row">iSAC<sup><a href="#other-audio-foot-2">[2]</a></sup></th>
+ <td>Chrome, Safari</td>
+ </tr>
+ </tbody>
+</table>
+
+<p><a id="other-audio-foot-1" name="other-audio-foot-1">[1]</a> <strong>{{interwiki("wikipedia", "Internet Low Bitrate Codec")}}</strong> (<strong>iLBC</strong>)  - узкополосный кодек с открытым кодом, разработанный Global IP Solutions и Google, спроектированный для потокового голосового аудио. Google и другие разработчики браузеров адоптировали его для работы с  WebRTC, но он доступен не во всех браузерах, и не является обязательно поддерживаемым кодеком.</p>
+
+<p><a id="other-audio-foot-2" name="other-audio-foot-2">[2]</a> The <strong>{{interwiki("wikipedia", "Internet Speech Audio Codec")}}</strong> (<strong>iSAC</strong>)  -  другой кодек, разработанный Global IP Solutions, теперь принадлежащий Google, открывший его код. Используется Google Talk, QQ, и другими клиентами быстрых сообщений, специально спроектированный для голосовых сообщений, упакованных в поток RTP. Пока не является обязатено поддерживаемым кодеком. Поддерживается Safari и Chrome. Не поддерживается Firefox и Edge.</p>
+
+<p><strong>{{interwiki("wikipedia", "Comfort noise")}}</strong> (<strong>CN</strong>) - комфортный шум. Является формой искусственного фонового шума, использующегося для заполнения пробелов в передаче, вместо использования полной тишины. Помогает избежать вибрационных эффектов, возникающих, когда голосовая активация или подобная функциональность  вызывает временное простановление потока, известная как прерывистая передача (Discontinuous Transmission (DTX)). В спецификации {{RFC(3389)}}, метод предлагает использовать определенное заполнение в беззвучных промежутках.</p>
+
+<p>Комфортный шум используется с G.711 и может потенциально использоваться с другими кодеками, которые не имеют встроенной функции CN. Кодек Opus, к примеру, имеет собственную реализацию CN, поэтому использование RFC 3389 CN с кодеком Opus не рекомендуется.</p>
+
+<p>Отправитель звука никогда не должен использовать прерывистую передачу или комфортный шум.</p>
+
+<h3 id="Кодек_Opus">Кодек Opus</h3>
+
+<p>Формат Opus, определенный в {{RFC (6716)}}), является основным форматом для аудио в WebRTC. Формат полезной нагрузки RTP для Opus находится в {{RFC (7587)}}. Можете найти подробную информацию об Opus и его возможностях, а также о том, как другие API могут поддерживать Opus, в <a href="/en-US/docs/Web/Media/Formats/Audio_codecs#Opus">соответствующей секции</a>  нашего <a href="/en-US/docs/Web/Media/Formats/Audio_codecs">руководства по аудиокодекам, использующимся в web</a>.</p>
+
+<p>Должны поддерживаться оба режима : речь и обычное аудио. Масштабируемость и гибкость Opus полезна при работе с аудио, имеющим различную степень сложности. Поддержка внутриполосных стереосигналов позволяет поддерживать стереозвук без усложнения процесса демультиплексирования.</p>
+
+<p>Весь диапазон битрейтов, поддерживаемых Opus (от 6 кбит / с до 510 кбит / с), поддерживается в WebRTC, причем скорость битов можно динамически изменять. Более высокие битовые скорости передачи обычно улучшают качество..</p>
+
+<h4 id="Рекомендации_по_скорости_передачи_данных_bit_rate">Рекомендации по скорости передачи данных (bit rate)</h4>
+
+<p>При условии размер кадра в 20 миллисекунд, в следующей таблице приведены рекомендуемые скорости передачи данных для различных типов носителей.</p>
+
+<table class="standard-table">
+ <thead>
+ <tr>
+ <th scope="col">Медиа носитель</th>
+ <th scope="col">Рекомендованный диапазон bit rate</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Узкополосная речь (NB)</td>
+ <td>8 - 12 kbps</td>
+ </tr>
+ <tr>
+ <td>Широкополосная речь (WB)</td>
+ <td>16 - 20 kbps</td>
+ </tr>
+ <tr>
+ <td>Полноценная речь (FB)</td>
+ <td>28 - 40 kbps</td>
+ </tr>
+ <tr>
+ <td>Монофоническая музыка (FB mono)</td>
+ <td>48 - 64 kbps</td>
+ </tr>
+ <tr>
+ <td>Стереофоническая музыка (FB stereo)</td>
+ <td>64 - 128 kbps</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Скорость передачи может быть скорректирована в любое время. Во избежание перегрузки сети средняя скорость передачи звука не должна превышать доступную пропускную способность сети (за вычетом любых других известных или ожидаемых дополнительных требований к пропускной способности).</p>
+
+<h3 id="Кодек_G.711">Кодек G.711</h3>
+
+<p>G.711 определяет формат для звука с импульсной кодовой модуляцией (PCM) в виде серии 8-битных целочисленных выборок, взятых с частотой дискретизации 8000 Гц, что дает скорость передачи данных 64 кбит / с. И в {{interwiki("wikipedia", "M-law", "µ-law")}} , и в {{interwiki("wikipedia", "A-law")}} разрешена кодировка.</p>
+
+<p>G.711 <a href="https://www.itu.int/rec/T-REC-G.711-198811-I/en">определяется ITU</a>  , а его формат нагрузки в {{RFC(3551, "4.5.14")}}.</p>
+
+<p>WebRTC требует, чтобы G.711 использовал 8-битные выборки со стандартной скоростью 64 кбит / с, хотя G.711 поддерживает некоторые другие варианты. WebRTC не предписывает использовать ни G.711.0 (сжатие без потерь), G.711.1 (широкополосная возможность), ни какие-либо другие расширения стандарта G.711</p>
+
+<p>Из-за низкой частоты дискретизации и размера выборки качество звука G.711 в целом считается низким по современным стандартам, хотя оно примерно эквивалентно звучанию стационарного телефона. Обычно он используется в качестве наименьшего общего знаменателя, чтобы гарантировать, что браузеры могут установить аудио-соединение независимо от платформ и браузеров, или как запасной вариант в целом.</p>
+
+<h2 id="Определение_и_конфигурирование_кодеков">Определение и конфигурирование кодеков</h2>
+
+<h3 id="Получение_поддерживаемых_кодеков">Получение поддерживаемых кодеков</h3>
+
+<p>Поскольку браузер и платформа могут иметь различную доступность среди потенциальных кодеков - и могут иметь несколько профилей или уровней, поддерживаемых для данного кодека - первый шаг при настройке кодеков для объекта типа {{domxref("RTCPeerConnection")}}  - получить список доступных кодеков. Для этого сначала нужно инициализировать объект соединения, который получит список.</p>
+
+<p>Существует два способа для выполнения этого. Наиболее эффективный - использовать статический метод {{domxref("RTCRtpSender.getCapabilities()")}} (или эквивалентный для принимающего узла {{domxref("RTCRtpReceiver.getCapabilities()")}} ), определяющий тип медиаданных в параметре. К примеру, для определения поддерживаемых кодеков видео применяем :</p>
+
+<pre class="brush: js notranslate">codecList = RTCRtpSender.getCapabilities("video").codecs;</pre>
+
+<p>Теперь массив <code>codecList</code> содержит объекты {{domxref("RTCRtpCodecCapability")}} , каждый содержащий описываемую конфигурацию кодека. Также в списке будут присутствовать записи для повторной передачи (RTX), избыточного кодирования (RED) и прямого исправления ошибок (FEC).</p>
+
+<p>Если соединение находится в процессе запуска, используем событие {{domxref("RTCPeerConnection.icegatheringstatechange_event", "icegatheringstatechange")}}  для наблюдения за изменением статуса сборки кандидатов  {{Glossary("ICE")}} и при завершении, запрашиваем список кодеков.</p>
+
+<pre class="brush: js notranslate">let codecList = null;
+
+peerConnection.addEventListener("icegatheringstatechange", (event) =&gt; {
+ if (peerConnection.iceGatheringState === "complete") {
+ const senders = peerConnection.getSenders();
+
+ senders.forEach((sender) =&gt; {
+ if (sender.track.kind === "video") {
+ codecList = sender.getParameters().codecs;
+ return;
+ }
+ });
+ }
+
+ codecList = null;
+});</pre>
+
+<p>Обработчик события <code>icegatheringstatechange</code> установлен; в нем мы отслеживаем тип события <code>complete</code> завершения сборки кандидатов ICE, указывающее что сборка кандидатов завершена. Метод {{domxref("RTCPeerConnection.getSenders()")}} вызывается для получения списка всех объектов {{domxref("RTCRtpSender")}} , использующихся в соединении.</p>
+
+<p>Имея это в виду, мы просматриваем список отправителей и ищем первого, чей {{domxref ("MediaStreamTrack")}} указывает, что тип {{domxref ("MediaStreamTrack.track", "track")}} в своем свойстве  {{domxref("MediaStreamTrack.kind", "kind")}} содержит значение <code>video</code>, указывающее, что данные являються видеоданными. Затем вызывается метод отправителя  {{domxref("RTCRtpSender.getParameters", "getParameters()")}} , и значением свойства  {{domxref("RTCRtpParameters.codecs", "codecs")}} возвращаемого объекта {{domxref("RTCRtpSendParameters")}} , инициализируем переменную <code>codecList</code>.</p>
+
+<p>Если видеотрек не найден, устанавливаем  <code>codecList</code> в <code>null</code>.</p>
+
+<p>При возврате, <code>codecList </code>либо  <code>null</code> , указывающий на то, что видеодорожки не были найдены, либо это массив {{domxref ("RTCRtpCodecParameters")}} объектов, каждый из которых описывает одну разрешенную конфигурацию кодека. Особое значение в этих объектах имеет свойство {{domxref ("RTCRtpCodecParameters.payloadType", "payloadType")}}, которое является однобайтовым значением, однозначно идентифицирующим описанную конфигурацию.</p>
+
+<div class="blockIndicator note">
+<p><strong>Примечание :</strong>  Два метода получения списков кодеков, показанные здесь, используют разные типы вывода в своих списках кодеков. Помните об этом при использовании результатов</p>
+</div>
+
+<h3 id="Настройка_списка_кодеков">Настройка списка кодеков</h3>
+
+<p>Как только получен список доступных кодеков, его можно изменить и передать этот пересмотренный список методу  {{domxref("RTCRtpTransceiver.setCodecPreferences()")}} для перенастройки списка, используемых кодеков. Это изменяет порядок предпочтений кодеков, позволяя указать WebRTC на более предпочтительный кодек среди прочих .</p>
+
+<pre class="brush: js notranslate">function changeVideoCodec(mimeType) {
+ const transceivers = peerConnection.getTransceivers();
+
+ transceivers.forEach(transceiver =&gt; {
+ const kind = transceiver.sender.track.kind;
+ let sendCodecs = RTCRtpSender.getCapabilities(kind).codecs;
+ let recvCodecs = RTCRtpReceiver.getCapabilities(kind).codecs;
+
+ if (kind === "video") {
+ sendCodecs = preferCodec(mimeType);
+ recvCodecs = preferCodec(mimeType);
+ transceiver.setCodecPreferences([...sendCodecs, ...recvCodecs]);
+ }
+ });
+
+ peerConnection.onnegotiationneeded();
+}
+</pre>
+
+<p>В этом примере функция  <code>changeVideoCodec()</code> принимает в параметр MIME тип предпочтительного к использованию кодека. Код начинается с получения списка объектов приемо-передатчиков объекта соединения {{domxref("RTCPeerConnection")}}.</p>
+
+<p>Затем, для каждого приемо-передатчика анализируем тип медиа свойства {{domxref("RTCRtpSender")}}'s track's {{domxref("MediaStreamTrack.kind", "kind")}}. Так же получаем список поддерживаемых браузером кодеков стороны отправки и получения  <code>video</code>, используя статический метод <code>getCapabilities()</code> обоих классов {{domxref("RTCRtpSender")}} и {{domxref("RTCRtpReceiver")}}.</p>
+
+<p>Если тип медиаданных является типом  <code>video</code>, вызываем метод <code>preferCodec()</code> для обоих взаимодействующих сторон списков кодеков, который реорганизует список кодеков необходимым образом  (смотри ниже).</p>
+
+<p>И наконец, вызываем метод {{domxref("RTCRtpTransceiver.setCodecPreferences", "setCodecPreferences()")}} объекта  {{domxref("RTCRtpTransceiver")}} для определения того, что использование кодеков обеих сторон разрешено, в указанном порядке.</p>
+
+<p>Это выполняется для каждого объекта приемо-передатчика объекта соединения  <code>RTCPeerConnection</code>; как только все приемо-передатчики обновили списки предпочитаемых кодеков, вызывается обработчик события  {{domxref("RTCPeerConnection.onnegotiationneeded", "onnegotiationneeded")}} , который создает новый объект предложения, обновляет объект локального описания сессии, отправляет предложение удаленному узлу, и так далее, запуская согласование соединения .</p>
+
+<p>Функция <code>preferCodec()</code> вызываемая приведенным выше кодом, действует так, чтобы переместить указанный кодек в верхнюю часть списка (для приоритета во время согласования):</p>
+
+<pre class="brush: js notranslate">function preferCodec(codecs, mimeType) {
+ let otherCodecs = [];
+ let sortedCodecs = [];
+ let count = codecs.length;
+
+ codecs.forEach(codec =&gt; {
+ if (codec.mimeType === mimeType) {
+ sortedCodecs.push(codec);
+ } else {
+ otherCodecs.push(codec);
+ }
+ });
+
+ return sortedCodecs.concat(otherCodecs);
+}</pre>
+
+<p>Этот код просто разбивает список кодеков на два массива: один, содержащий кодеки, чей  MIME тип совпадает с тем, который указан в параметре <code>mimeType</code> , другой же содержит остальные кодеки. Как только список разделен, они объединяются вместе с записями, соответствующими заданному <code>mimeType</code> следующими вначале, за которыми следуют остальные записи кодеков. Затем этот список возвращается вызывающему коду.</p>
+
+<h2 id="Кодеки_по_умолчанию">Кодеки по умолчанию</h2>
+
+<p>Если не определенно иное, кодеки по умолчанию (предпочтительные кодеки), запрашиваемые браузерными реализациями  WebRTC, перечислены ниже</p>
+
+<table class="standard-table">
+ <caption>
+ <p>Предпочтительные для  WebRTC кодеки основных вебрбаузеров</p>
+ </caption>
+ <thead>
+ <tr>
+ <th scope="col"></th>
+ <th scope="col">Audio</th>
+ <th scope="col">Video</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <th scope="row">Chrome</th>
+ <td></td>
+ <td></td>
+ </tr>
+ <tr>
+ <th scope="row">Edge</th>
+ <td></td>
+ <td></td>
+ </tr>
+ <tr>
+ <th scope="row">Firefox</th>
+ <td></td>
+ <td>VP9 (Firefox 46 and later)<br>
+ VP8</td>
+ </tr>
+ <tr>
+ <th scope="row">Opera</th>
+ <td></td>
+ <td></td>
+ </tr>
+ <tr>
+ <th scope="row">Safari</th>
+ <td></td>
+ <td></td>
+ </tr>
+ </tbody>
+</table>
+
+<h2 id="Правильный_выбор_кодеков">Правильный выбор кодеков</h2>
+
+<p>Перед выбором кодека, который не является обязательным (VP8 или AVC для видео и  Opus или PCM для аудио), следует серьезно рассмотреть потенциальные недостатки: в особенности, если предпологается, что эти кодеки не широко доступны на всех устройствах, поддерживающих WebRTC.</p>
+
+<p>Если вы предпочитаете кодек, отличный от обязательных, вы должны по крайней мере разрешить откат к одному из обязательных кодеков, если поддержка для кодека, который вы предпочитаете, окажется недоступна.</p>
+
+<h3 id="Аудио">Аудио</h3>
+
+<p>В целом, если кодек доступен и звук, который вы хотите отправить, имеет частоту дискретизации более 8 кГц, вам следует настоятельно рекомендовать использовать Opus в качестве основного кодека. Для голосовых соединений в стесненной среде использование G.711 с частотой дискретизации 8 кГц может обеспечить приемлемое качество для разговора, но обычно вы будете использовать G.711 в качестве запасного варианта, поскольку есть другие более эффективные варианты, чей звук лутше, такие как Опус в своем узкополосном режиме .</p>
+
+<h3 id="Видео">Видео</h3>
+
+<p>При выборе поддерживаемого видеокодека (или набора кодеков) необходимо учитывать ряд факторов</p>
+
+<h4 id="Условия_лицензирования">Условия лицензирования</h4>
+
+<p>Прежде чем выбрать видеокодек, убедитесь, что вы знаете о любых лицензионных требованиях к выбранному вами кодеку; можете найти информацию о возможных проблемах лицензирования в нашем основном <a href="/en-US/docs/Web/Media/Formats/Video_codecs">руководстве по видеокодекам, используемым в  web</a>. Из двух обязательных кодеков для видео - VP8 и AVC / H.264 - только VP8 полностью свободен от лицензионных требований. Если выбираете AVC, убедитесь, что вы знаете о любых возможных сборах, которые вам, возможно, придется заплатить; владельцы патентов обычно говорят, что большинству типичных разработчиков веб-сайтов не нужно беспокоиться об оплате лицензионных сборов, которые, как правило, больше ориентированы на разработчиков программного обеспечения для кодирования и декодирования.</p>
+
+<div class="blockIndicator warning">
+<p><strong>Внимание :</strong>  Информация здесь не является юридической консультацией! Обязательно убедитесь в возможности ответственности, прежде чем принимать какие-либо окончательные решения, если существует вероятность возникновения проблем с лицензированием.</p>
+</div>
+
+<h4 id="Энергопотребление_и_срок_службы_батареи">Энергопотребление и срок службы батареи</h4>
+
+<p>Еще один фактор, который следует учитывать, особенно на мобильных платформах, - это влияние кодека на время автономной работы. Если кодек обрабатывается аппаратно на данной платформе, он, вероятно, позволит значительно увеличить срок службы батареи и уменьшить выработку тепла.</p>
+
+<p>Например, Safari для iOS и iPadOS представила WebRTC с AVC в качестве единственного поддерживаемого видеокодека. Преимущество AVC на iOS и iPadOS заключается в возможности кодирования и декодирования на аппаратном уровне.Safari 12.1 представил поддержку VP8 в IRC, что улучшает взаимодействие, но за дополнительную плату - VP8 не имеет аппаратной поддержки на устройствах iOS, поэтому его использование приводит к увеличению нагрузки на процессор и сокращению срока службы батареи.</p>
+
+<h4 id="Призводительность">Призводительность</h4>
+
+<p>К счастью, VP8 и AVC работают одинаково с точки зрения конечного пользователя и одинаково адекватны для использования в видеоконференцсвязи и других решениях WebRTC. Окончательное решение остается за разработчиком. Какой бы вариант вы ни выбрали, обязательно прочитайте информацию, представленную в этой статье, о любых конкретных проблемах конфигурации, с которыми вам, возможно, придется столкнуться для этого кодека.</p>
+
+<p>Имейте в виду, что выбор кодека, которого нет в списке обязательных кодеков, может привести к риску выбора кодека, который не поддерживается браузером, который предпочитают ваши пользователи. Прочтите <a href="/en-US/docs/Web/Media/Formats/Support_issues">Решение проблем медиаподдержки в веб контенте</a> , чтобы узнать больше о том, как предлагать поддержку предпочитаемых кодеков, но при этом использовать браузеры, которые не поддерживают этот кодек.</p>
+
+<h2 id="Последствия_для_безопасности">Последствия для безопасности</h2>
+
+<p>При выборе и настройке кодеков возникают интересные потенциальные проблемы безопасности. Видео WebRTC защищено с помощью Datagram Transport Layer Security ({{Glossary("DTLS")}}), но для мотивированной стороны теоретически возможно вывести величину изменения, которое происходит от кадра к кадру при использовании кодеков с переменной скоростью передачи (VBR), путем мониторинга скорости потока  и ее изменения во времени.Это может потенциально позволить злоумышленнику сделать вывод о содержании потока, учитывая приливы и отливы скорости передачи.</p>
+
+<p>Подробнее о безопасности при использовании AVC в WebRTC см.  {{RFC(6184, "RTP Payload Format for H.264 Video: Security Considerations", 9)}}.</p>
+
+<h2 id="Смотри_так_же">Смотри так же :</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC API</a></li>
+ <li><a href="/en-US/docs/Web/API/WebRTC_API/Protocols">Введение в протоколы WebRTC</a></li>
+ <li><a href="/en-US/docs/Web/API/WebRTC_API/Connectivity">WebRTC соединение </a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/Video_codecs">Руководство по видеокодекам, использующимся в web</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/Audio_codecs">Руководство по аудиокодекам, использующимся в web</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/Video_concepts">Концепции цифрового видео</a></li>
+ <li><a href="/en-US/docs/Web/Media/Formats/Audio_concepts">Концепции цифрового аудио</a></li>
+</ul>
diff --git a/files/ru/web/media/index.html b/files/ru/web/media/index.html
new file mode 100644
index 0000000000..dc97746582
--- /dev/null
+++ b/files/ru/web/media/index.html
@@ -0,0 +1,89 @@
+---
+title: Web media technologies
+slug: Web/Media
+tags:
+ - Audio
+ - Landing
+ - Media
+ - NeedsTranslation
+ - TopicStub
+ - Video
+ - Web
+translation_of: Web/Media
+---
+<div>{{QuickLinksWithSubpages("/en-US/docs/Web/Media")}}</div>
+
+<p><span class="seoSummary">Over the years, the Web's ability to present, create, and manage audio, video, and other media has grown at an increasing pace. Today, there are a large number of APIs available, as well as HTML elements, DOM interfaces, and other features that make it possible to not only perform these tasks, but use media in tandem with other technologies to do truly remarkable things. This article lists the various APIs with links to documentation you may find helpful in mastering them.</span></p>
+
+<div class="row topicpage-table">
+<div class="section">
+<h2 class="Documentation" id="References">References</h2>
+
+<h3 id="HTML">HTML</h3>
+
+<p>These articles cover HTML features for media developers.</p>
+
+<dl>
+ <dt>{{HTMLElement("audio")}}</dt>
+ <dd>The <code>&lt;audio&gt;</code> element is used to play audio in a Web context. These can be used invisibly as a destination for more complex media, or with visible controls for user-controlled playback of audio files. Accessible from JavaScript as {{domxref("HTMLAudioElement")}} objects.</dd>
+ <dt>{{HTMLElement("video")}}</dt>
+ <dd>The <code>&lt;video&gt;</code> element is an endpoint for video content in a Web context. It can be used to simply present video files, or as a destination for streamed video content. <code>&lt;video&gt;</code> can also be used as a way to link media APIs with other HTML and DOM technologies, including {{HTMLElement("canvas")}} (for frame grabbing and manipulation), for example. Accessible from JavaScript as {{domxref("HTMLVideoElement")}} objects.</dd>
+ <dt>{{HTMLElement("track")}}</dt>
+ <dd>The HTML <code>&lt;track&gt;</code> element can be placed within an {{HTMLElement("audio")}} or {{HTMLElement("video")}} element to provide a reference to a <a href="/en-US/docs/Web/API/Web_Video_Text_Tracks_Format">WebVTT</a> format subtitle or caption track to be used when playing the media. Accessible from JavaScript as {{domxref("HTMLTrackElement")}} objects.</dd>
+ <dt>{{HTMLElement("source")}}</dt>
+ <dd>The HTML <code>&lt;source&gt;</code> element is used within an {{HTMLElement("audio")}} or {{HTMLElement("video")}} element to specify source media to present. Multiple sources can be used to provide the media in different formats, sizes, or resolutions. Accessible from JavaScript as {{domxref("HTMLSourceElement")}} objects.</dd>
+</dl>
+
+<h3 id="APIs">APIs</h3>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/API/Media_Capabilities_API">Media Capabilities API</a></dt>
+ <dd>The Media Capabilities API lets you determine the encoding and decoding capabilities of the device your app or site is running on. This lets you make real-time decisions about what formats to use and when.</dd>
+ <dt><a href="/en-US/docs/Web/API/Media_Streams_API">Media Capture and Streams API</a></dt>
+ <dd>A reference for the API which makes it possible to stream, record, and manipulate media both locally and across a network. This includes using local cameras and microphones to capture video, audio, and still images.</dd>
+ <dt><a href="/en-US/docs/Web/API/MediaStream_Recording_API">MediaStream Recording API</a></dt>
+ <dd>The MediaStream Recording API lets you capture media streams to process or filter the data or record it to disk.</dd>
+ <dt><a href="/en-US/docs/Web/API/Web_Audio_API">Web Audio API</a></dt>
+ <dd>The Web Audio API lets you generate, filter, and manipulate sound data both in real-time and on pre-recorded material, then send that audio to a destination such as an <code>&lt;audio&gt;</code> element, a media stream, or to disk.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC</a></dt>
+ <dd>WebRTC (Web Real-Time Communication) makes it possible to stream live audio and video, as well as transfer arbitrary data, between two peers over the Internet, without requiring an intermediary.</dd>
+</dl>
+</div>
+
+<div class="section">
+<h2 class="Documentation" id="Guides">Guides</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Media/Overview">Overview of media technology on the web</a></dt>
+ <dd>A general look at the open Web technologies and APIs that provide support for audio and video playback, manipulation, and recording. If you're not sure which API you should use, this is the place to start.</dd>
+ <dt><a href="/en-US/docs/Web/Media/HTML_media">Using audio and video in HTML</a></dt>
+ <dd>A guide to using the HTML <code>&lt;audio&gt;</code> and <code>&lt;video&gt;</code> elements.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Accessibility">Accessibility guide for media in web design</a></dt>
+ <dd>In this guide, we cover ways web designers and developers can create content that is accessible to people with different capabilities. This ranges from simply using the {{htmlattrxref("alt", "img")}} attribute on {{HTMLElement("img")}} elements to captions to tagging media for screen readers.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Formats">Guide to media types and formats on the web</a></dt>
+ <dd>A guide to the file types and codecs available for images, audio, and video media on the web. This includes recommendations for what formats to use for what kinds of content, best practices including how to provide fallbacks and how to prioritize media types, and also includes general browser support information for each media container and codec.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Streaming">Streaming audio and video</a></dt>
+ <dd>A guide which covers how to stream audio and video, as well as techniques and technologies you can take advantage of to ensure the best possible quality and/or performance of your streams.</dd>
+ <dt><a href="/en-US/docs/Web/Media/Autoplay_guide">Autoplay guide for media and Web Audio APIs</a></dt>
+ <dd>Unexpected automatic playback of media or audio can be an unwelcome surprise to users. While autoplay serves a purpose, it should be used carefully. To give users control over this, many browsers now provide forms of autoplay blocking. This article is a guide to autoplay, with tips on when and how to use it and how to work with browsers to handle autoplay blocking gracefully.</dd>
+</dl>
+
+<dl>
+</dl>
+
+<h2 id="Other_topics">Other topics</h2>
+
+<p>Related topics which may be of interest, since they can be used in tandem with media APIs in interesting ways.</p>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/API/Canvas_API">The Canvas API</a></dt>
+ <dd>The Canvas API lets you draw into an {{HTMLElement("canvas")}}, manipulating and changing the contents of an image. This can be used with media in many ways, including by setting a <code>&lt;canvas&gt;</code> element as the destination for video playback or camera capture so that you can capture and manipulate video frames.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebGL_API">WebGL</a></dt>
+ <dd>WebGL provides an OpenGL ES compatible API on top of the existing Canvas API, making it possible to do powerful 3D graphics on the Web. Through a canvas, this can be used to add 3D imagery to media content.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebVR_API">WebVR</a></dt>
+ <dd>The Web Virtual Reality API supports virtual reality (VR) devices such as the Oculus Rift or the HTC Vive, making it possible for developers to translate position and movement of the user into movement within a 3D scene which is then presented on the device. WebVR is expected to be gradually replaced with WebXR, which covers a wider range of use cases.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebXR_API">WebXR</a></dt>
+ <dd>WebXR, which is meant to eventually replace WebVR, is a technology that provides support for creating virtual reality (VR) and augmented reality (AR) content. The mixed reality content can then be displayed on the device's screen or using goggles or a headset.</dd>
+</dl>
+</div>
+</div>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-16 05:30:45 +0000