кодеком для приложений реального времени является
Внутренности протокола, которым браузеры передают голос и видео
WebRTC, технология голосовых и видеозвонков в браузерах (а еще realtime передачи произвольных данных, peer-to-peer пробивания NAT и захвата экрана) никогда не была простой. Долгая история, несовместимости между браузерами, запутанная документация, множество решаемых задач и используемых протоколов. Возможность позвонить и принять звонок из браузера всегда была одной из ключевых «фишек» нашей платформы Voximplant, и так как мы в этом неплохо разбираемся, то стараемся следить за интересными статьями и адаптировать их для аудитории Хабра. Под катом перевод свежей статьи от ребят из callstats.io — сервиса сбора статистики по качеству звонков для браузера. В небольшой статье они рассказывают о протоколе RTP с помощью которого, собственно, браузер и передает пакеты с голосом или видео.
WebRTC использует протокол SRTP (Secure Real-time Transport Protocol), чтобы обеспечить шифрование, аутентификацию и целостность сообщений, а также защитить RTP-данные от атак повторного воспроизведения. Это система безопасности, которая дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. Эти фишки безопасности в WebRTC – ключевой момент надежности и основа для всего, что касается RTP (Real-time Transport Protocol). Но что такое RTP, как оно работает?
Что такое RTP?
RTP это сетевой протокол, спроектированный для мультимедийных коммуникаций (VoIP, видеоконференции, телепрезентации), потоковой передачи мультимедиа (видео по запросу, прямые трансляции) и широковещательное медиа. Протокол был определен организацией IETF (Internet Engineering Task Force) в стандарте RFC1889. Изначально RTP создали для поддержки видеоконференций, в которых есть географически распределенные участники, разработку вела рабочая группа IETF по аудио- и видеотранспорту. На текущий момент, версия v2 из стандарта RFC3550 используется уже 15 лет!
В основе RTP лежат фундаментальные принципы формирования фреймов на уровне приложения и их обработки на уровне протокола. RTP описывает типы медиа данных и «полезной нагрузки» пакетов, механизм синхронизации медиапотоков, объясняет что делать с потерянными и перепутанными пакетами, как отслеживать состояние передаваемых медиаданных.
Для получения информации о качестве медиапотока внутри RTP используется «вложенный» протокол RTCP (RTP Control Protocol).
При использовании RTP отправляющая сторона упаковывает медиапоток в формат RTP пакетов и время от времени отсылает «RTCP Sender Report» для синхронизации медиапотоков между собой. Принимающая сторона организует «Jitter buffer» для сбор получаемых пакетов в правильном порядке и воспроизведения медиапотока в соответствии с информацией о таймингах, указанной в полученных пакетах. Если пакет теряется, то получающая сторона по возможности получает его еще раз или же “скрывает” проблему, интерполируя звук или разбивая видео на цветные квадратики. И, наконец, принимающая сторона передает в обратную сторону грубую или детальную статистику с помощью “RTCP Receiver Report”. Статистика позволяет отправителю выбирать битрейт, менять кодеки и выбирать объем коррекции ошибок.
Формат заголовка пакета RTP
Заголовок RTP пакета разделен на 4 части: источник синхронизации, метка времени, порядковый номер и тип полезной нагрузки.
1. Источник синхронизации. Позволяет определить, откуда идет медиапоток. Особенно полезно, когда источник отсылает несколько медиапотоков, которые надо синхронизировать.
2. RTP метка времени позволяет собирать из RTP пакетов медиа фреймы и воспроизводить медиапоток.
3. RTP порядковый номер: он и в африке порядковый номер, с его помощью находятся потерянные пакеты, а те что не потеряны — выстраиваются по порядку. UDP все-таки.
4. Тип полезной нагрузки определяет кодировку медиа данных в пакетах, его указывает кодек.
Отчеты RTCP
Известные в спецификации как «RTCP Reports», бывают трех типов: «Sender Reports» для отправителя, «Receiver Reports» для получателя и «Extended Reports» для всех участников процесса.
RTCP Sender Reports
Используются отправляющей стороной для синхронизации медиапотоков. Метки времени всех отправляемых потоков устанавливаются относительно часов этого компьютера, так что принимающая сторона понимает как потоки нужно воспроизводить друг относительно друга. В этом же отчете указывается количество отправляемых в секунду пакетов и байт.
RTCP Receiver Reports
Принимающая сторона осматривает получаемые потоки и отчитывается о происходящем с помощью пакетов «RTCP Receiver Report». В отчете указывается текущий уровень потерь пакетов, джиттер (буфер, в котором хранятся пакеты перед проигрыванием, чтобы подождать опоздавших и поменять местами запутавшихся), максимальный порядковый номер. Часть этих данных используется для расчета round trip time.
RTCP Extended Reports
Используются как отправляющей, так и принимающей стороной для передачи сложных метрик о происходящем между ними. К таким метрикам относится производительность самих компьютеров, состояние сети, джиттер буфера, вариации в задержках пакетов, просто информация о задержках, количество не обработанных пакетов, QoS и другие. Также в этот пакет можно добавлять собственные метрики, так что обе стороны могут отслеживать специфичные для приложения параметры.
Как выглядят форматы полезной нагрузки для RTP?
«Формат полезной нагрузки», payload format, задается такой штукой, которая в спецификации называется «кодированием», encoding. Непереводимая на русский игра слов описыват три варианта. Это может быть кодек, например H.264, H.263, H.261, MPEG-2, JPEG, G.711, G.722 или AMR. Это может быть «полезная нагрузка общего назначения», такая как «Forward Error Correction» (FEC), NACK и другие страшные акронимы. И, наконец, это могут быть мультиплексированные медиапотоки (несколько медиапотоков в рамках одного).
Спецификация жестко задает формат для кодеков и определяет два правила: агрегации и фрагментации. Правила агрегации описывают, как RTP работает с кодеками, которые производят пакеты меньше MTU — например, звуковыми кодеками. Правила фрагментации, наоборот, описывают работу с кодеками, предпочитающими большие пакеты, например пакеты с I-фреймами видеокодирования. RTP задает собственное фрагментирование, потому что IP фрагментирование для UDP как правило не работает, и NAT’ы с Firewall’ами просто молча дропают такие пакеты.
Для чего в RTP используются «Header Extensions»?
«Расширения» заголовков пакетов используются для информации, не имеющей отношения к медиапотокам. Обычно это та информация, которую нужно передавать в реальном времени — чаще, чем отсылаются RTCP отчеты.
Например, для интерактивных медиапотоков (видеочат?) RTP пакеты отправляются каждые несколько десятков миллисекунд. Расширение к RTP заголовкам может использоваться для индикации потерянных и полученных пакетов — чтобы реагировать быстрее, чем это позволяют получаемые время от времени RTCP отчеты с NACK/ACK.
Расширение заголовков обратно совместимо: если один из участников передачи данных не понимает этот формат, то он будет просто игнорировать соответствующую часть заголовка пакета. Заголовки описаны в спецификации как штука «общего назначения» и их не нужно отдельно указывать для каждого используемого кодека.
Они часто используются для передачи состояния сети и таких специфичных для приложения штук как громкость звука для нескольких каналов в конференции.
Что такое «отчетный интервал» для RTCP?
Использование протокола RTP выглядит как замкнутый цикл: мы отправляем RTP пакеты и получаем RTCP пакеты с обратной связью. Почти как TCP с его ACK. Обычно отчетный интервал выбирается так, чтобы объем передаваемых пакетов RTCP был гораздо меньше, чем объем передаваемых медиаданных. Выбор происходит на основании количества потоков, которые нужно синхронизировать, и ширины канала.
Теоретически, ширина канала должна равномерно делиться по участникам (аудио или видео конференции). На практике приложения рассчитывают ширину исходя из предполагаемого количества одновременно активных участников. Например, для аудиоконференции это обычно один участник: если несколько людей начнут говорить одновременно, то никто ничего не поймет. А вот для видеоконференции все сложнее: показывать видео с нескольких участников это вполне популярный сценарий. В таких ситуациях отчетный интервал рассчитывается индивидуально для каждого участника.
5% ширины канала выделяется для RTCP пакетов.
Для сценариев с большим количеством принимающих устройств и малым количеством отправляющих устройств (вебинар, голосовая конференция) четверть канала для отчетов равномерно распределяется для передающих устройств, а оставшиеся три четверти для принимающих. Такое распределение позволяет новым подключившимся устройствам быстро получить CNAME и метки времени для синхронизации. А чтобы новые подключившиеся устройства могли быстро передать информацию о себе, интервал отправки RTCP пакетов для них выбирается в два раза меньше, чем для остальных участников.
Рекомендованный минимальный интервал отправки RTCP пакетов составляет 5 секунд.
Это значение может быть уменьшено до 360 / ширина канала (в секундах) для ситуаций, когда данные передаются в обе стороны и нужно быстро передавать дополнительную информацию для управления потерями пакетов.
Расширенный профиль RTP для обратной связи с помощью RTCP
Если клиент замечает потери пакетов или проблемы с сетью, то он не может сразу отослать RTCP пакет и должен подождать окончания интервала. А там, на секундочку, 5 секунд. Для решения вопроса в спецификации есть «Extended RTP Profile for RTCP-Based Feedback» — это расширение правил RTP о таймингах.
Если оба устройства поддерживают такой профиль, то они могут договориться отсылать RTCP пакеты чаще, чем положено по спецификации. До тех пор, пока средняя скорость отправки пакетов укладывается в специфицированный интервал. Это же расширение описывает несколько дополнительных сообщений, которые клиенты могут использовать для описания происходящего с медиаданными: Negative Acknowledgement (NACK), Picture Loss Indication (PLI), Slice Loss Indication (SLI) и Reference Picture Selection Indication (RPSI).
Некоторые умозаключения об IP-телефонии — основной цифровой сигнал, кодеки, полоса пропускания
Приветствую вас, друзья!
В ходе изучения материалов к экзамену CCNA Voice родилась идея оформить некоторую полученную информацию в виде отдельной статьи. Преследуя при этом две цели: одна корыстная — получше самому разобраться в изучаемом материале и разложить всё по полочкам в своём сознании; вторая альтруистическая — поделиться полученными знаниями с теми, кому это мало мальски интересно.
В статье поведаю о процессах кодирования голоса, кодеках как таковых и расчётах полосы пропускания, необходимой для передачи голоса в IP-сетях
Про основной цифровой сигнал
Думаю, не стоит объяснять что, для передачи аналогового сигнала (коим является голос человека) по IP-сетям, необходимо этот самый сигнал преобразовать в последовательность единиц и нулей. Как это делается, прекрасно объяснил пользователь denis_g в своей многим понравившейся статье. Дабы не сойти за плагиатора и дабы не дублировать информацию, я просто оставлю это здесь. Вкратце суть такова — исходя из теоремы Котельникова (буржуи зовут её теоремой Найквиста) при использовании импульсно-кодовой модуляции для передачи голосового сигнала без потери качества достаточно передавать данные со скоростью 64 kbit/сек.
64 килобита в секунду — это то, что в современной цифровой телефонии называется основным цифровым сигналом.
На 32-х (30 голосовых + 2 служебных) основных цифровых сигналах построен первичный (самый маленький, простой) уровень в плезиосинхронной (почти синхронной) цифровой иерархии (PDH) — т.н. поток E1 (2048 кбит/сек). А сам основной цифровой сигнал порой называют нулевым уровнем. Стоит отметить, что в PDH существует второй (E2), третий (E3) и четвёртый (E4) уровни. Каждый последующий уровень мультиплексируется из четырёх предыдущих с добавлением кое-какой служебной информации, например E3=4*E2+сигнализация.
На PDH-технологии какое-то время (в 80-х годах) была построена вся цифровая телефония в мире. Но у неё было некоторое количество недостатков, самым существенным из которых была необходимость последовательного демультиплексирования потока высокого уровня для извлечения потоков более низкого уровня. То есть, к примеру, для извлечения одного E1 потока из потока E4 с целью маршрутизации его в другое место, необходимо было для начала разложить E4 на четыре E3, затем разобрать E3 на четыре E2, разобрать E2 на четыре E1, перенаправить E1 куда следует, собрать поток в обратном порядке и отправить дальше. Муторно в общем, да и ресурсов немерено съедало.
На смену технологии PDH пришла SDH (синхронная цифровая иерархия), которая и по сей день остаётся основным вариантом организации связи у сотовых операторов, да и сети наших двух магистральных провайдеров (ТТК, РТК) до сих пор основаны на SDH.
Тем не менее первичные уровни (E1) никуда не делись, и порой остаются единственным способом организации связи. Так например, все телефонные операторы в нашей стране для стыков друг с другом используют N-ное количество потоков E1.
Ага, отвлёкся. Вернёмся таки к IP-телефонии, то бишь к коммутации пакетов, а про коммутацию каналов пока забудем.
Про кодеки
Итак, у нас с вами есть первичный цифровой канал воплощением которого в IP-сетях стал кодек G.711. Этот стандарт стал де-факто самым популярным и нынче используется в таких протоколах как SIP и SCCP. Он использует полосу пропускания в 64 кбит/секунду и наверное знаком всем, кто имеет дело с современной IP-телефонией.
Стандарт был разработан в 70-х годах прошлого столетия и в данный момент срок патента на него истёк, и он является народным достоянием.
В стандарте описано два алгоритма кодирования — Mu-law (используется в Северной Америке и Японии) и A-law (используется в Европе и в остальном мире). Оба алгоритма являются логарифмическими, но более поздний a-law был изначально предназначен для компьютерной обработки процессов. (с) Wikipedia
Помимо общепризнанного G.711 существует ещё масса стандартов для кодирования\декодирования аудиосигналов. Наиболее популярными из них являются G.729, G.729a, G.726, G.728. Если оценивать их по занимаемой полосе пропускания, то увидим следующую картину:
G.729 — 8 кбит/сек
G.729а — 8 кбит/сек
G.726 — 32 кбит/сек
G.728 — 16 кбит/сек
Казалось бы, если они используют меньшую полосу, то почему не стали популярнее G.711? Дело в том, что полоса пропускания — не самый важный параметр кодека, важна ещё и скорость работы, и как следствие — загрузка DSP (Digital Signal Processor) — цифровго сигнального процессора, который в реальном времени отвечает за кодирование/декодирования сигнала.
Ещё одним немаловажным критерием определяющим успешность того или иного кодека является т.н. MOS (Mean Opinion Score, в русской литературе встречается как усреднённая субъективная оценка). Идея MOS очень проста: специально сформированной группе людей предоставляют возможность воспользоваться системой связи и просят поставить оценку от 1 (ужасно) до 5 (отлично). Усредненные данные такого исследования и называются MOS.
Так вот, для указанных мною кодеков оценки MOS имеют следующие значения:
G.711 — 4,1 (по некоторым источникам 4,45 для Мю-закона)
G.729 — 3, 92 (возможно бы и потягался с G.711, да вот процессорного времени много сжирает)
G.729а — 3,7 (этот кодек работает гораздо быстрее своего старшего брата, но как видим — в ущерб качества)
G.726 — 3,85
G.728 — 3,61
И вот совокупность всех этих факторов (пропускная способность, скорость работы, MOS) определяет главенство того или иного кодека в царстве цифрового кодирования сигналов.
К слову сказать, все эти стандарты (ну которые начинаются на G.) являются плодами деятельности международного консультационного комитета по телефонии и телеграфии (подразделения ITU — международного союза электросвязи) и по сути дела являются проприетарными. А в наше время сложно представить отсутствие свободных альтернатив у проприетраных стандартов. Так и в сфере кодирования аудиосигналов родился стандарт iLBC (internet Low Bitrate Codec), который использует15,2 Кбит/секунду и имеет оценку MOS 4,1. Именно эти факторы наряду с открытостью оказали влияние на то, что данный стандарт используется в Google talk, Yahoo messenger и всем нами любимом Skype.
Стоит отметить, что популярные IP-АТС (asterisk, cisco CME) поддерживают все эти кодеки, и вы всегда вправе сами определить, что будете использовать в вашей телефонной сети.
Про полосу пропускания
Расчётная пропускная способность — это тот параметр, который необходимо учитывать при планировании любой сети передачи данных, чтобы она была легко масштабируемой и у ваших пользователей не возникало лишних неудобств в процессе её эксплуатации. Повторюсь — любой сети, в том числе и сети VoIP.
Немаловажным параметром в данном частном случае является размер сэмпла (измеряется в миллисекундах). Размер сэмпла это тот параметр который определяет «количество» голосовой информации в IP-пакете — например, в один и тот же стандартных размеров пакет вы можете запихать один слог или два. Чем больше размер сэмпла, тем экономнее вы расходуете свою пропускную способность, но тем больше в разговоре будет слышна задержка (следствие работы цифрового процессора по кодированию/раскодированию).
Не знаю как в Asterisk (надеюсь кто-нибудь подскажет), но в Cisco CME (решение от Cisco в области IP-телефонии) при настройке параметров кодека к сожалению нет такого параметра — размер сэмпла, зато есть параметр, определяющий количество байт в сэмпле. Они друг с другом связаны простой формулой (линейная зависимость), и легко выражаются друг через друга. А вот и формула:
БвС = РС*ППК/8, где БвС — количество байт в сэмпле, РС — размер сэмпла в секундах, ППК — пропускания кодека в битах/сек. То есть если мы хотим чтобы при использовании кодека G.711 в одном пакете было, к примеру, 20 милисекунду разговора, то нам необходимо выставить значение параметра БвС=0,02*64000/8=160
Таким образом нам в наш UDP-фрагмент необходимо заложить 160 байт полезной информации. Ок, идём дальше.
Допустим мы используем классическую IP сеть, канальным протоколом для которой является Ethernet, плюс хотим это всё гонять в шифрованной сети VPN. Тогда к нашим 160 байтам добавятся ещё 18 байт служебной информации Ethernet. Добавляем сюда сетевой и транспортный уровень — заголовки IP, UDP и RTP (20+8+12 байт). И заворачиваем всё наше добро в IPSec — ещё плюс 50 байт. На выходе имеем пакет размером 268 байт.
Чтобы вычислить итоговую полосу пропускания нам необходимо умножить размер этого пакета на количество пакетов в секунду. С учётом того, что размер нашего сэмпла — 20 мс, то в одну секунду таких сэмплов будет 50. Умножая 50 на 268 видим что за одну секунду нам надо гонять 13400 байт или 107200 бит в секунду, то есть 107, 2 Кбита в секунду. А это уже почти в два раза больше чем изначальные 64 килобита! Именно из этого числа необходимо исходить при планировании своей сети.
Кодеки, используемые WebRTC
С WebRTC API возможно создание сайтов и приложений, позволяющих пользователям общаться в реальном времени, используя аудио и/или видео, а также передавать данные или другую информацию. Для общения, двум устройствам необходима возможность согласования использования кодеков, для каждой дорожки в потоке данных, для успешного взаимодействия и обмена медиаданными. В этом руководстве рассматриваются кодеки, которые требуются браузерам для этого, а также другие кодеки, которые поддерживаются некоторыми или всеми браузерами, поддерживающими WebRTC.
Безконтейнерные медиаданные
Эти две спецификации определяют свойства, которые должны поддерживаться каждым кодеком, а так же определённые функции для удобства использования, к примеру, функция эхоподавления. В этом руководстве происходит обзор кодеков, поддержка которых обязательна браузерам для реализации WebRTC, а так же иные (не обязательные) кодеки, поддерживаемые отдельными или всеми браузерами,.
Хоть сжатие всегда и необходимо при работе со средствами массовой информации в Интернете, оно имеет дополнительное значение при проведении видеоконференций, чтобы участники могли общаться без задержек и перерывов. Второстепенное значение имеет необходимость синхронизации видео и звука, чтобы движения и любая вспомогательная информация (например, слайды или проекция) были представлены одновременно с соответствующим звуком
Общие требования к кодекам
Прежде чем рассматривать возможности и требования, специфичные для кодеков, необходимо выполнить несколько общих требований, которые должны быть выполнены при любой конфигурации кодеков, используемой с WebRTC
Если SDP специально не указывает иное, веб-браузер, принимающий видеопоток WebRTC, должен иметь возможность обрабатывать видео со скоростью не менее 20 кадров в секунду при минимальном разрешении 320 пикселей в ширину и 240 пикселей в высоту. Рекомендуется, чтобы видео кодировалось с частотой кадров и размером не ниже этого, поскольку это, по сути, нижняя граница того, что WebRTC обычно должен обрабатывать.
SDP поддерживает независимый от кодеков способ указания предпочтительных разрешений видео (RFC 6236). Это делается путём отправки a=imageattr атрибута SDP для указания максимально допустимого разрешения. Однако отправителю не требуется поддерживать этот механизм, поэтому вы должны быть готовы получать носители с другим разрешением, чем вы запрашивали. Помимо этого простого запроса максимального разрешения, определённые кодеки могут предлагать дополнительные способы запроса конкретных конфигураций мультимедиа.
Поддерживаемые видео кодеки
WebRTC устанавливает набор базовых кодеков, которые требуются браузерам для работы. Некоторые браузеры могут поддерживать дополнительный набор кодеков.
Ниже приведены видеокодеки, которые требуются в любом полностью совместимом с WebRTC браузере, а также требуемые профили и браузеры, которые фактически соответствуют требованиям
Для получения дополнительной информации о соображениях, связанных с WebRTC для каждого кодека, см. Подразделы ниже, перейдя по ссылкам на название каждого кодека.
Полную информацию о том, какие видеокодеки и конфигурации требуется для поддержки WebRTC, можно найти в RFC 7742: Требования к обработке видео и кодекам WebRTC. Стоит отметить, что RFC охватывает множество требований, связанных с видео, включая цветовые пространства (sRGB является предпочтительным, но не обязательным цветовым пространством по умолчанию), рекомендации по функциям обработки веб-камеры (автоматическая фокусировка, автоматический баланс белого, автоматический уровень освещения) и так далее.
Предупреждение : Эти требования относятся к веб-браузерам и другим продуктам, полностью совместимым с WebRTC. Продукты, не относящиеся к WebRTC, которые в некоторой степени могут взаимодействовать с WebRTC, могут поддерживать или не поддерживать эти кодеки, хотя это рекомендуется в технических документах
В дополнение к обязательным кодекам, некоторые браузеры также поддерживают дополнительные кодеки. Они перечислены в таблице ниже
Другие видео кодеки
Кодек VP8
VP8, который мы описывали в общем в основной статье руководства по сетевым видеокодекам, имеет специфические требования, которым необходимо следовать при кодировании видео треков 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 и его функциональности найдёте в основном руководстве по видеокодекам.
Требования поддержки специальных параметров
AVC предлагает широкий спектр параметров для управления дополнительными значениями. Чтобы повысить надёжность совместного использования мультимедиа WebRTC на нескольких платформах и в разных браузерах, необходимо, чтобы конечные точки WebRTC, поддерживающие AVC, обрабатывали определённые параметры определённым образом. Иногда это просто означает, что параметр должен (или не должен) поддерживаться. Иногда это означает, что необходимо указать конкретное значение для параметра или разрешить определённый набор значений. А иногда требования более сложны.
Полезные, но необязательные параметры
Параметры с определёнными требованиями
Эти параметры являются необязательными, но имеют специальные требования при их использовании.
packetization-mode Все конечные точки обязательны для поддержания режима 1 (не чередующийся режим). Поддержка иных режимов пакетизации не обязательна, и сам параметр не обязателен для определения. sprop-parameter-sets Информация о последовательности и изображении для AVC может передаваться как внутри канала, так и вне его. При использовании AVC с WebRTC, информация должна передаваться в канале, поэтому значение параметра не включается в SDP.
Обязательные для определения параметры
Эти параметры обязательны к определению, при использовании AVC в WebRTC соединении.
Конкретное значение разработчику не известно, используется одно на всех, и устанавливается WebRTC. Начиная с RFC 6184 («RTP Payload Format for H.264 Video»), наличие profile-level-id необязательно.
Прочие требования
Если не указано иное, соотношение сторон пикселя составляет 1: 1, что указывает на то, что пиксели являются квадратными
Прочие замечания
Формат полезной нагрузки, используемый для AVC в WebRTC, описан в RFC 6184: RTP Payload Format for H.264 Video. Реализации AVC для WebRTC необходимы для поддержки специальных сообщений SEI : «заполнитель нагрузки» и «полное замораживание кадра», они используются для плавного переключения между несколькими входными потоками.
Поддерживаемые аудио кодеки
Спецификация RFC 7874 предписывает всем браузерам поддержку аудиокодеков, перечисленных в таблице :
Более подробное обсуждение использования кодеков в WebRTC следует ниже.
Спецификация RFC 7874 определяет список аудио кодеков, которые браузеры, реализующие WebRTC обязаны поддерживать; так же предоставляются рекомендации и требования для специфических аудио функциональностей, таких как удаление эхоподавление, шумоподавление и выравнивание звука.
Примечание : Список выше указывает на минимальный набор кодеков, который требуется реализовать браузерам (браузерному окружению), поддерживающих WebRTC. Такие браузеры могут поддерживать также и другие кодеки, что подвергает риску межплатформенной совместимости при использовании этих кодеков без проверки гарантированной работоспособности в часто используемых браузерах.
В дополнение к обязательным видеокодекам, некоторые браузеры поддерживают дополнительные кодеки, перечисленные в таблице:
| Наименование кодека | Совместимость с браузерами |
|---|---|
| G.722 | Chrome, Firefox, Safari |
| iLBC [1] | Chrome, Safari |
| iSAC [2] | Chrome, Safari |
Комфортный шум используется с 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 миллисекунд, в следующей таблице приведены рекомендуемые скорости передачи данных для различных типов носителей.
Скорость передачи может быть скорректирована в любое время. Во избежание перегрузки сети средняя скорость передачи звука не должна превышать доступную пропускную способность сети (за вычетом любых других известных или ожидаемых дополнительных требований к пропускной способности).
Кодек G.711
WebRTC требует, чтобы G.711 использовал 8-битные выборки со стандартной скоростью 64 кбит / с, хотя G.711 поддерживает некоторые другие варианты. WebRTC не предписывает использовать ни G.711.0 (сжатие без потерь), G.711.1 (широкополосная возможность), ни какие-либо другие расширения стандарта G.711
Из-за низкой частоты дискретизации и размера выборки качество звука G.711 в целом считается низким по современным стандартам, хотя оно примерно эквивалентно звучанию стационарного телефона. Обычно он используется в качестве наименьшего общего знаменателя, чтобы гарантировать, что браузеры могут установить аудио-соединение независимо от платформ и браузеров, или как запасной вариант в целом.
Определение и конфигурирование кодеков
Получение поддерживаемых кодеков
Если соединение находится в процессе запуска, используем событие icegatheringstatechange (en-US) для наблюдения за изменением статуса сборки кандидатов ICE (en-US) и при завершении, запрашиваем список кодеков.
Примечание : Два метода получения списков кодеков, показанные здесь, используют разные типы вывода в своих списках кодеков. Помните об этом при использовании результатов
Настройка списка кодеков
И наконец, вызываем метод setCodecPreferences() (en-US) объекта RTCRtpTransceiver (en-US) для определения того, что использование кодеков обеих сторон разрешено, в указанном порядке.
Функция preferCodec() вызываемая приведённым выше кодом, действует так, чтобы переместить указанный кодек в верхнюю часть списка (для приоритета во время согласования):
Кодеки по умолчанию
Если не определённо иное, кодеки по умолчанию (предпочтительные кодеки), запрашиваемые браузерными реализациями WebRTC, перечислены ниже
Предпочтительные для WebRTC кодеки основных веб-браузеров
VP8
Правильный выбор кодеков
Перед выбором кодека, который не является обязательным (VP8 или AVC для видео и Opus или PCM для аудио), следует серьёзно рассмотреть потенциальные недостатки: в особенности, если предполагается, что эти кодеки не широко доступны на всех устройствах, поддерживающих WebRTC.
Если вы предпочитаете кодек, отличный от обязательных, вы должны по крайней мере разрешить откат к одному из обязательных кодеков, если поддержка для кодека, который вы предпочитаете, окажется недоступна.
Аудио
Видео
При выборе поддерживаемого видеокодека (или набора кодеков) необходимо учитывать ряд факторов
Условия лицензирования
Внимание : Информация здесь не является юридической консультацией! Обязательно убедитесь в возможности ответственности, прежде чем принимать какие-либо окончательные решения, если существует вероятность возникновения проблем с лицензированием.
Энергопотребление и срок службы батареи
Производительность
К счастью, VP8 и AVC работают одинаково с точки зрения конечного пользователя и одинаково адекватны для использования в видеоконференцсвязи и других решениях WebRTC. Окончательное решение остаётся за разработчиком. Какой бы вариант вы ни выбрали, обязательно прочитайте информацию, представленную в этой статье, о любых конкретных проблемах конфигурации, с которыми вам, возможно, придётся столкнуться для этого кодека.
Последствия для безопасности
При выборе и настройке кодеков возникают интересные потенциальные проблемы безопасности. Видео WebRTC защищено с помощью Datagram Transport Layer Security (DTLS (en-US) ), но для мотивированной стороны теоретически возможно вывести величину изменения, которое происходит от кадра к кадру при использовании кодеков с переменной скоростью передачи (VBR), путём мониторинга скорости потока и её изменения во времени.Это может потенциально позволить злоумышленнику сделать вывод о содержании потока, учитывая приливы и отливы скорости передачи.