Пока первые early adopters примеряют в свои проекты наши новые видеоконференции (до 100 человек!) мы продолжаем рассказывать об интересном из мира передачи голоса и видео с участием браузера. Про видеоконференции тоже расскажем, но позже — когда накопится критическая масса пользователей и соберется интересная статистика. А сейчас я перевел и адаптировал для нас рассказ Dr. Alex о месте разных протоколов при передаче видео с низкими задержками. Рассказ по сути является ответом на другую статью, и автор вместе с рассказом указывает на ошибки и неточности, которые допустили его коллеги по цеху.

Данные по сети: сигнализация отдельно, видео отдельно

В современных системах, если вы видите видео в браузере, то видеопоток и сигнализация скорее всего будут обрабатываться разными серверами. Если с видео все понятно, то «сервер сигнализации» обеспечивает две штуки: «discovery» и «handshake». Первое, «discovery», это выбор способа передачи данных: IP-адреса, промежуточный сервер (если нужно). «Handshake» – про договориться между участниками передачи видео и звука: кодеки, разрешение, частота кадров, качество. Интересно, что в древнем Flash сигнализация и передача медиа не были разделены как в VoxIP или WebRTC и обеспечивались одним протоколом: RTMP.

Разница между протоколом сигнализации и транспортом сигнализации

Протокол сигнализации определяет язык, с помощью которого браузер и другие участники передачи видео будут договариваться о discovery и handshake. Это может быть SIP для discovery в VoIP или WebRTC, и он же с offer/answer для handshake. Давным-давно во Flash использовался RTMP/AMF. А при желании для WebRTC можно использовать не SIP, а необычный JSEP.

Протокол транспорта сигнализации из того же стека, но ниже: это то, каким образом будут физически передаваться пакеты протокола сигнализации. Традиционно для Flash + SIP использовали TCP или UDP, но сейчас в связке WebRTC + SIP все чаще можно встретить WebSockets. Транспортный протокол WebSockets занимает нишу TCP в браузерах, где нельзя использовать «чистые» TCP- и UDP-сокеты.

Полный стек сигнализации сейчас популярно описывать фразами вроде «SIP поверх веб-сокетов», «JSEP поверх веб-сокетов», устаревающее «SIP поверх TCP/UDP» или древнее «часть RTMP».

Программерский англицизм: медиакодек

Большинство протоколов стриминга видео завязаны на один или несколько кодеков. Полученное с камеры видео обрабатывается покадрово. А проблемы в сети, такие как снижение пропускной способности, потери пакетов или задержки между ними, решаются настройками кодека для каждого кадра. Чтобы вовремя узнавать о проблемах в сети, используются механизмы транспортных протоколов (RTP/RTCP) и механизмы оценки пропускной способности (REMB, Transport-CC, TIMBR). Одна из фундаментальных проблем Flash-видео была в том, что RTMP ни мог ни того, ни другого — поэтому видео просто прекращало играть при падении пропускной способности канала.

Еще один англицизм: протокол стриминга медиа

Определяет, как делить видеопоток на небольшие пакеты, которые пересылаются по сети транспортным протоколом. Обычно протокол стриминга еще обеспечивает механизмы работы с сетевыми проблемами: потери и задержки пакетов. Jitter buffer, retransmission (RTC), redundancy (RED) и Forward Error Correction (FEC).

Транспортный протокол передачи медиа

После того, как полученное с камеры видео разбито на небольшие пакеты, их нужно передать по сети. Используемый для этого транспортный протокол похож на сигнальный, но так как «полезная нагрузка» совершенно другая, одни протоколы подходят лучше других. К примеру, TCP обеспечивает доходимость пакетов, но это не добавляет стеку ценности, потому что похожие механизмы (RTX/RED/FEC) уже есть в стриминговом протоколе. А вот задержки на повторную отправку в TCP это явный недостаток, которого лишен UDP. Но при этом есть практика блокировки UDP как «протокола для торрентов».

Выбор протокола и сетевых портов раньше решался «хардкодингом», но сейчас мы используем такие протоколы как ICE в WebRTC, который позволяет договориться о портах и транспорте в каждом конкретном подключении. В ближайшем будущем возможно использование протокола QUIC (обратно совместимого с UDP), который активно обсуждается IETF и имеет преимущества над TCP и UDP по скорости и надежности. Наконец, можно упомянуть такие протоколы стриминга медиа, как MPEG-DASH и HLS, которые используют HTTP в качестве транспорта и получат преимущества от внедрения HTTP/2.0.

Безопасность передачи медиа данных

Некоторые движки защищают данные при передаче по сети: или сам медиапоток, или пакеты транспортного уровня. Процесс включает в себя ту самую передачу ключей шифрования, для чего используются отдельные протоколы: SDES в VoIP и DTLS в WebRTC. Последний имеет преимущество, так как кроме данных защищает и саму передачу ключей шифрования.

Что меня во всем этом смущает

Некоторые разработчики, например авторы вот этой статьи, помещают чисто транспортные протоколы WebSocket и QUIC на тот же уровень, что и WebRTC, Flash, или HLS. Для меня такая группировка выглядит странно, ведь три последних протокола — это история про стриминг медиа. Кодирование и разбиение на пакеты происходит до использования WebSocket или QUIC. Эталонная реализация WebRTC (libwebrtc/chrome) от Google и ORTC от Microsoft используют QUIC в качестве транспортного протокола.

Не менее удивительно отсутствие упоминания HTTP/2.0 как оптимизации для протоколов, основанных на HTTP, таких как HLS и MPEG-DASH. А упомянутый CMAF — не более чем формат файлов для HLS и MPEG-DASH, но никак не их замена.

Наконец, SRT является всего лишь транспортным протоколом. Он, конечно, добавляет ряд фишек по сравнению с основанными на файлах HLS и MPEG-DASH, но все эти фишки уже есть на другом уровне стека и реализуются в RTMP или WebRTC. Еще SRT разделяет кодирование медиапотока и статистики, что не позволяет кодеку держать эту информацию максимально близко друг от друга. Такое решение может негативно сказаться на возможности адаптировать пересылаемое видео под меняющуюся пропускную способность сети.

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