Для кого

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

Основы WebRTC: что нужно знать

Если вы знакомы с тем, как работают видеозвонки в браузерах, смело пропускайте этот раздел (возможно и весь материал).

Большинство популярных платформ для видеозвонков (кроме Zoom) используют технологию WebRTC для имплементации своих продуктов в браузерах. Она дефакто является стандартом для создания сервисов коммуникации в реальном времени и поддерживается всеми современными браузерами.

WebRTC состоит из нескольких основных компонентов:

• API для захвата медиа: оно позволяет получить потоки аудио и видео с камеры и микрофона устройства.

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

• Кодеки и обработка медиа: WebRTC поддерживает различные аудио и видео кодеки для кодирования и декодирования медиа потоков. Также доступны инструменты для обработки медиа, включая эхоподавление, шумоподавление и автоматическое регулирование усиления.

• Безопасность: WebRTC использует шифрование для всех передаваемых данных и медиапотоков для обеспечения конфиденциальности и безопасности в сети.

Как работает WebRTC:

• Сигналлинг: Для начала обмена медиаданными между пирами необходим процесс сигналлинга, который не входит напрямую в спецификацию WebRTC, оставляя разработчикам свободу выбора метода сигнализации (через WebSocket, REST API и др.). Сигналлинг используется для обмена метаинформацией: типа медиа, параметров кодеков, сетевых адресов и портов, необходимых для установления соединения.

• Установление соединения: После обмена начальной информацией, применяются механизмы ICE (Interactive Connectivity Establishment) с использованием STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT) серверов для обхода NAT (сетевого адресного преобразователя) и установления прямого соединения между пирами.

• Передача данных: После установления соединения начинается передача потоковых данных между пирами через защищённое соединение, используя RTP (Real-time Transport Protocol) для медиа и SCTP (Stream Control Transmission Protocol) для данных.

• Адаптация и обработка: В процессе передачи WebRTC может адаптироваться к изменяющимся сетевым условиям, изменяя качество потока для оптимизации производительности. Также происходит обработка медиа, включая фильтрацию шума, эхоподавление и другие функции для улучшения качества связи.

Далее в трех разделах я расскажу об инструментах/сервисах и демо, которые помогли мне изучить эту технологию в практическом ключе, а затем поделюсь opensource продуктами, которые позволят разобраться в деталях и на практике, как работает WebRTC в больших продуктах.

Инструменты

Chrome Tools

Браузер Chrome предоставляет несколько мощных инструментов для анализа WebRTC:

• chrome://webrtc‑internals

• chrome://webrtc-logs

Webrtc-internals

Начнем с chrome://webrtc-internals. Наверное, это самый базовый инструмент, с которым знакомятся в самом начале пути при работе с WebRTC. Там можно найти кучу информации о текущих соединениях, что помогает при дебаггинге и реверс инжиниринге других продуктов.

Здесь можно узнать какие кодеки используются существующими сервисами видеозвонков. Например, присоединившись к звонку в google meets и открыв chrome://webrtc-internals, можно увидеть, что google meets использует AV1 видеокодек.

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

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

Больше информации можно найти здесь: https://getstream.io/blog/debugging-webrtc-calls/ 

Webrtc-logs

Этот раздел используется гораздо реже, так как содержит более подробную информацию, и необходим при более детальном анализе сложных проблем. В отличии от chrome://webrtc-internals он содержит логи в текстовом формате о предыдущих сессиях. Таким образом можно посмотреть логи для уже завершенного звонка, chrome://webrtc-internals такое не умеет.

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

Часть информации из этих логов можно использовать для построения метрик, похожих на те, что есть в chrome://webrtc-internals. К сожалению, Chrome не предоставляет такой функциональности, однако существует открытый продукт, который помогает в решении этой задачи.

Этот инструмент идеально подходит, если произошла проблема на одном из реальных звонков, и когда анализ в реальном времени недоступен. Данные логи по дефолту сохраняются в директорию …/Google/Chrome/Default/WebRTC Logs/<log_name>.gz, что позволяет собирать эти данные с нетехнических пользователей, кто готов помочь в анализе проблемы.

TestRTC

Ссылка

analyzeRTC от сервиса testRTC находится в чем-то вроде бета тестирования. Вся платформа - платная, но проанализировать ваш дамп можно можно совершенно бесплатно. В целом ничего нового после chrome://webrtc-internals здесь найти не получится, так как источник данных у них одинаковый. Но вот отображение этих данных в analyzeRTC гораздо лучше. 

Например, информация о видеопотоке представлена особенно удобно:

А еще здесь можно посмотреть общую оценку звонка и качества аудио:

Score — это общий балл сценария от 0 до 10, учитывающий аудио и видео по всем каналам. Он помогает оценить производительность службы и требует субъективной интерпретации на основе опыта с приложением. MOS (Mean Opinion Score) оценивает только аудиоканалы сценария, представляя субъективное качество звука по шкале от 1 до 5, где выше 3 считается хорошим качеством, от 2 до 3 — удовлетворительным, а ниже 2 — плохим.

Короткий видео туториал можно найти здесь

Демонстрационные приложения

Official Demos

Ссылка

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

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

SDP Explanation

Ссылка

Далее поговорим об SDP - протоколе, использующимся для установки соединения перед началом звонка. Сам формат описан в RFC 8866, он предназначен для того, чтобы перед звонком согласовать параметры медиапотока, такие как форматы кодеков, разрешение видео и типы медиа (аудио, видео, данные), необходимые для установления соединения и обмена медиаданными.

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

В интерактивном режиме можно прочитать про каждую строчку из SDP протокола, экономя время на поиск объяснений в RFC.

Media test

Ссылка

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

Здесь можно экспериментировать с различными аспектами видеопотоков, такими как создание потока с нуля или с камеры, выбор разрешения видео и частоты кадров. Можно также применять трансформации к кадрам, например, изменение цвета, конвертация в черно-белый формат, кодирование/декодирование в H.264, и добавление наложений для отслеживания времени отображения в элементе <video>.

После экспериментов можно узнать результаты обработки, включая время обработки на разных этапах (например, преобразование в RGBX, добавление фона и наложений), время отображения кадра, общее время от начала до конца обработки, а также время ожидания в очереди. Каждый показатель включает количество обработанных кадров, среднее, медианное, минимальное и максимальное значения времени обработки. Эти данные помогают оценить производительность и эффективность обработки видео в приложении и понять, сколько “стоит” каждая операция.

Слайды от авторов.

Simulcast Playgrounds

Первая

Ссылка

Еще одно демо, в этот раз неофициальное, но все еще с открытым исходным кодом. Здесь мы фокусируемся на Simulcast. Это такой подход, который позволяет участникам конференции с разной пропускной способностью сети получать от вас видео в разном разрешении (чем больше пропускная способность - тем лучше разрешение). 

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

Если вы никогда не слышали про Simulcast лучше потратить немного времени на теорию прежде чем подходить к изучению этого демо. Я бы рекомендовал посмотреть на этот материалы на хабре:

https://habr.com/ru/companies/flashphoner/articles/564714/ (Ищите по ключевому слову ‘simulcast’, если нет желания читать всю статью)

Вторая

Ссылка

Другая вариация демо simulcast, совсем не гибкая, зато сильно более репрезентативная. Можно увидеть стандартную конфигурацию с тремя параллельными потоками и метриками из chrome://webrtc-internals. Выглядит более привычно и не отвлекает дополнительными настройками. Отличное дополнение к тому инструменту, что описан выше.

Pagination Demo App

Ссылка

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

Там можно разобраться в том, как правильно управлять входящими видео/аудио потоками от других участников звонка. Это особенно важно при большом количестве участников, когда все они не умещаются на экране и нужно добавлять другие страницы. Нету никакого смысла принимать поток данных от участников, находящихся на других страницах, и нужно правильно это обработать.

Самый интересный компонент это ‘components/PaginatedGrid.js’, в нем находится практически вся логика по управлению отрисовки и управления потоками. Описание исходного кода и вообще всего приложения можно найти в официальной документации.

Opensource продукты

Jitsi Meet

GitHub репозитоий

Один из самых популярных продуктов с открытым исходным кодом для разработки связанной с видеозвонками в браузере. На самом деле jitsi содержит не только веб клиент, но и все остальные необходимые части для построения всего продукта. Это прекрасный ресурс для того, чтобы очень глубоко погрузиться в тему RTC, но на это уйдет уйма времени, так как jitsi очень гибкий и довольно старый продукт с огромной кодовой базой. 

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

Janus

GitHub репозиторий

Janus Gateway - это открытый сервер WebRTC, решающий похожую проблему. Но в отличие от Jitsi Meet, Janus сосредоточен на предоставлении низкоуровневого API для управления медиа-потоками, что делает его более гибким, но потенциально и более сложным в использовании для новичков. Этот продукт так же больше подходит для тех, кого интересует серверная часть, нежели клиентская, с которой лучше поможет Jitsi Meet.

Для Janus доступна очень подробная документация и целая куча отдельных демо (которые кстати не вошли в предыдущий раздел, но я все равно рекомендовал бы с ними ознакомиться). 

Mediasoup

GitHub репозиторий

MediaSoup представляет собой еще один сервер WebRTC. В отличие от Jitsi Meet и Janus Gateway, Он решает те же задачи, что и Janus Gateway с тем отличием, что mediasoup имеет как серверную, так и клиентскую часть.

Другие продукты

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

Вместо выводов

Никаких рассуждений или нововведений в статье не было, а значит и выводов никаких сделать не получится. Я лишь описал все инструменты, которые я использовал, уверен, что это далеко не полный список. Буду благодарен за ваши рекомендации инструментов и сервисов, которые я пропустил, в комментариях!