Adding captions and subtitles to HTML5 video
============================================

>
> В других статьях мы рассмотрели как создать cross browser видео плеер используя `HTMLMediaElement` и `Window.fullScreen` (en-US) APIs, а так-же как стилизовать плеер. В этой статье мы возьмём тот же плеер и покажем как добавить подписи и субтитры, используя `the WebVTT format` (en-US) и `<track>` элемент.
>
>
>

Пример видео с подписями
------------------------

В этой статье мы сошлёмся на пример плеера с подписями. Этот пример использует отрывок из Sintel open movie, созданного Blender Foundation.

![Video player with stand controls such as play, stop, volume, and captions on and off. The video playing shows a scene of a man holding a spear-like weapon, and a caption reads "Esta hoja tiene pasado oscuro."](/ru/docs/Web/Media/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video/video-player-with-captions.png)

**Примечание:** вы можете найти source on Github, а так же посмотреть пример.

HTML5 и Video Captions
----------------------

До того как погрузиться в то, как добавить подписи в видео плеер, мы хотели бы упомянуть о некоторых вещах, о которых вы должны знать перед тем как начать.

### Подписи или Субтитры

Подписи и субтитры не одно и тоже: они имеют существенные различия для зрителя, и передают различную информацию, мы рекомендуем ознакомится с различиями, если вы не уверены, что они есть. Однако технически они реализуются одинаково, поэтому материал в нашей статье применим к обоим.

В этой статье мы сошлёмся на text tracks, отображаемые как субтистры, т.к их контент направлен на слышащих людей, со сложностью понимания языка в фильме, а не на людей с плохим или отсутствием слуха.

### Элемент <track>

HTML5 позволяет нам указать субтитры для видео, используя `<track>` элемент. Различные атрибуты этого элемента позволяют нам указать такие вещи как тип контента, который мы хотим разместить, язык и конечно ссылку на текстовый файл который содержит информацию о субтитрах.

### WebVTT

Файлы содержащие данные о субтитрах - это простой текстовый файл, который следует специальному формату, такому как Web Video Text Tracks (en-US) (WebVTT) формат. WebVTT specification всё ещё работает, по этому основные его части стабильны и мы можем использовать их сегодня.

Поставщики видео контента (такие как Blender Foundation) предоставляют и подписи и субтитры в текстовом формате с их видео, но они обычно в SubRip Text (SRT) формате. Этот формат может быть легко переконвертирован в WebVTT, используя online конвертер например такой как srt2vtt.

Modifications to the HTML and CSS
---------------------------------

В этом разделе представлены модификации, сделанные в коде предыдущих статей, для того чтобы облегчить добавление субтитров в видео. Если вам это не интересно и вы просто хотите идти дальше в JavaScript и более соответствующий CSS, пропустите Subtitle implementation раздел.

В этом примере мы используем другое видео, Sintel, так как оно имеет больше речи и следовательно лучше иллюстрирует работу субтитров.

### HTML Markup

Как упоминалось выше, нам необходимо использовать новый HTML5 `<track>` чтобы добавить файл с субтитрами в HTML5 Video. У нас уже имеется субтритры в 3х различных локалях, такие как English, German и Spanish, что ж теперь мы привяжем все 3 соответствующих VTT файла, добавляя `<track>` внутрь нашего HTML5 `<video>` элемента:

```html
<video id="video" controls preload="metadata">
  <source src="video/sintel-short.mp4" type="video/mp4" />
  <source src="video/sintel-short.webm" type="video/webm" />
  <track
 label="English"
 kind="subtitles"
 srclang="en"
 src="captions/vtt/sintel-en.vtt"
 default />
  <track
 label="Deutsch"
 kind="subtitles"
 srclang="de"
 src="captions/vtt/sintel-de.vtt" />
  <track
 label="Español"
 kind="subtitles"
 srclang="es"
 src="captions/vtt/sintel-es.vtt" />
</video>
```

Как вы можете видеть, каждый `<track>` элемент имеет следующие установленные атрибуты:

* `kind` is given a value of `subtitles`, indicating the type of content the files contain
* `label` is given a value indicating which language that subtitle set is for — for example `English` or `Deutsch` — these labels will appear in the user interface to allow the user to easily select which subtitle language they want to see.
* `src` is assigned a valid URL pointing to the relevant WebVTT subtitle file in each case.
* `srclang` indicates what language each subtitle files' contents are in.
* The `default` attribute is set on the English `<track>` element, indicating to the browser that this is the default subtitle file definition to use when subtitles have been turned on and the user has not made a specific selection.

В дополнении к нашему `<track>` элементу, мы так же добавили новую кнопку контроля меню субтитров. Как следствие, контроллеры видео выглядят следующим образом:

```html
<div id="video-controls" class="controls" data-state="hidden">
  <button id="playpause" type="button" data-state="play">Play/Pause</button>
  <button id="stop" type="button" data-state="stop">Stop</button>
  <div class="progress">
    <progress id="progress" value="0" min="0">
      <span id="progress-bar"></span>
    </progress>
  </div>
  <button id="mute" type="button" data-state="mute">Mute/Unmute</button>
  <button id="volinc" type="button" data-state="volup">Vol+</button>
  <button id="voldec" type="button" data-state="voldown">Vol-</button>
  <button id="fs" type="button" data-state="go-fullscreen">Fullscreen</button>
  <button id="subtitles" type="button" data-state="subtitles">CC</button>
</div>
```

### CSS Changes

Видео контроллеры подверглись некоторым изменениям, чтобы сделать пространство для новой кнопки, но эти изменения относительно просты.

В подписи кнопки не использовано никаких изображений, поэтому это просто стилизовано как:

```css
.controls button[data-state="subtitles"] {
  height: 85%;
  text-indent: 0;
  font-size: 16px;
  font-size: 1rem;
  font-weight: bold;
  color: #666;
  background: #000;
  border-radius: 2px;
}
```

Есть так же и другие CSS изменения, характерные для некоторой дополнительной реализации JavaScript, но об этом будет упомянуто ниже.

Subtitle implementation
-----------------------

Множество того, что мы делаем для доступа к видео субтитрам, вращается вокруг JavaScript. Аналогично видео контроллерам, если браузер поддерживает HTML5 video субтитры, существует контроллер, входящий в состав встроенного набора управления, чтобы получить доступ к ним. Однако, определив наши собственные элементы управления видео, эта кнопка является скрытой, поэтому мы должны определить свою.

Браузеры различаются в зависимости от того, что они поддерживают, поэтому мы должны попытаться предоставить единый UI, для каждого браузера, где это возможно.

### Initial setup

Как и со всеми другими кнопками, одно из первых вещей, которые мы должны сделать - это получить дескриптор нашей кнопки субтитров:

```js
var subtitles = document.getElementById("subtitles");
```

Мы так же изначально отключаем все субтитры, в случае если браузер включает некоторые из них по умолчанию:

```js
for (var i = 0; i < video.textTracks.length; i++) {
  video.textTracks[i].mode = "hidden";
}
```

Свойство `video.textTracks` содержит массив всех текстовых треков, присоединённых к видео. Мы проходим по каждому и устанавливаем его `mode` в `hidden`

Примечание: WebVTT API даёт нам доступ ко всем текстовым трекам, что определены в HTML5 video, c помощью элемента `<track>`

### Building a caption menu

Наша цель - это использовать кнопку `subtitles` , которую мы добавили ранее, чтобы дать возможность пользователю выбрать тот язык, который он хочет или полностью отключить субтитры.

Мы добавили кнопку, но перед тем как что-то сделать, мы должны создать меню, которое с ней идёт. Это меню создаётся динамически, т.к языки могут быть добавлены или удалены после, простым редактированием элементов `<track>` в разметке видео.

Все что нам необходимо сделать - это пройти через `textTracks`, читая их свойства и строя меню из них:

```js
var subtitlesMenu;
if (video.textTracks) {
  var df = document.createDocumentFragment();
  var subtitlesMenu = df.appendChild(document.createElement("ul"));
  subtitlesMenu.className = "subtitles-menu";
  subtitlesMenu.appendChild(createMenuItem("subtitles-off", "", "Off"));
  for (var i = 0; i < video.textTracks.length; i++) {
    subtitlesMenu.appendChild(
      createMenuItem(
        "subtitles-" + video.textTracks[i].language,
        video.textTracks[i].language,
        video.textTracks[i].label,
      ),
    );
  }
  videoContainer.appendChild(subtitlesMenu);
}
```

This code creates a `documentFragment`, which is used to hold an unordered list containing our subtitles menu. First of all an option is added to allow the user to switch all subtitles off, and then buttons are added for each text track, reading the language and label from each one.

The creation of each list item and button is done by the `createMenuItem()` function, which is defined as follows:

```js
var captionMenuButtons = [];
var createMenuItem = function (id, lang, label) {
  var listItem = document.createElement("li");
  var button = listItem.appendChild(document.createElement("button"));
  button.setAttribute("id", id);
  button.className = "subtitles-button";
  if (lang.length > 0) button.setAttribute("lang", lang);
  button.value = label;
  button.setAttribute("data-state", "inactive");
  button.appendChild(document.createTextNode(label));
  button.addEventListener("click", function (e) {
    // Set all buttons to inactive
    subtitleMenuButtons.map(function (v, i, a) {
      subtitleMenuButtons[i].setAttribute("data-state", "inactive");
    });
    // Find the language to activate
    var lang = this.getAttribute("lang");
    for (var i = 0; i < video.textTracks.length; i++) {
      // For the 'subtitles-off' button, the first condition will never match so all will subtitles be turned off
      if (video.textTracks[i].language == lang) {
        video.textTracks[i].mode = "showing";
        this.setAttribute("data-state", "active");
      } else {
        video.textTracks[i].mode = "hidden";
      }
    }
    subtitlesMenu.style.display = "none";
  });
  subtitleMenuButtons.push(button);
  return listItem;
};
```

This function builds the required `<li>` and `<button>` elements, and returns them so they can be added to the subtitles menu list. It also sets up the required event listeners on the button to toggle the relevant subtitle set on or off. This is done by simply setting the required subtlte's `mode` attribute to `showing`, and setting the others to `hidden`.

Once the menu is built, it is then inserted into the DOM at the bottom of the videoContainer.

Initially the menu is hidden by default, so an event listener needs to be added to our subtitles button to toggle it:

```js
subtitles.addEventListener("click", function (e) {
  if (subtitlesMenu) {
    subtitlesMenu.style.display =
      subtitlesMenu.style.display == "block" ? "none" : "block";
  }
});
```

### Subtitle menu CSS

We also added some rudimentary styling for the newly created subtitles menu:

```css
.subtitles-menu {
  display: none;
  position: absolute;
  bottom: 14.8%;
  right: 20px;
  background: #666;
  list-style-type: none;
  margin: 0;
  padding: 0;
  width: 100px;
  padding: 10px;
}

.subtitles-menu li {
  padding: 0;
  text-align: center;
}

.subtitles-menu li button {
  border: none;
  background: #000;
  color: #fff;
  cursor: pointer;
  width: 90%;
  padding: 2px 5px;
  border-radius: 2px;
}
```

Styling the displayed subtitles
-------------------------------

One of the less well known about and supported features of WebVTT is the ability to style the individual subtitles (something called text cues) via CSS Extensions.

The `::cue` pseudo-element is the key to targetting individual text track cues for styling, as it matches any defined cue. There are only a handful of CSS properties that can be applied to a text cue:

* `color` (en-US)
* `opacity`
* `visibility`
* `text-decoration` (en-US)
* `text-shadow`
* `background` shorthand properties
* `outline` shorthand properties
* `font` shorthand properties, including `line-height`
* `white-space`

For example, to change the text colour of the text track cues you can write:

```css
::cue {
  color: #ccc;
}
```

If the WebVTT file uses voice spans, which allow cues to be defined as having a particular "voice":
```

0
00:00:00.000 --> 00:00:12.000
<v Test>[Test]</v>
```

Then this specific 'voice' will be stylable like so:

```css
::cue(v[voice="Test"]) {
  color: #fff;
  background: #0095dd;
}
```

**Примечание:** Some of the styling of cues with ::cue currently works on Chrome, Opera, and Safari, but not yet on Firefox.

Совместимость с браузерами
--------------------------

Browser support for WebVTT and the `<track>` element is fairly good, although some browsers differ slightly in their implementation.

### Safari

In Safari 6.1+, subtitles are enabled by default, and the default controls contain a button and a menu that offers the same functionality as the menu we just built, along with an "Auto" option which allows the browser to choose. The `default` attribute is also supported.

### Chrome and Opera

These browsers have similar implementations again: subtitles are enabled by default and the default control set contains a 'cc' button that turns subtitles on and off. Chrome and Opera ignore the `default` attribute on the `<track>` element and will instead try to match the browser's language to the subtitle's language.

Plugins
-------

 There are also many open-source and commercial HTML video-player plugins that offer caption and subtitle support that you can use instead of rolling your own.
 You can search for those on the web using search terms like *"HTML video player plugin"*.


Медиа-буферизация, поиск и временные диапазоны
==============================================

Sometimes it's useful to know how much `<audio>` or `<video>` has downloaded or is playable without delay — a good example of this is the buffered progress bar of an audio or video player. This article discusses how to build a buffer/seek bar using TimeRanges (en-US), and other features of the media API.

Buffered
--------

Атрибут `buffered` расскажет нам, какие части медиа-элемента были загружены. Он возвращает объект `TimeRanges` (en-US), который содержит информацию о том, какие куски медиа были загружены. Обычно он непрерывный, но если пользователь перескакивает, когда медиа-элемент занят буферизацией, он может содержать пропуски.

Это будет работать с `<audio>` или `<video>`; теперь давайте рассмотрим простой пример для audio:

```html
<audio id="my-audio" controls src="music.mp3"></audio>
```

Мы можем получить доступ к этому атрибутам, так:

```js
var myAudio = document.getElementById("my-audio");

var bufferedTimeRanges = myAudio.buffered;
```

Объект TimeRanges
-----------------

TimeRanges содержит данные о частях буферизованных участков медиафайла (один или более — сколько успело буферизоваться) (Узнать больше о TimeRanges (en-US)).

Объект `TimeRanges` (en-US) имеет следующие свойства:

* `length`: число интервалов.
* `start(index)`: начальное время указанного интервала.
* `end(index)`: конечное время указанного интервала.

Без действий пользователя обычно существует только один временной диапазон (Time Ranges), но если вы переходите по медиа-файлу, может появиться более одного диапазона, как показано на рисунке ниже. Получится два буферизированных диапазона по времени - один с 0 по 5 секунду, а второй - с 15 по 19 секунду.
```

------------------------------------------------------
|=============|                    |===========|     |
------------------------------------------------------
0             5                    15          19    21
```

Для этого звукового файла `TimeRange` будет иметь следующие доступные свойства:

```js
myAudio.buffered.length; // returns 2
myAudio.buffered.start(0); // returns 0
myAudio.buffered.end(0); // returns 5
myAudio.buffered.start(1); // returns 15
myAudio.buffered.end(1); // returns 19
```

Чтобы опробовать и визуализировать буферные диапазоны времени, мы можем написать немного HTML:

```html
<p>
  <audio id="my-audio" controls>
    <source src="music.mp3" type="audio/mpeg" />
  </audio>
</p>
<p>
  <canvas id="my-canvas" width="300" height="20"> </canvas>
</p>
```

и немного JavaScript:

```js
window.onload = function () {
  var myAudio = document.getElementById("my-audio");
  var myCanvas = document.getElementById("my-canvas");
  var context = myCanvas.getContext("2d");

  context.fillStyle = "lightgray";
  context.fillRect(0, 0, myCanvas.width, myCanvas.height);
  context.fillStyle = "red";
  context.strokeStyle = "white";

  var inc = myCanvas.width / myAudio.duration;

  // отображение TimeRanges

  myAudio.addEventListener("seeked", function () {
    for (i = 0; i < myAudio.buffered.length; i++) {
      var startX = myAudio.buffered.start(i) \* inc;
      var endX = myAudio.buffered.end(i) \* inc;
      var width = endX - startX;

      context.fillRect(startX, 0, width, myCanvas.height);
      context.rect(startX, 0, width, myCanvas.height);
      context.stroke();
    }
  });
};
```

Это наглядно работает с длинными фрагментами аудио или видео. Нажмите кнопку воспроизведения и нажмите на панели прогресса и вы должны получить что-то вроде того, что показано на картинке ниже. Each red filled white rectangle represents a time range.

![A simple audio player with play button, seek bar and volume control, with a series of red rectangles beneath it representing time ranges.](/ru/docs/Web/Media/Audio_and_video_delivery/buffering_seeking_time_ranges/bufferedtimeranges.png)

**Примечание:** You can see the timerange code running live on JS Bin.

Seekable
--------

The `seekable` attribute returns a `TimeRanges` (en-US) object and tells us which parts of the media can be played without delay; this is irrespective of whether that part has been downloaded or not. Some parts of the media may be seekable but not buffered if byte-range requests are enabled on the server. Byte range requests allow parts of the media file to be delivered from the server and so can be ready to play almost immediately — thus they are seekable.

```js
var seekableTimeRanges = myAudio.seekable;
```

Создание собственной буферизации
--------------------------------

If we wish to create our own custom player, we may want to provide feedback on how much of the media is ready to be played. In practice a good way to do this is use the `seekable` attribute, although as we have seen above seekable parts of the media are not neccessarily contiguous — they often are however and we can safely approximate this information to give the user an indication of which parts of the media can be played directly. We can find this point in the media using the following line of code:

```js
var seekableEnd = myAudio.seekable.end(myAudio.seekable.length - 1);
```

**Примечание:** `myAudio.seekable.end(myAudio.seekable.length - 1)` actually tells us the end point of the last time range that is seekable (not all seekable media). In practice this is good enough as the browser either enables range requests or it doesn't. If it doesn't then `audio.seekable` will be equivalent to `audio.buffered`, which will give a valid indication of the end of seekable media. If range requests are enabled this value usually becomes the duration of the media almost instantly.

It is better perhaps to give an indication of how much media has actually downloaded — this what the browser's native players seem to display.

Итак, давайте реализуем это. HTML для нашего плеера выглядит так:

```css
<audio id="my-audio" preload controls>
  <source src="music.mp3" type="audio/mpeg">
</audio>
<div class="buffered">
  <span id="buffered-amount"></span>
</div>
<div class="progress">
  <span id="progress-amount"></span>
</div>
```

Мы будем использовать следующий CSS для стилизации отображения буферизации:

```css
.buffered {
  height: 20px;
  position: relative;
  background: #555;
  width: 300px;
}

#buffered-amount {
  display: block;
  height: 100%;
  background-color: #777;
  width: 0;
}

.progress {
  margin-top: -20px;
  height: 20px;
  position: relative;
  width: 300px;
}

#progress-amount {
  display: block;
  height: 100%;
  background-color: #595;
  width: 0;
}
```

И следующий JavaScript реализует нашу функциональность:

```js
window.onload = function () {
  var myAudio = document.getElementById("my-audio");

  myAudio.addEventListener("progress", function () {
    var duration = myAudio.duration;
    if (duration > 0) {
      for (var i = 0; i < myAudio.buffered.length; i++) {
        if (
          myAudio.buffered.start(myAudio.buffered.length - 1 - i) <
          myAudio.currentTime
        ) {
          document.getElementById("buffered-amount").style.width =
            (myAudio.buffered.end(myAudio.buffered.length - 1 - i) / duration) \*
              100 +
            "%";
          break;
        }
      }
    }
  });

  myAudio.addEventListener("timeupdate", function () {
    var duration = myAudio.duration;
    if (duration > 0) {
      document.getElementById("progress-amount").style.width =
        (myAudio.currentTime / duration) \* 100 + "%";
    }
  });
};
```

The progress event is fired as data is downloaded, this is a good event to react to if we want to display download or buffering progress.

The timeupdate event is fired 4 times a second as the media plays and that's where we increment our playing progress bar.

This should give you results similar to the following, where the light grey bar represents the buffered progress and green bar shows the played progress:

![A simple audio player with play button, seek bar and volume control, with a bar below it. The bar has a red portion to show played video, and a dark gray bar to show how much has been buffered.](/ru/docs/Web/Media/Audio_and_video_delivery/buffering_seeking_time_ranges/bufferedprogress.png)

**Примечание:** You can see the buffering code running live on JS Bin.

Пару слов о Played
------------------

Надо заметить, что есть свойство `played`, сообщающее, были ли воспроизведены интервалы полностью. Пример:

```js
var played = audio.played; // вернёт объект TimeRanges
```

Если просуммировать все интервалы `audio.played`, то получим долю прослушанного аудио, что может быть полезно для сбора метрик.


Кодеки, используемые WebRTC

Кодеки, используемые WebRTC
===========================

С WebRTC API возможно создание сайтов и приложений, позволяющих пользователям общаться в реальном времени, используя аудио и/или видео, а также передавать данные или другую информацию. Для общения, двум устройствам необходима возможность согласования использования кодеков, для каждой дорожки в потоке данных, для успешного взаимодействия и обмена медиаданными. В этом руководстве рассматриваются кодеки, которые требуются браузерам для этого, а также другие кодеки, которые поддерживаются некоторыми или всеми браузерами, поддерживающими WebRTC.

Безконтейнерные медиаданные
---------------------------

WebRTC использует объект типа `MediaStreamTrack` для представления каждого трека, передающегося между узлами соединения без использования контейнера или объекта типа `MediaStream` , объединяющего треки. Какие кодеки могут быть в этих треках, спецификацией WebRTC не определяется. Однако, RFC 7742 определяет, что все браузеры, поддерживающие WebRTC, должны поддерживать VP8 (en-US) и H.264 (en-US) ограниченный базовый профиль для видео; и RFC 7874 , определяющая, что браузеры должны поддерживать, по меньшей мере, кодеки Opus (en-US) и G.711 (en-US) форматов PCMA и PCMU.

Эти две спецификации определяют свойства, которые должны поддерживаться каждым кодеком, а так же определённые функции для удобства использования, к примеру, функция эхоподавления. В этом руководстве происходит обзор кодеков, поддержка которых обязательна браузерам для реализации WebRTC, а так же иные (не обязательные) кодеки, поддерживаемые отдельными или всеми браузерами,.

Хоть сжатие всегда и необходимо при работе со средствами массовой информации в Интернете, оно имеет дополнительное значение при проведении видеоконференций, чтобы участники могли общаться без задержек и перерывов. Второстепенное значение имеет необходимость синхронизации видео и звука, чтобы движения и любая вспомогательная информация (например, слайды или проекция) были представлены одновременно с соответствующим звуком

Общие требования к кодекам
--------------------------

Прежде чем рассматривать возможности и требования, специфичные для кодеков, необходимо выполнить несколько общих требований, которые должны быть выполнены при любой конфигурации кодеков, используемой с WebRTC

Если SDP специально не указывает иное, веб-браузер, принимающий видеопоток WebRTC, должен иметь возможность обрабатывать видео со скоростью не менее 20 кадров в секунду при минимальном разрешении 320 пикселей в ширину и 240 пикселей в высоту. Рекомендуется, чтобы видео кодировалось с частотой кадров и размером не ниже этого, поскольку это, по сути, нижняя граница того, что WebRTC обычно должен обрабатывать.

SDP поддерживает независимый от кодеков способ указания предпочтительных разрешений видео (RFC 6236). Это делается путём отправки `a=imageattr` атрибута SDP для указания максимально допустимого разрешения. Однако отправителю не требуется поддерживать этот механизм, поэтому вы должны быть готовы получать носители с другим разрешением, чем вы запрашивали. Помимо этого простого запроса максимального разрешения, определённые кодеки могут предлагать дополнительные способы запроса конкретных конфигураций мультимедиа.

Поддерживаемые видео кодеки
---------------------------

WebRTC устанавливает набор базовых кодеков, которые требуются браузерам для работы. Некоторые браузеры могут поддерживать дополнительный набор кодеков.

Ниже приведены видеокодеки, которые требуются в любом полностью совместимом с WebRTC браузере, а также требуемые профили и браузеры, которые фактически соответствуют требованиям

| Наименование кодека | Профиль | Совместимость с браузерами |
| --- | --- | --- |
| VP8 | — | Chrome, Edge, Firefox, Safari (12.1+) |
| AVC / H.264 | Constrained Baseline (CB) | Chrome (52+), Edge, Firefox[1], Safari |

[1] Firefox для Android 68 и более поздних версий больше не поддерживает AVC (H.264). Это связано с изменением требований магазина Google Play, которые не позволяют Firefox загружать и устанавливать кодек OpenH264, необходимый для обработки H.264 в соединениях WebRTC. Смотрим подробности в статье о SUMO.

Для получения дополнительной информации о соображениях, связанных с WebRTC для каждого кодека, см. Подразделы ниже, перейдя по ссылкам на название каждого кодека.

Полную информацию о том, какие видеокодеки и конфигурации требуется для поддержки WebRTC, можно найти в RFC 7742: Требования к обработке видео и кодекам WebRTC. Стоит отметить, что RFC охватывает множество требований, связанных с видео, включая цветовые пространства (sRGB является предпочтительным, но не обязательным цветовым пространством по умолчанию), рекомендации по функциям обработки веб-камеры (автоматическая фокусировка, автоматический баланс белого, автоматический уровень освещения) и так далее.

**Примечание:** Эти требования относятся к веб-браузерам и другим продуктам, полностью совместимым с WebRTC. Продукты, не относящиеся к WebRTC, которые в некоторой степени могут взаимодействовать с WebRTC, могут поддерживать или не поддерживать эти кодеки, хотя это рекомендуется в технических документах

В дополнение к обязательным кодекам, некоторые браузеры также поддерживают дополнительные кодеки. Они перечислены в таблице ниже

| Наименование кодека | Профили | Совместимость с браузерами |
| --- | --- | --- |
| VP9 | — | Chrome (48+), Firefox |

### Кодек VP8

VP8, который мы описывали в общем (en-US) в основной статье руководства по сетевым видеокодекам (en-US), имеет специфические требования, которым необходимо следовать при кодировании видео треков WebRTC соединения.

По умолчанию, VP8 будет использовать квадратные пиксели (то есть, пиксели с соотношением сторон 1: 1).

#### Дополнительное замечание

Формат полезной нагрузки сети для совместного использования VP8 с помощью RTP (en-US) (например, при использовании WebRTC) описано в RFC 7741: RTP Payload Format for VP8 Video.

### Кодек AVC / H.264

Поддержка профиля AVC Constrained Baseline (`CB`) требуется во всех полностью совместимых реализациях WebRTC. `CB` является подмножеством основного профиля и специально разработан для приложений с низкой сложностью и малой задержкой, таких как мобильное видео и видеоконференции, а также для платформ с более низкими возможностями обработки видео..

Наш обзор AVC (en-US) и его функциональности найдёте в основном руководстве по видеокодекам.

#### Требования поддержки специальных параметров

AVC предлагает широкий спектр параметров для управления дополнительными значениями. Чтобы повысить надёжность совместного использования мультимедиа WebRTC на нескольких платформах и в разных браузерах, необходимо, чтобы конечные точки WebRTC, поддерживающие AVC, обрабатывали определённые параметры определённым образом. Иногда это просто означает, что параметр должен (или не должен) поддерживаться. Иногда это означает, что необходимо указать конкретное значение для параметра или разрешить определённый набор значений. А иногда требования более сложны.

##### Полезные, но необязательные параметры

Эти параметры не обязаны поддерживаться конечной точкой WebRTC, и их использование также не обязательно. Их использование, некоторым образом, может улучшить пользовательское впечатление , но к использованию не обязательно. Некоторые из них довольно сложны в использовании.

`max-br`

Если параметр определён и поддерживается , он определяет максимальную скорость передачи видеоданных в единицах 1,000 bps (бит в секунду) для VCL и 1,200 bps (бит в секунду) для NAL. Подробности на странице 47 спецификации RFC 6184.

`max-cpb`

Если параметр определён и поддерживается, он определяет максимальный размер буфера, кодируемых данных. Немного усложнённый параметр, размер которого может варьироваться. Смотрим на страницу 45 спецификации RFC 6184 о подробностях.

`max-dpb`

Определяет максимальный размер буфера декодированных данных, выраженных в единицах 8/3 макроблоков. Подробности в спецификации RFC 6184, страница 46.

`max-fs`

Определяет максимальный размер видеокадра, выраженный в количестве макроблоков.

`max-mbps`

Определяет максимальную скорость обработки макроблоков в секунду. Значение является целым числом..

`max-smbps`

Определяет максимальную скорость обработки статических макроблоков в секунду (используя гипотетическое предположение, что все макроблоки являются статическими макроблоками).

##### Параметры с определёнными требованиями

Эти параметры являются необязательными, но имеют специальные требования при их использовании.

`packetization-mode`

Все конечные точки обязательны для поддержания режима 1 (не чередующийся режим). Поддержка иных режимов пакетизации не обязательна, и сам параметр не обязателен для определения.

`sprop-parameter-sets`

Информация о последовательности и изображении для AVC может передаваться как внутри канала, так и вне его. При использовании AVC с WebRTC, информация должна передаваться в канале, поэтому значение параметра не включается в SDP.

##### Обязательные для определения параметры

Эти параметры обязательны к определению, при использовании AVC в WebRTC соединении.

* `profile-level-id`

Все реализации WebRTC обязательно определяют и передают в своих SDP, определяя суб - профиль используемого кодека (подмножество инструментов кодирования, которые могут быть использованы для генерации потока или того, что поддерживает получатель) и уровня потока по умолчанию, или уровня поддержки получателя.

Конкретное значение разработчику не известно, используется одно на всех, и устанавливается WebRTC. Начиная с RFC 6184 ("RTP Payload Format for H.264 Video"), наличие `profile-level-id` необязательно.

#### Прочие требования

В целях поддержки переключения между книжной и альбомной ориентацией можно использовать два метода. Первый - это расширение заголовка видеоориентации (CVO) для протокола RTP. Однако, если это не сигнализируется как поддерживаемое в SDP, тогда рекомендуется, чтобы браузеры поддерживали сообщения Display Orientation SEI, хотя и не обязательно

Если не указано иное, соотношение сторон пикселя составляет 1: 1, что указывает на то, что пиксели являются квадратными

#### Прочие замечания

Формат полезной нагрузки, используемый для AVC в WebRTC, описан в RFC 6184: RTP Payload Format for H.264 Video. Реализации AVC для WebRTC необходимы для поддержки специальных сообщений SEI : «заполнитель нагрузки» и «полное замораживание кадра», они используются для плавного переключения между несколькими входными потоками.

Поддерживаемые аудио кодеки
---------------------------

Спецификация RFC 7874 предписывает всем браузерам поддержку аудиокодеков, перечисленных в таблице :

| Наименование кодека | Совместимость с браузерами |
| --- | --- |
| Opus (en-US) | Edge, Firefox, Safari |
| G.711 PCM (A-law) (en-US) | Chrome, Firefox, Safari |
| G.711 PCM (µ-law) (en-US) | Chrome, Firefox, Safari |

Более подробное обсуждение использования кодеков в WebRTC следует ниже.

Спецификация RFC 7874 определяет список аудио кодеков, которые браузеры, реализующие WebRTC обязаны поддерживать; так же предоставляются рекомендации и требования для специфических аудио функциональностей, таких как удаление эхоподавление, шумоподавление и выравнивание звука.

**Примечание:** Список выше указывает на минимальный набор кодеков, который требуется реализовать браузерам (браузерному окружению), поддерживающих WebRTC. Такие браузеры могут поддерживать также и другие кодеки, что подвергает риску межплатформенной совместимости при использовании этих кодеков без проверки гарантированной работоспособности в часто используемых браузерах.

В дополнение к обязательным видеокодекам, некоторые браузеры поддерживают дополнительные кодеки, перечисленные в таблице:

| Наименование кодека | Совместимость с браузерами |
| --- | --- |
| G.722 | Chrome, Firefox, Safari |
| iLBC[1] | Chrome, Safari |
| iSAC[2] | Chrome, Safari |

[1] **Internet Low Bitrate Codec (iLBC)** - узкополосный кодек с открытым кодом, разработанный Global IP Solutions и Google, спроектированный для потокового голосового аудио. Google и другие разработчики браузеров адоптировали его для работы с WebRTC, но он доступен не во всех браузерах, и не является обязательно поддерживаемым кодеком.

[2] The **Internet Speech Audio Codec (iSAC)** - другой кодек, разработанный Global IP Solutions, теперь принадлежащий Google, открывший его код. Используется Google Talk, QQ, и другими клиентами быстрых сообщений, специально спроектированный для голосовых сообщений, упакованных в поток RTP. Пока не является обязательной поддерживаемым кодеком. Поддерживается Safari и Chrome. Не поддерживается Firefox и Edge.

**Комфортный шум** является формой искусственного фонового шума, использующегося для заполнения пробелов в передаче, вместо использования полной тишины. Помогает избежать вибрационных эффектов, возникающих, когда голосовая активация или подобная функциональность вызывает временное приостановление потока, известная как прерывистая передача (Discontinuous Transmission (DTX)). В спецификации RFC 3389, метод предлагает использовать определённое заполнение в беззвучных промежутках.

Комфортный шум используется с G.711 и может потенциально использоваться с другими кодеками, которые не имеют встроенной функции CN. Кодек Opus, к примеру, имеет собственную реализацию CN, поэтому использование RFC 3389 CN с кодеком Opus не рекомендуется.

Отправитель звука никогда не должен использовать прерывистую передачу или комфортный шум.

### Кодек Opus

Формат Opus, определённый в RFC 6716), является основным форматом для аудио в WebRTC. Формат полезной нагрузки RTP для Opus находится в RFC 7587. Можете найти подробную информацию об Opus и его возможностях, а также о том, как другие API могут поддерживать Opus, в соответствующей секции (en-US) нашего руководства по аудиокодекам, использующимся в web (en-US).

Должны поддерживаться оба режима : речь и обычное аудио. Масштабируемость и гибкость Opus полезна при работе с аудио, имеющим различную степень сложности. Поддержка внутриполосных стереосигналов позволяет поддерживать стереозвук без усложнения процесса демультиплексирования.

Весь диапазон битрейтов, поддерживаемых Opus (от 6 кбит/с до 510 кбит/с), поддерживается в WebRTC, причём скорость битов можно динамически изменять. Более высокие битовые скорости передачи обычно улучшают качество.

#### Рекомендации по скорости передачи данных (bit rate)

При условии размер кадра в 20 миллисекунд, в следующей таблице приведены рекомендуемые скорости передачи данных для различных типов носителей.

| Медиа носитель | Рекомендованный диапазон bit rate |
| --- | --- |
| Узкополосная речь (NB) | 8 - 12 kbps |
| Широкополосная речь (WB) | 16 - 20 kbps |
| Полноценная речь (FB) | 28 - 40 kbps |
| Монофоническая музыка (FB mono) | 48 - 64 kbps |
| Стереофоническая музыка (FB stereo) | 64 - 128 kbps |

Скорость передачи может быть скорректирована в любое время. Во избежание перегрузки сети средняя скорость передачи звука не должна превышать доступную пропускную способность сети (за вычетом любых других известных или ожидаемых дополнительных требований к пропускной способности).

### Кодек G.711

G.711 определяет формат для звука с импульсной кодовой модуляцией (PCM) в виде серии 8-битных целочисленных выборок, взятых с частотой дискретизации 8000 Гц, что даёт скорость передачи данных 64 кбит/с. И в Мю-законе, и в A-законе разрешена кодировка.

G.711 определяется ITU, а его формат нагрузки в RFC 3551: 4.5.14.

WebRTC требует, чтобы G.711 использовал 8-битные выборки со стандартной скоростью 64 кбит/с, хотя G.711 поддерживает некоторые другие варианты. WebRTC не предписывает использовать ни G.711.0 (сжатие без потерь), G.711.1 (широкополосная возможность), ни какие-либо другие расширения стандарта G.711

Из-за низкой частоты дискретизации и размера выборки качество звука G.711 в целом считается низким по современным стандартам, хотя оно примерно эквивалентно звучанию стационарного телефона. Обычно он используется в качестве наименьшего общего знаменателя, чтобы гарантировать, что браузеры могут установить аудио-соединение независимо от платформ и браузеров, или как запасной вариант в целом.

Определение и конфигурирование кодеков
--------------------------------------

### Получение поддерживаемых кодеков

Поскольку браузер и платформа могут иметь различную доступность среди потенциальных кодеков - и могут иметь несколько профилей или уровней, поддерживаемых для данного кодека - первый шаг при настройке кодеков для объекта типа `RTCPeerConnection` - получить список доступных кодеков. Для этого сначала нужно инициализировать объект соединения, который получит список.

Существует два способа для выполнения этого. Наиболее эффективный - использовать статический метод `RTCRtpSender.getCapabilities()` (en-US) (или эквивалентный для принимающего узла `RTCRtpReceiver.getCapabilities()` (en-US) ), определяющий тип медиаданных в параметре. К примеру, для определения поддерживаемых кодеков видео применяем :

```js
codecList = RTCRtpSender.getCapabilities("video").codecs;
```

Теперь массив `codecList` содержит объекты `RTCRtpCodecCapability` (en-US) , каждый содержащий описываемую конфигурацию кодека. Также в списке будут присутствовать записи для повторной передачи (RTX), избыточного кодирования (RED) и прямого исправления ошибок (FEC).

Если соединение находится в процессе запуска, используем событие `icegatheringstatechange` (en-US) для наблюдения за изменением статуса сборки кандидатов ICE (en-US) и при завершении, запрашиваем список кодеков.

```js
let codecList = null;

peerConnection.addEventListener("icegatheringstatechange", (event) => {
  if (peerConnection.iceGatheringState === "complete") {
    const senders = peerConnection.getSenders();

    senders.forEach((sender) => {
      if (sender.track.kind === "video") {
        codecList = sender.getParameters().codecs;
        return;
      }
    });
  }

  codecList = null;
});
```

Обработчик события `icegatheringstatechange` установлен; в нем мы отслеживаем тип события `complete` завершения сборки кандидатов ICE, указывающее что сборка кандидатов завершена. Метод `RTCPeerConnection.getSenders()` (en-US) вызывается для получения списка всех объектов `RTCRtpSender` (en-US) , использующихся в соединении.

Имея это в виду, мы просматриваем список отправителей и ищем первого, чей `MediaStreamTrack` указывает, что тип `track` в своём свойстве `kind` (en-US) содержит значение `video`, указывающее, что данные являются видеоданными. Затем вызывается метод отправителя `getParameters()` (en-US) , и значением свойства `codecs` возвращаемого объекта `RTCRtpSendParameters` (en-US) , инициализируем переменную `codecList`.

Если видеотрек не найден, устанавливаем `codecList` в `null`.

При возврате, `codecList` либо `null` , указывающий на то, что видеодорожки не были найдены, либо это массив `RTCRtpCodecParameters` (en-US) объектов, каждый из которых описывает одну разрешённую конфигурацию кодека. Особое значение в этих объектах имеет свойство `payloadType`, которое является однобайтовым значением, однозначно идентифицирующим описанную конфигурацию.

**Примечание:** Два метода получения списков кодеков, показанные здесь, используют разные типы вывода в своих списках кодеков. Помните об этом при использовании результатов

### Настройка списка кодеков

Как только получен список доступных кодеков, его можно изменить и передать этот пересмотренный список методу `RTCRtpTransceiver.setCodecPreferences()` (en-US) для перенастройки списка, используемых кодеков. Это изменяет порядок предпочтений кодеков, позволяя указать WebRTC на более предпочтительный кодек среди прочих .

```js
function changeVideoCodec(mimeType) {
  const transceivers = peerConnection.getTransceivers();

  transceivers.forEach((transceiver) => {
    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();
}
```

В этом примере функция `changeVideoCodec()` принимает в параметр MIME тип предпочтительного к использованию кодека. Код начинается с получения списка объектов приёмо-передатчиков объекта соединения `RTCPeerConnection`.

Затем, для каждого приёмо-передатчика анализируем тип медиа свойства `RTCRtpSender` (en-US)'s track's `kind` (en-US). Так же получаем список поддерживаемых браузером кодеков стороны отправки и получения `video`, используя статический метод `getCapabilities()` обоих классов `RTCRtpSender` (en-US) и `RTCRtpReceiver` (en-US).

Если тип медиаданных является типом `video`, вызываем метод `preferCodec()` для обоих взаимодействующих сторон списков кодеков, который реорганизует список кодеков необходимым образом (смотри ниже).

И наконец, вызываем метод `setCodecPreferences()` (en-US) объекта `RTCRtpTransceiver` (en-US) для определения того, что использование кодеков обеих сторон разрешено, в указанном порядке.

Это выполняется для каждого объекта приёмо-передатчика объекта соединения `RTCPeerConnection`; как только все приёмо-передатчики обновили списки предпочитаемых кодеков, вызывается обработчик события `onnegotiationneeded` (en-US) , который создаёт новый объект предложения, обновляет объект локального описания сессии, отправляет предложение удалённому узлу, и так далее, запуская согласование соединения .

Функция `preferCodec()` вызываемая приведённым выше кодом, действует так, чтобы переместить указанный кодек в верхнюю часть списка (для приоритета во время согласования):

```js
function preferCodec(codecs, mimeType) {
  let otherCodecs = [];
  let sortedCodecs = [];
  let count = codecs.length;

  codecs.forEach((codec) => {
    if (codec.mimeType === mimeType) {
      sortedCodecs.push(codec);
    } else {
      otherCodecs.push(codec);
    }
  });

  return sortedCodecs.concat(otherCodecs);
}
```

Этот код просто разбивает список кодеков на два массива: один, содержащий кодеки, чей MIME тип совпадает с тем, который указан в параметре `mimeType` , другой же содержит остальные кодеки. Как только список разделён, они объединяются вместе с записями, соответствующими заданному `mimeType` следующими вначале, за которыми следуют остальные записи кодеков. Затем этот список возвращается вызывающему коду.

Кодеки по умолчанию
-------------------

Если не определённо иное, кодеки по умолчанию (предпочтительные кодеки), запрашиваемые браузерными реализациями WebRTC, перечислены ниже

|  | Audio | Video |
| --- | --- | --- |
| Chrome |  |  |
| Edge |  |  |
| Firefox |  | VP9 (Firefox 46 and later) VP8 |
| Opera |  |  |
| Safari |  |  |

Правильный выбор кодеков
------------------------

Перед выбором кодека, который не является обязательным (VP8 или AVC для видео и Opus или PCM для аудио), следует серьёзно рассмотреть потенциальные недостатки: в особенности, если предполагается, что эти кодеки не широко доступны на всех устройствах, поддерживающих WebRTC.

Если вы предпочитаете кодек, отличный от обязательных, вы должны по крайней мере разрешить откат к одному из обязательных кодеков, если поддержка для кодека, который вы предпочитаете, окажется недоступна.

### Аудио

В целом, если кодек доступен и звук, который вы хотите отправить, имеет частоту дискретизации более 8 кГц, вам следует настоятельно рекомендовать использовать Opus в качестве основного кодека. Для голосовых соединений в стеснённой среде использование G.711 с частотой дискретизации 8 кГц может обеспечить приемлемое качество для разговора, но обычно вы будете использовать G.711 в качестве запасного варианта, поскольку есть другие более эффективные варианты, чей звук лучше, такие как Опус в своём узкополосном режиме .

### Видео

При выборе поддерживаемого видеокодека (или набора кодеков) необходимо учитывать ряд факторов

#### Условия лицензирования

Прежде чем выбрать видеокодек, убедитесь, что вы знаете о любых лицензионных требованиях к выбранному вами кодеку; можете найти информацию о возможных проблемах лицензирования в нашем основном руководстве по видеокодекам, используемым в web (en-US). Из двух обязательных кодеков для видео - VP8 и AVC / H.264 - только VP8 полностью свободен от лицензионных требований. Если выбираете AVC, убедитесь, что вы знаете о любых возможных сборах, которые вам, возможно, придётся заплатить; владельцы патентов обычно говорят, что большинству типичных разработчиков веб-сайтов не нужно беспокоиться об оплате лицензионных сборов, которые, как правило, больше ориентированы на разработчиков программного обеспечения для кодирования и декодирования.

**Предупреждение:** **Внимание :** Информация здесь не является юридической консультацией! Обязательно убедитесь в возможности ответственности, прежде чем принимать какие-либо окончательные решения, если существует вероятность возникновения проблем с лицензированием.

#### Энергопотребление и срок службы батареи

Ещё один фактор, который следует учитывать, особенно на мобильных платформах, - это влияние кодека на время автономной работы. Если кодек обрабатывается аппаратно на данной платформе, он, вероятно, позволит значительно увеличить срок службы батареи и уменьшить выработку тепла.

Например, Safari для iOS и iPadOS представила WebRTC с AVC в качестве единственного поддерживаемого видеокодека. Преимущество AVC на iOS и iPadOS заключается в возможности кодирования и декодирования на аппаратном уровне.Safari 12.1 представил поддержку VP8 в IRC, что улучшает взаимодействие, но за дополнительную плату - VP8 не имеет аппаратной поддержки на устройствах iOS, поэтому его использование приводит к увеличению нагрузки на процессор и сокращению срока службы батареи.

#### Производительность

К счастью, VP8 и AVC работают одинаково с точки зрения конечного пользователя и одинаково адекватны для использования в видеоконференцсвязи и других решениях WebRTC. Окончательное решение остаётся за разработчиком. Какой бы вариант вы ни выбрали, обязательно прочитайте информацию, представленную в этой статье, о любых конкретных проблемах конфигурации, с которыми вам, возможно, придётся столкнуться для этого кодека.

Имейте в виду, что выбор кодека, которого нет в списке обязательных кодеков, может привести к риску выбора кодека, который не поддерживается браузером, который предпочитают ваши пользователи. Прочтите Решение проблем медиаподдержки в веб контенте (en-US) , чтобы узнать больше о том, как предлагать поддержку предпочитаемых кодеков, но при этом использовать браузеры, которые не поддерживают этот кодек.

Последствия для безопасности
----------------------------

При выборе и настройке кодеков возникают интересные потенциальные проблемы безопасности. Видео WebRTC защищено с помощью Datagram Transport Layer Security (DTLS (en-US)), но для мотивированной стороны теоретически возможно вывести величину изменения, которое происходит от кадра к кадру при использовании кодеков с переменной скоростью передачи (VBR), путём мониторинга скорости потока и её изменения во времени.Это может потенциально позволить злоумышленнику сделать вывод о содержании потока, учитывая приливы и отливы скорости передачи.

Подробнее о безопасности при использовании AVC в WebRTC см. RFC 6184, раздел 9: RTP Payload Format for H.264 Video: Security Considerations.

Смотрите также
--------------

* WebRTC API
* Введение в протоколы WebRTC
* WebRTC соединение
* Руководство по видеокодекам, использующимся в web (en-US)
* Руководство по аудиокодекам, использующимся в web (en-US)
* Концепции цифрового видео (en-US)
* Концепции цифрового аудио (en-US)


Параметр "codecs" для распространённых типов носителей
======================================================

На базовом уровне, можно задать тип медиа файла, используя простой

MIME (en-US) тип, такой как `video/mp4` или `audio/mpeg`. Однако, многие медиа типы, особенно те, которые поддерживают видео дорожки, более привлекательные из-за способности более точного описания содержащегося формата данных. Например, просто описывая видео в файле MPEG-4 (en-US) с MIME типом `video/mp4` ничего не скажет о том, какой формат в действительности он содержит.

По этой причине в MIME тип может быть добавлен параметр `codecs` , описывающий медиа контент, предоставляя более подробную информацию о содержимом. Эта информация может содержать, к примеру, профиль видео кодека, или тип, используемый аудио треками, и так далее.

В этом руководстве кратко рассматривается синтаксис параметра `codecs` мультимедийного типа и его использование со строкой, описывающей MIME тип, для предоставления подробных сведений о содержимом аудио- или видеоматериалов, помимо простого указания типа

Общий синтаксис
---------------

Основной медиатип определяется установкой строкового значения (`audio`, `video`, и т.д.), после которого идёт символ слеша (`/`), затем указывается формат контейнера, который будет содержать информацию:

`audio/mpeg`

Аудио файл, использующий тип файла MPEG (en-US) , к примеру, MP3.

`video/ogg`

Видео файл, использующий тип файла Ogg (en-US).

`video/mp4`

Видео файл, использующий тип файла MPEG-4 (en-US).

`video/quicktime`

Видео файл, Apple формата QuickTime (en-US). Как уже отмечалось, этот формат обычно используется в Сети, поскольку требует использования плагинов.

Однако эти MIME являются не прозрачными. Все эти типы поддерживают несколько кодеков, и эти кодеки могут содержать несколько профилей, уровней , и других факторов конфигурирования. По этой причине указывается строковый параметр медиа типа `codecs`.

Для его добавления, перед ним ставиться точка с запятой (`;`) , за которой следует строка `codecs=` , в значении указывается формат содержимого файла. Некоторые типы носителей позволяют указывать только имена используемых кодеков, в то время как другие позволяют также указывать различные ограничения для этих кодеков. Вы можете указать несколько кодеков, разделяя их запятыми.

`audio/ogg; codecs=vorbis`

Файл Ogg (en-US) содержит Vorbis (en-US) аудио трек.

`video/webm; codecs="vp8, vorbis"`

Файл WebM (en-US) , содержащий VP8 (en-US) видео и/или Vorbis (en-US) аудио.

`video/mp4; codecs="avc1.4d002a"`

Файл MPEG-4 (en-US) , содержащий AVC (en-US) (H.264) видео, Основной профиль, Уровень 4.2.

Как и в случае с любым параметром MIME типа , `codecs` должен заменяться на `codecs*` (обратите внимание на символ звёздочки, `*`) , если какое-либо из свойств кодека использует специальные символы для указания дополнительной информации (языковые отметки, кодировка байтов в шестнадцатеричные значения и т.д.), входящие в RFC 2231, раздел 4: MIME Parameter Value and Encoded Word Extensions. Можно использовать функции JavaScript `encodeURI()` для кодирования списка параметров, можно использовать `decodeURI()` для декодирования предварительно закодированного списка параметров.

**Примечание:** Когда используется параметр `codecs`, указанный список кодеков должен включать каждый кодек, используемый для содержимого файла Список также может содержать кодеки, которых нет в файле.

Свойства кодеков для контейнеров
--------------------------------

Контейнеры ниже поддерживают расширенные свойства кодеков в своих параметрах `codecs` :

* 3GP
* AV1
* ISO BMFF
* MPEG-4
* QuickTime
* WebM

Несколько ссылок выше входят в одину и то же секцию, потому, что все медиатипы основаны на файловом формате ISO Base Media File Format (ISO BMFF), поэтому они используют тот же синтаксис.

### AV1

Синтаксис параметра `codecs` для AV1 определяется спецификацией AV1 Codec ISO Media File Format Binding, секция 5: Строки параметра codecs.
```

av01.P.LLT.DD[.M[.CCC[.cp[.tc[.mc[.F]]]]]]
```

Компоненты строковых параметров кодеков описываются более подробно в таблице ниже. Каждый компонент имеет фиксированное количество символов, и если значение меньше этой длины, оно должно быть дополнено начальными нулями.

AV1 компоненты строковых параметров кодека| Компонент | Описание |
| --- | --- |
| `P` | Однознаковый номер профиля:

AV1 номера профилей| Номер профиля | Описание |
| --- | --- |
| 0 |
 "Основной" профиль; поддерживает YUV 4:2:0 или одноцветный поток
 битов с глубиной 8 или 10 бит на компонент.
  |
| 1 | "Высокий" профиль добавляет поддержку выбора цветности 4:4:4. |
| 2 |
 "Профессиональный" профиль добавляет поддержку выбора цветности
 4:2:2 и 12 бит на один цвет компонента.
  |

 |
| `LL` |
 Двухзначный номер уровня, который преобразуется в формат X.Y, где `X = 2 + (LL >> 2)`,
 и `Y = LL & 3`. Подробнее
 Дополнение A, секция 3
 в спецификации AV1 .
  |
| `T` |
 The one-character tier indicator. For the Main tier (`seq_tier`
 equals 0), this character is the letter `M`. For the High
 tier (`seq_tier` is 1), this character is the letter
 `H`. The High tier is only available for level 4.0 and up.
  |
| `DD` |
 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.
  |
| `M` |
 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
 YUV (en-US)
 for details on how the YUV color system works. The default value is 0
 (not monochrome).
  |
| `CCC` |
`CCC` indicates the chroma subsampling as three digits. The
 first digit is `subsampling_x`, the second is
 `subsampling_y`. If both of those are 1, the third is the
 value of `chroma_sample_position`; otherwise, the third
 digit is always 0. This, combined with the `M` component,
 can be used to construct the chroma subsampling format:

Determining the chroma subsampling format| subsampling\_x | subsampling\_y | Monochrome flag | Chroma subsampling format |
| --- | --- | --- | --- |
| 0 | 0 | 0 | YUV 4:4:4 |
| 1 | 0 | 0 | YUV 4:2:2 |
| 1 | 1 | 0 | YUV 4:2:0 |
| 1 | 1 | 1 | YUV 4:0:0 (Monochrome) |

 The third digit in `CCC` 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.

The default value is `110` (4:2:0 chroma subsampling). |
| `cp` |
 The two-digit `color_primaries` value indicates the color
 system used by the media. For example, BT.2020/BT.2100 color, as used
 for HDR video, is `09`. The information for this—and for each
 of the remaining components—is found in the
 Color config semantics section
 of the AV1 specification. The default value is `01` (ITU-R
 BT.709).
  |
| `tc` |
 The two-digit `transfer_characteristics` 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 `14`.
 The default value is `01` (ITU-R BT.709).
  |
| `mc` |
 The two-digit `matrix_coefficients` 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 `01`. The
 default value is `01` (ITU-R BT.709).
  |
| `F` |
 A one-digit flag indicating whether the color should be allowed to use
 the full range of possible values (`1`), or should be
 constrained to those values considered legal for the specified color
 configuration (that is, the
 **studio swing representation**). The default is 0 (use the
 studio swing representation).
  |

All fields from `M` (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:

`av01.2.15M.10.0.100.09.16.09.0`

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.

`av01.0.15M.10`

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.

### ISO Base Media File Format: MP4, QuickTime, and 3GP

All media types based upon the ISO Base Media File Format (ISO BMFF) share the same syntax for the `codecs` parameter. These media types include MPEG-4 (en-US) (and, in fact, the QuickTime (en-US) file format upon which MPEG-4 is based) as well as 3GP (en-US). Both video and audio tracks can be described using the `codecs` parameter with the following MIME types:

| MIME type | Description |
| --- | --- |
| `audio/3gpp` | 3GP audio (RFC 3839: MIME Type Registrations for 3rd generation Partnership Project (3GP) Multimedia files) |
| `video/3gpp` | 3GP video (RFC 3839: MIME Type Registrations for 3rd generation Partnership Project (3GP) Multimedia files) |
| `audio/3gp2` | 3GP2 audio (RFC 4393: MIME Type Registrations for 3GPP2 Multimedia files) |
| `video/3gp2` | 3GP2 video (RFC 4393: MIME Type Registrations for 3GPP2 Multimedia files) |
| `audio/mp4` | MP4 audio (RFC 4337: MIME Type Registration for MPEG-4) |
| `video/mp4` | MP4 audio (RFC 4337: MIME Type Registration for MPEG-4) |
| `application/mp4` | Non-audiovisual media encapsulated in MPEG-4 |

Each codec described by the `codecs` parameter can be specified either as simply the container's name (`3gp`, `mp4`, `quicktime`, 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 (`.`).

The syntax for the value of `codecs` varies by codec; however, it always starts with the codec's four-character identifier, a period separator (`.`), 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 AVC (H.264) (en-US).

Thus, the syntaxes for each of the supported codecs look like this:

`cccc[.pp]*` (Generic ISO BMFF)

Where `cccc` is the four-character ID for the codec and `pp` is where zero or more two-character encoded property values go.

`mp4a.oo[.A]` (MPEG-4 audio)

Where `oo` is the Object Type Indication value describing the contents of the media more precisely and `A` is the one-digit *audio* OTI. The possible values for the OTI can be found on the MP4 Registration Authority web site's Object Types page. For example, Opus audio in an MP4 file is `mp4a.ad`. For further details, see MPEG-4 audio.

`mp4v.oo[.V]` (MPEG-4 video)

Here, `oo` is again the OTI describing the contents more precisely, while `V` is the one-digit *video* OTI.

`avc1.oo[.PPCCLL]` (AVC video)

`oo` is the OTI describing the contents, while `PPCCLL` is six hexadecimal digits specifying the profile number (`PP`), constraint set flags (`CC`), and level (`LL`). See AVC profiles for the possible values of `PP`.

The constraint set flags byte is comprised of one-bit Boolean flags, with the most significant bit being referred to as flag 0 (or `constraint_set0_flag`, in some resources), and each successive bit being numbered one higher. Currently, only flags 0 through 2 are used; the other five bits *must* be zero. The meanings of the flags vary depending on the profile being used.

The level is a fixed-point number, so a value of `14` (decimal 20) means level 2.0 while a value of `3D` (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.

#### AVC profiles

The following are the AVC profiles and their profile numbers for use in the `codecs` parameter, as well as the value to specify for the constraints component, `CC`.

| Profile | Number (Hex) | Constraints byte |
| --- | --- | --- |
| **Constrained Baseline Profile (CBP)** 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. | `42` | `40` |
| **Baseline Profile (BP)** 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. | `42` | `00` |
| **Extended Profile (XP)** Designed for streaming video over the network, with high compression capability and further improvements to data robustness and stream switching. | `58` | `00` |
| **Main Profile (MP)** The profile used for standard-definition digital television being broadcast in MPEG-4 format. *Not* 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. | `4D` | `00` |
| **High Profile (HiP)** 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. | `64` | `00` |
| **Progressive High Profile (PHiP)** Essentially High Profile without support for field coding. | `64` | `08` |
| **Constrained High Profile** PHiP, but without support for bi-predictive slices ("B-slices"). | `64` | `0C` |
| **High 10 Profile (Hi10P)** High Profile, but with support for up to 10 bits per color component. | `6E` | `00` |
| **High 4:2:2 Profile (Hi422P)** Expands upon Hi10P by adding support for 4:2:2 chroma subsampling along with up to10 bits per color component. | `7A` | `00` |
| **High 4:4:4 Predictive Profile (Hi444PP)** 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). | `F4` | `00` |
| **High 10 Intra Profile** High 10 constrained to all-intra-frame use. Primarily used for professional apps. | `6E` | `10` |
| **High 4:2:2 Intra Profile** The Hi422 Profile with all-intra-frame use. | `7A` | `10` |
| **High 4:4:4 Intra Profile** The High 4:4:4 Profile constrained to use only intra frames. | `F4` | `10` |
| **CAVLC 4:4:4 Intra Profile** The High 4:4:4 Profile constrained to all-intra use, and to using only CAVLC entropy coding. | `44` | `00` |
| **Scalable Baseline Profile** Intended for use with video conferencing as well as surveillance and mobile uses, the 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. | `53` | `00` |
| **Scalable Constrained Baseline Profile** Primarily used for real-time communication applications. Not yet supported by WebRTC, but an extension to the WebRTC API to allow SVC is in development. | `53` | `04` |
| **Scalable High Profile** Meant mostly for use in broadcast and streaming applications. The base (or highest quality) layer must conform to the AVC High Profile. | `56` | `00` |
| **Scalable Constrained High Profile** A subset of the Scalable High Profile designed mainly for real-time communticions. | `56` | `04` |
| **Scalable High Intra Profile** Primarily useful only for production applications, this profile supports only all-intra usage. | `56` | `20` |
| **Stereo High Profile** 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. | `80` | `00` |
| **Multiview High Profile** Supports two or more views using both temporal and MVC inter-view prediction. *Does not support* field pictures or macroblock-adaptive frame-field coding. | `76` | `00` |
| **Multiview Depth High Profile** Based on the High Profile, to which the main substream must adhere. The remaining substreams must match the Stereo High Profile. | `8A` | `00` |

#### MPEG-4 audio

When the value of an entry in the `codecs` list begins with `mp4a`, the syntax of the value should be:
```

mp4a.oo[.A]
```

Here, `oo` is the two-digit hexadecimal Object Type Indication which specifies the codec class being used for the media. The OTIs are assigned by the MP4 Registration Authority, which maintains a list of the possible OTI values. A special value is `40`; 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 `40` to narrow the type down to a specific subtype of MPEG-4.

The Audio Object Type is specified as a one or two digit *decimal* value (unlike most other values in the `codecs` parameter, which use hexadecimal). For example, MPEG-4's AAC-LC has an audio object type number of `2`, so the full `codecs` value representing AAC-LC is `mp4a.40.2`.

Thus, ER AAC LC, whose Audio Object Type is 17, can be represented using the full `codecs` value `mp4a.40.17`. 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 `mp4a.40.02`.

**Примечание:** 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 `0` 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.

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.

| ID | Audio Object Type | Profile support |
| --- | --- | --- |
| `0` | NULL |  |
| `1` | AAC Main | Main |
| `2` | AAC LC (Low Complexity) | Main, Scalable, HQ, LD v2, AAC, HE-AAC, HE-AAC v2 |
| `3` | AAC SSR (Scalable Sampling Rate) | Main |
| `4` | AAC LTP (Long Term Prediction) | Main, Scalable, HQ |
| `5` | SBR (Spectral Band Replication) | HE-AAC, HE-AAC v2 |
| `6` | AAC Scalable | Main, Scalable, HQ |
| `7` | TwinVQ (Coding for ultra-low bit rates) | Main, Scalable |
| `8` | CELP (Code-Excited Linear Prediction) | Main, Scalable, Speech, HQ, LD |
| `9` | HVXC (Harmonic Vector Excitation Coding) | Main, Scalable, Speech, LD |
| `10` – `11` | *Reserved* |  |
| `12` | TTSI (Text to Speech Interface) | Main, Scalable, Speech, Synthetic, LD |
| `13` | Main Synthetic | Main, Synthetic |
| `14` | Wavetable Synthesis |  |
| `15` | General MIDI |  |
| `16` | Algorithmic Synthesis and Audio Effects |  |
| `17` | ER AAC LC (Error Resilient AAC Low-Complexity) | HQ, Mobile Internetworking |
| `18` | *Reserved* |  |
| `19` | ER AAC LTP (Error Resilient AAC Long Term Prediction) | HQ |
| `20` | ER AAC Scalable (Error Resilient AAC Scalable) | Mobile Internetworking |
| `21` | ER TwinVQ (Error Resilient TwinVQ) | Mobile Internetworking |
| `22` | ER BSAC (Error Reslient Bit-Sliced Arithmetic Coding) | Mobile Internetworking |
| `23` | ER AAC LD (Error Resilient AAC Low-Delay; used for two-way communication) | LD, Mobile Internetworking |
| `24` | ER CELP (Error Resilient Code-Excited Linear Prediction) | HQ, LD |
| `25` | ER HVXC (Error Resilient Harmonic Vector Excitation Coding) | LD |
| `26` | ER HILN (Error Resilient Harmonic and Individual Line plus Noise) |  |
| `27` | ER Parametric (Error Resilient Parametric) |  |
| `28` | SSC (Sinusoidal Coding) |  |
| `29` | PS (Parametric Stereo) | HE-AAC v2 |
| `30` | MPEG Surround |  |
| `31` | *Escape* |  |
| `32` | MPEG-1 Layer-1 |  |
| `33` | MPEG-1 Layer-2 (MP2) |  |
| `34` | MPEG-1 Layer-3 (MP3) |  |
| `35` | DST (Direct Stream Transfer) |  |
| `36` | ALS (Audio Lossless) |  |
| `37` | SLS (Scalable Lossless) |  |
| `38` | SLS Non-core (Scalable Lossless Non-core) |  |
| `39` | ER AAC ELD (Error Resilient AAC Enhanced Low Delay) |  |
| `40` | SMR Simple (Symbolic Music Representation Simple) |  |
| `41` | SMR Main (Symbolic Music Representation Main) |  |
| `42` | *Reserved* |  |
| `43` | SAOC (Spatial Audio Object Coding)[1] |  |
| `44` | LD MPEG Surround (Low Delay MPEG Surround)[1] |  |
| `45` and up | *Reserved* |  |

[1] SAOC and LD MPEG Surround are defined in ISO/IEC 14496-3:2009/Amd.2:2010(E).

### WebM

The basic form for a WebM `codecs` parameter is to simply list one or more of the four WebM codecs by name, separated by commas. The table below shows some examples:

| MIME type | Description |
| --- | --- |
| `video/webm;codecs="vp8"` | A WebM video with VP8 video in it; no audio is specified. |
| `video/webm;codecs="vp9"` | A WebM video with VP9 video in it. |
| `audio/webm;codecs="vorbis"` | Vorbis audio in a WebM container. |
| `audio/webm;codecs="opus"` | Opus audio in a WebM container. |
| `video/webm;codecs="vp8,vorbis"` | A WebM container with VP8 video and Vorbis audio. |
| `video/webm;codecs="vp9,opus"` | A WebM container with VP9 video and Opus audio. |

The strings `vp8.0` and `vp9.0` also work, but are not recommended.

#### ISO Base Media File Format syntax

As part of a move toward a standardized and powerful format for the `codecs` parameter, WebM is moving toward describing *video* content using a syntax based on that defined by the ISO Base Media File Format. This syntax is defined in VP Codec ISO Media File Format Binding, in the section Codecs Parameter String. The audio codec continues to be indicated as either `vorbis` or `opus`.

In this format, the `codecs` 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 (`.`) separated two-digit values.
```

cccc.PP.LL.DD.CC[.cp[.tc[.mc[.FF]]]]
```

The first five components are required; everything from `cp` (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.

WebM codecs parameter components| Component | Details |
| --- | --- |
| `cccc` |
 A four-character code indicating which indicates which of the possible
 codecs is being described. Potential values are:

Four-character codes for WebM-supported codecs| Four-character code | Codec |
| --- | --- |
| `vp08` | VP8 |
| `vp09` | VP9 |
| `vp10` | VP10 |

 |
| `PP` |
 The two-digit profile number, padded with leading zeroes if necessary
 to be exactly two digits.

WebM profile numbers| Profile | Description |
| --- | --- |
| `00` |
 Only 4:2:0 (chroma subsampled both horizontally and vertically).
 Allows only 8 bits per color component.
  |
| `01` |
 All chroma subsampling formats are allowed. Allows only 8 bits
 per color component.
  |
| `02` |
 Only 4:2:0 (chroma subsampled both horizontally and vertically).
 Supports 8, 10, or 12 bits per color sample component.
  |
| `03` |
 All chroma subsampling formats are allowed. Supports 8, 10, or
 12 bits per color sample component.
  |

 |
| `LL` |
 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 `30` and level 6.1 is
 `61`.
  |
| `DD` |
 The bit depth of the luma and color component values; permitted values
 are 8, 10, and 12.
  |
| `CC` |
 A two-digit value indicating which chroma subsampling format to use.
 The following table lists permitted values; see
 Chroma subsampling (en-US)
 for additional information about this topic and others.

WebM chroma subsampling identifiers| Value | Chroma subsampling format |
| --- | --- |
| `00` |
 4:2:0 with the chroma samples sited interstitially between the
 pixels
  |
| `01` |
 4:2:0 chroma subsampling with the samples colocated with luma
 (0, 0)
  |
| `02` |
 4:2:2 chroma subsampling (4 out of each 4 horizontal pixels'
 luminance are used)
  |
| `03` |
 4:4:4 chroma subsampling (every pixel's luminance and
 chrominance are both retained)
  |
| `04` | *Reserved* |

 |
| `cp` |
 A two-digit integer specifying which of the color primaries from
 Section 8.1 of the
 ISO/IEC 23001-8:2016
 standard. This component, and every component after it, is optional.

The possible values of the color primaries component are:

ISO/IEC Color primary identifiers| Value | Details |
| --- | --- |
| `00` | *Reserved for future use by ITU or ISO/IEC* |
| `01` |
 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).
  |
| `02` |
 Image characteristics are unknown, or are to be determined by
 the application
  |
| `03` | *Reserved for future use by ITU or ISO/IEC* |
| `04` |
 BT.470 System M, NTSC (standard definition television in the
 United States)
  |
| `05` |
 BT.470 System B, G; BT.601; BT.1358 625; BT.1700 625 PAL and 625
 SECAM
  |
| `06` |
 BT.601 525; BT.1358 525 or 625; BT.1700 NTSC; SMPTE 170M.
 *Functionally identical to `7`.* |
| `70` | SMPTE (en-US) 240M (historical).
 *Functionally identical to `6`.* |
| `08` | Generic film |
| `09` |
 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.
  |
| `10` |
 SMPTE ST 428 (D-Cinema Distribution Master: Image
 characteristics). Defines the uncompressed image characteristics
 for DCDM.
  |
| `11` |
 SMPTE RP 431 (D-Cinema Quality: Reference projector and
 environment). Describes the reference projector and environment
 conditions that provide a consistent film presentation
 experience.
  |
| `12` |
 SMPTE EG 432 (Digital Source Processing: Color Processing for
 D-Cinema). Engineering guideline making color signal decoding
 recommendations for digital movies.
  |
| `13` – `21` | *Reserved for future use by ITU-T or ISO/IEC* |
| `22` | EBU Tech 3213-E |
| `23` – `255` | *Reserved for future use by ITU-T or ISO/IEC* |

 |
| `tc` |
 A two-digit integer indicating the
 `transferCharacteristics` for the video. This value is from
 Section 8.2 of
 ISO/IEC 23001-8:2016, and indicates the transfer characteristics to be used when adapting
 the decoded color to the render target.
  |
| `mc` |
 The two-digit value for the `matrixCoefficients` property.
 This value comes from the table in Section 8.3 of the
 ISO/IEC 23001-8:2016
 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.
  |
| `FF` |
 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 `00` indicates that these
 limitations should be enforced, while a value of `01` allows
 the full range of possible values for each component, even if the
 resulting color is out of bounds for the color system.
  |

#### WebM media type examples

`video/webm;codecs="vp08.00.41.08,vorbis"`

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.

`video/webm;codecs="vp09.02.10.10.01.09.16.09.01,opus"`

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.

Using the codecs parameter
--------------------------

You can use the `codecs` parameter in a few situations. Firstly, you can use it with the `<source>` element when creating an `<audio>` or `<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.

You can also use the codecs parameter when specifying a MIME media type to the `MediaSource.isTypeSupported()` (en-US) method; this method returns a Boolean which indicates whether or not the media is likely to work on the current device.

See also
--------

* Web media technologies (en-US)
* Guide to media types and formats on the web (en-US)
* Guide to audio codecs used on the web (en-US)
* Guide to video codecs used on the web (en-US)
* Codecs used by WebRTC