- PVSM.RU - https://www.pvsm.ru -

Как Chrome и Firefox договариваются о передаче двух видеопотоков

Как Chrome и Firefox договариваются о передаче двух видеопотоков - 1

Среди подводных камней WebRTC [1] один особенный. Это то, как браузеры договариваются между собой о передаче медиа-потоков. Кодеки, битрейты, разрешение видео, – вся вот эта история. Кода медиа-поток один — все хорошо. Но когда их два (а видео со звуком, это, на секундочку, два медиа-потока: один для видео, другой для звука), то мнения браузеров о формате описания ситуации резко разделяются. Сделать видеозвонок из Chrome в Firefox можно довольно легко. А вот видеозвонок со звуком — уже нет. Под катом небольшая история, почему так повелось, что запилили в новой Safari и какой особый путь у Microsoft Edge.

Комбайн на поле голосовых и видеозвонков

WebRTC — это комбайн. Множество протоколов и разных JavaScript API под одним названием, который делает разные штуки:

  • Захват видео с камеры и/или голоса с микрофона.
  • Кодирование и декодирование разными кодеками, которые поддерживает браузер.
  • Установка Peer-to-Peer подключения между браузерами с использованием подхода ICE и указанных серверов. STUN серверов для изучения топологии сети и TURN серверов, если не удалось пробить NAT и нужно подключаться через внешний сервер.
  • Передача видео и аудио по сети. Кроме того, анализ ширины канала и подстройка под него битрейта кодека.
  • Воспроизведение полученного.
  • Передача данных в UDP или TCP стиле.
  • Screen Sharing.

Самое сложное в этой истории – установить Peer-to-Peer подключение. Если это не локальное общение между вкладками, устройства не в одной сети или у них нет реальных IP-адресов с открытыми портами, то нужны какие-то промежуточные серверы, чтобы «договориться». Обычно эти сервера поднимает разработчик, который хочет воспользоваться WebRTC. За исключением STUN эхо серверов, которые отвечают на вопрос «какой у меня публичный IP» и есть публичные от Google.

В зависимости от того, что разработчик собирается передавать: голос, видео или произвольные данные, – установливается Peer-to-Peer подключение. WebRTC формирует текстовые пакеты «offer», «answer» и «ice candidate», которые разработчик должен как-то передавать между подключающимися друг к другу браузерами (обычно через собственный signaling сервер). В этих пакетах оба браузера описывают свои возможности и что будет происходить, а WebRTC пытается выбрать оптимальный способ подключения.

SDP-наследие телефонии

Пакеты, которыми WebRTC обменивается руками разработчика, используют формат SDP. Он очень старый, текстовый, пришел из телефонии (WebRTC старается минимизировать усилия разработчика при звонке из браузера в телефонные сети и обратно) и похож на HTTP. Вот так выглядит SDP-пакет «этот браузер хочет установить Peer-to-Peer подключение к другому браузеру, но пока не знает, что будет передавать по сети».

Если разработчик хочет начать/закончить передавать данные, голос или видео, то WebRTC сразу требует от него «renegotiation» – перезапуск Peer-to-Peer подключения, чтобы проверить оптимальность сетевого маршрута для передаваемых данных и передоговориться о кодеках. Вот так выглядит SDP-пакет, в котором WebRTC сообщает о желании передавать видео:

Быстро меняющийся стандарт

WebRTC с нами уже много лет и до сих пор в статусе «бета-версия». За последнее время JavaScript API было полностью переписано с коллбеков на промисы, поменялась работы с голосовыми и видео потоками, Microsoft скрафтила альтернативный API «oRTC». Много всего интересного произошло. А еще поменялся формат описания медиа потоков в SDP-пакете. Много лет использовавшийся «Plan B» с иерархической структурой был deprecated и заменен на «Unified Plan», в котором каждый поток задавался отдельной секцией в SDP пакете. Сравните.

Было:

Стало:

Chrome vs Firefox vs Edge vs Safari

Когда дело касается бета-версий веб-технологий, то их реализация в браузерах иногда сильно различается и может на годы отставать от текущей версии стандарта. Так случилось и с WebRTC. Много лет назад в Google Chrome сделали поддержку несколько медиа-треков в формате «Plan B» и до сих пор не поменяли реализацию на «Unified Plan». Соответствующий тикет [2] открыт пару лет назад, разработчики обсуждают, насколько это важно и переназначают тикет друг другу, но воз и ныне там. В Firefox, что характерно, реализован только Unified Plan, поэтому без проблем можно коммуницировать только один медиа трек: голос или видео без звука. Нужно больше? Добро пожаловать в мир адаптеров [3] и полифилов!

Microsoft Edge, изначально поддерживающий только свою собственную реализацию API «oRTC», в последних версиях добавил поддержку WebRTC API и Unified Plan. В Safari поддержка WebRTC будет только в следующей версии, бета которой уже доступна для разработчиков [4]. И, что печально, Plan B. Потому что делалось на основе Chromium.

Как делать кроссбраузерные звонки?

Как мы видим, Chrome, самый популярный браузер, остался с устаревшим форматом «Plan B». Там же Safari, мобильная версия которого живет в iPhone. Firefox и новый Microsoft Edge с новым «Unified Plan».

Для передачи голоса или видео без аудио это не играет никакой роли, а вот в случае нескольких медиа-треков придется вручную модифицировать SDP или воспользоваться адаптером [3]. Очень надеюсь, что рано или поздно все браузеры перейдут на Unified Plan. Но пока суровая реальность такова, что большинство Desktop и подавляющее большинство Mobile браузеров поддерживают «Plan B», а для совместимости с Firefox и Edge придется добавлять код. И много отлаживаться.

Картинка до ката взята отсюда. [5]

Автор: Voximplant

Источник [6]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/javascript/261441

Ссылки в тексте:

[1] подводных камней WebRTC: https://habrahabr.ru/company/Voximplant/blog/333486/

[2] тикет: https://bugs.chromium.org/p/chromium/issues/detail?id=465349

[3] адаптеров: https://github.com/jitsi/sdp-interop

[4] доступна для разработчиков: https://webkit.org/blog/7763/a-closer-look-into-webrtc/

[5] отсюда.: https://imgs.xkcd.com/comics/standards.png

[6] Источник: https://habrahabr.ru/post/334498/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best