кодек для приложений реального времени
Обзор пакета кодеков K-Lite Codec Pack
Вне зависимости от версии Windows, проблема одна и та же: для просмотра фильма нужны кодеки, которых нет в составе операционной системы. Поэтому пакет K-Lite Codec Pack, с одной стороны, в представлении не нуждается: многие пользователи скачивают его сразу же после установки Windows, чтобы одним махом улучшить поддержку популярных форматов мультимедиа.
С другой стороны, редко кто удосуживается изучить содержимое данного пакета (срабатывает принцип «лишь бы все работало»), хотя для этого есть основания. Так, в состав K-Lite включены утилиты, которые можно использовать для диагностики, решения частных проблем, связанных с работой кодеков.
Кроме того, пакет K-Lite не только добавляет широкую поддержку форматов медиа, но и позволяет полностью управлять процессом обработки. На этапе установки позволяется выбрать нужные компоненты, а также указать предпочтительные фильтры и декодеры. От их правильной настройки зависит качество воспроизведения и скорость обработки.
Все эти моменты будут затронуты в данном обзоре.
Основные преимущества K-Lite Codec Pack
K-Lite Codec Pack имеет множество сильных сторон, ограничимся перечислением ключевых моментов:
Внутренняя совместимость компонентов
Дистрибутив K-Lite всегда тестируется на совместимость специалистами. При самостоятельной установке кодеков легко прийти к ситуации «Codec hell» («Ад кодеков»), поскольку многие фильтры между собой не уживаются. Для устранения конфликтов нужно искать причину «зла» и с помощью специальных утилит удалять тот или иной компонент.
Хорошая совместимость с Windows
Помимо вышеупомянутого отсутствия конфликтов, пакет легко полностью удалить из системы без следов. При установке K-Lite проверяет наличие в системе других кодеков и предлагает их использование при установке среди прочих вариантов. Также на этапе установки производится поиск неисправных кодеков и предлагается их исправить.
Гибкая настройка
Для скачивания доступно 5 вариантов пакета с различной комплектацией, также предлагается 3 режима инсталляции и профили.
Для каждого мультимедиа формата можно выбрать подходящий декодер из доступных вариантов, по умолчанию K-Lite подбирает наиболее оптимальный. Для пользователей Windows 7 и 8 предусмотрена специальная утилита Preferred Filter Tweaker for Windows 7 and 8 для настройки предпочтительных кодеков в обход ОС.
Регулярные обновления
Пользователю не нужно следить за обновлением каждого аудио- или видеокодека или других компонентов: K-Lite всегда содержит актуальные версии.
Сборки K-Lite
Есть другой способ просмотра информации по сборкам, доступный на сайте пакета K-Lite в виде сравнительных таблиц: по возможностям и по комплектации. По сути, если вас интересует конкретная функция или формат, то и сравнивать ничего не нужно.
Установка
Возможно три режима установки — простой, обычный и расширенный, в зависимости от чего изменяется количество настроек для компонентов, входящих в состав пакета.
На следующем шаге — выбор установочного профиля. Он влияет не только на количество компонентов, но и на предпочтительные настройки. Например, «LAV for everything» подразумевает, что декодирование видео по возможности будет производиться с помощью LAV Video. «Lot of stuff» — инсталляция максимального количества компонентов.
Вы не сможете установить несколько кодеков или фильтров для воспроизведения одного формата, так как это неизбежно вызвало бы конфликт. Опция «Use system default» обозначает, что инсталлятор уже обнаружил кодек, который не относится к составу K-Lite: например, включенный в состав ОС или установленный ранее.
Далее, инсталлятор предлагает удалить «битые» (некорректно удаленные из системы) кодеки и фильтры DirectShow, которые, в частности, являются причиной появления ошибок в видеоплейере.
На последнем шаге («Hardware Acceleration») — настройки аппаратного ускорения видео. Очень желательно ознакомиться с небольшим справочным документом по описанию настроек (кнопка «Help» внизу окна).
Так, согласно справке, на быстром процессоре выставляем стандартные настройки («Use software decoding»), на видеокартах NVIDIA — CUVID или LAV DXVA2, на AMD — LAV DXVA2, при использовании плеера Media Player Classic HomeCinema — декодер DXVA.
Состав K-Lite
Для того, чтобы «расшифровать» этот список, нужно пояснить смысл некоторых терминов (см. ниже). Более наглядно работа сплиттера, фильтров и парсеров может быть отображена программой GraphStudioNext, которая входит в состав K-Lite. Для примера проще всего открыть любой медиафайл с помощью команды «File — Render Media File…». Процесс обработки файла будет продемонстрирован на схеме.
DirectShow — это фреймворк от Microsoft, который функционирует в Windows и является средой для воспроизведения форматов аудио и видео и ввода/вывода на устройства. Некоторые форматы поддерживаются DirectShow изначально, список меняется с каждой версией Windows. На данный момент DirectShow вытесняется фреймворком Media Foundation, который интегрирован в Windows 7 и Windows 8.
Сплиттеры (англ. «source filters», дословно — фильтры источника) отделяют от контейнера аудио и видео для дальнейшей обработки декодерами. Нужно понимать, что файл для воспроизведения представляет собой контейнер, который часто ошибочно называют форматом видео.
Фильтры декодирования видео и аудио DirectShow, или фильтры преобразования, добавляют поддержку дополнительных форматов файлов, которые могут воспроизводиться любым видеоплейером.
Примером фильтров можно назвать популярный декодер ffdshow, который работает на основе открытых библиотек. Он позволяет воспроизводить Xvid, DivX и H.264 — а это, пожалуй, большинство случаев, с которыми приходится иметь дело. В состав ffdshow входят фильтры (не путать с фильтрами DirectShow), которые позволяют управлять воспроизведением в режиме реального времени: применять фильтры, изменять размеры, цвет и т. п.
Разработчики K-Lite прямым текстом советуют выбирать декодер LAV ввиду его большей производительности и стабильности, а ffdshow — только в том случае, если необходима экстра-функциональность.
Наравне с LAV Video, входит во все пакеты, остальные фильтры опциональны и могут быть заменяемы.
Аналогично, аудиофильтры декодируют аудиоформаты, отделенные от контейнера сплиттером. В их числе популярная библиотека AC3Filter, которая добавляет поддержку AC3 и DTS вместе с инструментами для настройки многоканального аудио.
Задача парсера — вывод сигнала на устройство после его декодирования.
Плеер Media Player Classic
Безусловно, при установке K-Lite практически любой проигрыватель (GOM Player, LightAlloy, Zoom Player и т. п.) будет работать с требуемыми форматами. Однако в случае с K-Lite все же предпочтительно использовать Media Player Classic, который не входит только в сборку Basic. Данный видеопроигрыватель лучше всего оптимизирован под этот пакет, к тому же, в составе K-Lite он находится в модифицированном виде.
Существует два плейера: Media Player Classic Home Cinema и Media Player Classic Regular, который является ответвлением проекта Home Cinema. Несмотря на то, что базируются они на одной платформе, различия есть.
Относительно плеера Classic Regular можно сказать только то, что он, в сравнении с Home Cinema, менее функционален. Для знакомства с ним нужно установить сборку Mega и при установке указать Media Player Classic Regular в качестве предпочитаемого плеера.
Среди прочих приятных дополнений Media Player Home Cinema: вывод изображения на несколько мониторов, аппаратное декодирование H.264, поддержка множества форматов субтитров, присутствие локализации, в том числе и русской. В оригинальном дистрибутиве Home Cinema, который можно скачать на сайте разработчиков, уже предусмотрены декодеры (поэтому плеер может работать и автономно, без установки K-Lite). В описании K-Lite же указано, что встроенные в плеер кодеки были заменены более эффективными — теми, которые доступны на выбор при установке K-Lite.
Утилиты
После установки K-Lite возникает необходимость в тонкой настройке кодеков. Найти вспомогательные утилиты можно в директории с установленным пакетом K-Lite, папка Tools.
Codec Tweak Tool
Основные настройки K-Lite собраны в оболочке Codec Tweak Tool. В настройках вы можете удалить битые кодеки и фильтры (которые были неправильно установлены или оставили следы в реестре), перезарегистрировать фильтры, сбросить настройки на изначальные, сформировать лог из содержимого пакета, иногда это требуется для диагностики.
Наиболее интересная секция — «Configuration», здесь собраны настройки всех установленных фильтров (аудио-, видео-, source фильтры (сплиттеры)). В принципе, то же самое нетрудно проделать через параметры видеоплейера, но это был бы не самый удобный способ.
Codec and Filter Management позволяет активировать и деактивировать ненужные фильтры и кодеки, в т. ч. входящие в состав ОС. Дополнительно, по аналогии с установкой K-Lite, для каждого формата можно указать предпочитаемые сплиттеры.
Preferred Filter Tweaker for Windows 7 and 8
Пользователям Windows 7 и Windows 8 нужно обратить внимание на утилиту Win7DSFilterTweaker. Ее необходимость проявляется в том, что в этих ОС своя система декодирования аудио и видео — Media Foundation. Встроенные возможности этого фреймворка не могут быть перекрыты сторонними фильтрами без внесений изменений в реестр. Для этого, собственно, и предназначается эта утилита. С ее помощью можно не только указать предпочтительные декодеры, но также отключить неиспользуемые, вплоть до деактивации Media Foundation.
MediaInfo
Утилита, с помощью которой можно узнать детальную информацию о файле: битрейт, разрешение, контейнер, форматы аудио и видео, компрессия. Технические данные будут полезны, если нужно будет перенастроить фильтры или установить недостающий кодек. Данная программа встроена в Media Player Classic и доступна как вкладка «Mediainfo», пункт «Свойства» в контекстном меню.
GraphStudioNext
Очень познавательная утилита для анализа аудио и медиафайлов. После обработки содержимого GraphStudioNext в виде схемы показывает процесс обработки, который проходит файл перед выводом на экран и динамики. Все это зависит от конкретной конфигурации кодеков в пакете. Поэтому GraphStudioNext будет полезно использовать для диагностики при появлении проблем с воспроизведением файла. Кроме того, каждый компонент на схеме кликабелен и открывает настройки кодека или сплиттера.
VobSubStrip
Редактирование субтитров в формате IDX — можно удалить ненужные потоки из списка и пересохранить.
Внутренности протокола, которым браузеры передают голос и видео
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).
Кодеки, используемые 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), путём мониторинга скорости потока и её изменения во времени.Это может потенциально позволить злоумышленнику сделать вывод о содержании потока, учитывая приливы и отливы скорости передачи.