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

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

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

WebRTC использует объект типа MediaStreamTrack для представления каждого трека, передающегося между узлами соединения без использования контейнера или объекта типа MediaStream , объединяющего треки. Какие кодеки моут быть в этих треках, спецификацией  WebRTC не определяется. Однако, RFC 7742 определяет, что все браузеры, поддерживающие WebRTC, должны поддерживать VP8 и H.264 ограниченный базовый профиль для видео; и RFC 7874 , определяющая, что браузеры должны поддерживать, по меньшей мере, кодеки Opus и G.711  форматов 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, который мы  описывали в общем  в основной статье  руководства по сетевым видеокодекам, имеет специфические требования, которым необходимо следовать при кодировании видео треков WebRTC соединения.

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

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

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

 Кодек AVC / H.264

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

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

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

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 Edge, Firefox, Safari
G.711 PCM (A-law) Chrome, Firefox, Safari
G.711 PCM (µ-law) 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.

Comfort noise (CN) - комфортный шум. Является формой искусственного фонового шума, использующегося для заполнения пробелов в передаче, вместо использования полной тишины. Помогает избежать вибрационных эффектов, возникающих, когда голосовая активация или подобная функциональность  вызывает временное простановление потока, известная как прерывистая передача (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, в соответствующей секции  нашего руководства по аудиокодекам, использующимся в web.

Должны поддерживаться оба режима : речь и обычное аудио. Масштабируемость и гибкость 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 кбит / с. И в µ-law , и в A-law разрешена кодировка.

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() (или эквивалентный для принимающего узла RTCRtpReceiver.getCapabilities() ), определяющий тип медиаданных в параметре. К примеру, для определения поддерживаемых кодеков видео применяем :

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

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

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

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() вызывается для получения списка всех объектов RTCRtpSender , использующихся в соединении.

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

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

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

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

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

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

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's track's kind. Так же получаем список поддерживаемых браузером кодеков стороны отправки и получения  video, используя статический метод getCapabilities() обоих классов RTCRtpSender и RTCRtpReceiver.

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

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

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

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

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, перечислены ниже

Предпочтительные для  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. Из двух обязательных кодеков для видео - VP8 и AVC / H.264 - только VP8 полностью свободен от лицензионных требований. Если выбираете AVC, убедитесь, что вы знаете о любых возможных сборах, которые вам, возможно, придется заплатить; владельцы патентов обычно говорят, что большинству типичных разработчиков веб-сайтов не нужно беспокоиться об оплате лицензионных сборов, которые, как правило, больше ориентированы на разработчиков программного обеспечения для кодирования и декодирования.

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

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

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

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

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

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

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

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

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

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

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