«Вашу маму и там и тут передают»: какие протоколы реализуют низкую задержку

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

Задержка в общем понимании — это разница во времени между тем, когда конкретный видеокадр был захвачен устройством (камерой, плейаутом, кодером, и т. д.) и тем, когда этот кадр был проигран на дисплее у конечного пользователя.

Низкая задержка не должна снижать качество передачи сигнала, а это значит, что требуется минимальная буферизация при кодировании и мультиплексировании с сохранением плавной и чёткой картинки на экране любого устройства. Еще одно обязательное условие — гарантированная доставка: все потерянные пакеты должны быть восстановлены, а передача в открытых сетях не должна вызывать проблем.

Всё больше сервисов мигрируют в облако, чтобы сэкономить на арендуемых площадях, электроэнергии и покупке железа. Это повышает требования к низкой задержке с высоким RTT (Round Trip Time — время пересылки сообщения туда и обратно). Это особенно актуально при передаче больших битрейтов во время трансляции HD и UHD видео — например, если облачный сервер стоит в США, а потребитель контента находится в Европе.

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

Наверное, первой технологией, которая активно применялась в современном телевещании и с которой связывают термин «низкая задержка», было вещание мультикаст трафика с MPEG Transport Stream содержимым по UDP. Обычно подобный формат выбирали в закрытых ненагруженных сетях, где вероятность потерянных пакетов сводилась к минимуму. К примеру, вещание с кодера на модулятор на головной станции (зачастую – в рамках одной серверной стойки), либо вещание IPTV по выделенной медной или оптоволоконной линии с усилителями и повторителями. Подобная технология используется повсеместно и показывает отличные показатели задержки. Отечественные компании достигали задержки на кодирование, передачу данных и декодирование с использованием сети Ethernet не более 80 мс при 25 кадрах в секунду. С более высокой частотой кадров – и того меньше.

На первой картинке – сигнал с карты захвата SDI. На второй – сигнал, прошедший стадию кодирования, мультиплексирования, вещания, приёмки и декодирования. Как видно, второй сигнал приходит позже на одну единицу измерения (в данном случае – 1 кадр, который равен 40 мс, т. к. здесь 25 кадров в секунде). Подобное решение применялось на Кубке Конфедераций 2017 и Чемпионате Мира FIFA 2018, только ко всей архитектурной цепочке добавлялся модулятор, распределённая DVB-C сеть и телевизор в качестве конечного устройства. Общая задержка составила 220–240 мс.

А если сигнал проходит через внешнюю сеть? Там его ждут различные испытания: помехи, шейпирование, нагруженный трафиком канал, ошибки оборудования, повреждённые кабели, проблемы программного уровня. В таком случае требуется не только низкая задержка, но и переотправка потерянных пакетов. В случае с UDP с этим неплохо справляется технология Forward Error Correction с избыточностью (дополнительным проверочным трафиком или оверхедом). При этом неизбежно увеличиваются требования к пропускной способности сети, и, следовательно, задержка и объём избыточности в зависимости от ожидаемого процента потерянных пакетов. Процент восстановленных благодаря FEC пакетов всегда лимитирован, а при передаче по открытым сетям он может существенно изменяться. Таким образом, чтобы надёжно передавать большие объёмы данных на длительные расстояния, приходится добавлять к ним десятки процентов избыточного трафика.

Рассмотрим технологии, которые базируются на протоколе TCP (достоверной доставке). Если контрольная сумма полученного пакета не соответствует ожидаемому значению (выставленному в заголовке TCP пакета), то этот пакет отправляется повторно. А если на стороне клиента и сервера не поддерживается спецификация Selective acknowledgment (SACK), то происходит переотправка всей цепочки TCP пакетов с потерянного и до последнего полученного на сниженной скорости.

Ранее протокол TCP избегали, когда речь заходила про низкую задержку при вещании в прямом эфире, поскольку она вырастала из-за проверки на ошибки, пересылки пакетов, трехстороннего рукопожатия, «медленного старта» и предотвращения переполнения канала (TCP Slow Start и congestion avoidance phase). При этом задержка до начала передачи даже при широком канале может достигать пятикратной круговой задержки (RTT), а увеличение пропускной способности влияет на задержку крайне незначительно.

Также приложения, которые вещают по TCP, не получают полную обратную связь по состоянию соединения (таймауты, размеры окна для перевещания), т. к. передача TCP идёт единым сплошным потоком, и прежде, чем выдать ошибку, приложение может зависнуть на неопределённое время. А протоколы более верхнего уровня не имеют возможности тюнинга ТСP для минимизации проблем вещания.

При этом существуют протоколы, которые эффективно работают поверх UDP даже в открытых сетях и на длительные расстояния.

Рассмотрим и сравним различные реализации протоколов. Из протоколов и форматов передачи данных, которые базируются на TCP, отметим RTMP, HLS и CMAF, а из базирующихся на UDP — WebRTC и SRT.

RTMP был проприетарным протоколом от Macromedia (теперь принадлежит Adobe) и был очень популярен, когда приложения на базе Flash пользовались успехом. Имеет несколько разновидностей с поддержкой шифрования TLS/SSL, и даже вариацией на базе UDP – RTFMP (Real Time Media Flow Protocol, использовался для соединений точка-точка). RTMP разбивает поток на фрагменты, размер которых может динамически меняться. Внутри канала пакеты, которые относятся к аудио и видео, могут чередоваться и мультиплексироваться.

RTMP формирует несколько виртуальных каналов, по которым передаются аудио, видео, метаданные и др. Большинство CDN`ов уже не поддерживают RTMP как протокол для раздачи трафика конечным клиентам. Однако у Nginx есть собственный RTMP модуль с поддержкой простого (plain) RTMP протокола, который работает поверх TCP и использует 1935 порт по умолчанию. Nginx может выступать в качестве RTMP сервера и раздавать контент, который он получает от RTMP-стримеров. Кроме того, RTMP по-прежнему пользуется популярностью для доставки трафика на CDN, а в дальнейшем трафик передаётся по другим протоколам.

Сегодня технология Flash устарела и практически не поддерживается: браузеры либо сокращают её поддержку, либо полностью блокируют. RTMP не поддерживает HTML5 и не работает в браузерах (воспроизведение возможно с помощью Adobe Flash плагина). Для обхода брандмауэров используют RTMPT (инкапсуляцию в HTTP запросы и использование стандартного 80/443 вместо 1935), но это значительно влияет на задержку и избыточность (по разным оценкам, RTT и общая задержка увеличиваются на 30%). RTMP по-прежнему популярен, например, для вещания на Youtube или в социальных сетях (RTMPS для Facebook).

Ключевые минусы RTMP — отсутствие поддержки HEVC/VP9/AV1 и ограничение на две аудиодорожки. Также RTMP не содержит временных меток в заголовках пакетов. RTMP содержит лишь метки, рассчитанные исходя из фреймрейта, поэтому декодер не знает, когда именно декодировать этот поток. Это обязывает принимающий компонент ровно выдавать самплы на декодирование, поэтому приходится увеличивать буфер на величину джиттера пакетов.

Другой проблемой RTMP является пересылка потерянных пакетов TCP, которая описана выше. Подтверждения получения (ACKs) не уходят сразу к отправителю, чтобы поддерживать низкий уровень обратного трафика. Только после получения цепочки пакетов отправляется позитивное (ACKs) или негативное (NACKs) подтверждение вещающей стороне.

По разным оценкам задержка при вещании с помощью RTMP составляет минимум две секунды при полном тракте кодирования (RTMP кодер → RTMP сервер → RTMP клиент).

Common Media Application Format (CMAF) — протокол, разработанный экспертной группой по движущимся изображениям по заказу Apple и Microsoft для адаптивного вещания (с адаптивным битрейтом, который меняется исходя из изменения пропускной способности всего сетевого тракта) поверх HTTP. Обычно HTTP Live Streaming (HLS) от Apple использовал MPEG Transport Stream, а MPEG DASH от Microsoft — фрагментированный MP4. В июле 2017-го спецификация CMAF увидела свет. В CMAF фрагментированные MP4 сегменты (ISOBMFF) передаются по HTTP с двумя разными плейлистами для одного контента для соответствующего плеера: iOS (HLS) или Android/Microsoft (MPEG DASH).

По умолчанию CMAF (как HLS и MPEG DASH) не предназначен для вещания с низкой задержкой. Но внимание и интерес к низкой задержке постоянно растет, так что некоторые производители предлагают расширение стандарта, например Low Latency CMAF. Это расширение предполагает, что и вещательная, и приёмная стороны поддерживают два метода:

Чтобы переключаться между профилями, необходима буферизация (минимум 2 секунды). Учитывая это, а также потенциальные проблемы в доставке, разработчики стандарта заявляют о потенциальной задержке менее трех секунд. При этом сохраняются такие киллер-фичи, как масштабирование через CDN с тысячами одновременных клиентов, шифрование (вместе с поддержкой Common Encryption), поддержка HEVC и WebVTT (субтитров), гарантированная доставка и совместимость с разными плеерами (Apple/Microsoft). Из минусов можно выделить обязательную поддержку LL CMAF на стороне плеера (поддержка фрагментированных сегментов и продвинутая работа с внутренними буферками). При этом в случае несовместимости плеер по-прежнему может работать с контентом в рамках спецификации CMAF со стандартной задержкой, типичной для HLS или DASH.

В июне 2019 года Apple опубликовала спецификацию для Low Latency HLS.

Она состоит из следующих составляющих:

Ожидаемая задержка при полной поддержке этой спецификации CDN`ом и плеером – менее трех секунд. HLS очень широко используется для вещания в открытых сетях благодаря отличной масштабируемости, поддержки шифрования и адаптивного битрейта, кросс-платформенности и обладает обратной совместимостью, что полезно, если плеер не поддерживает LL HLS.

Web Real Time Communications (WebRTC) — опенсорсный протокол, разработанный Google в 2011 году. Используется в Google Remote desktop, Google Duo, Google Meet, Zoom, Hangouts, Youtube live (вещание из браузера), Stadia cloud gaming. WebRTC — это набор стандартов, протоколов и JavaScript программных интерфейсов, который реализует сквозное шифрованное благодаря DTLS-SRTP в рамках peer-to-peer соединения. При этом технология не использует сторонние плагины или ПО, проходя через брандмауэры без потери качества и задержки (например, при использовании видеоконференций в браузерах). При вещании видео обычно используется реализация WebRTC поверх UDP.

Протокол работает следующим образом: хост отправляет запрос на соединение к пиру, с которым хочет соединиться. Пока соединение между пирами не установлено, они общаются между собой через третье лицо — сигнальный сервер. Далее каждый из пиров обращается к STUN серверу с вопросом «Кто я?» (как ко мне попасть извне?). При этом существуют публичные гугловские STUN сервера (например, stun.l.google.com:19302). STUN сервер отдаёт список IP и портов, по которому можно достучаться до текущего хоста. Из этого списка формируются ICE кандидаты. Вторая сторона делает то же самое. Происходит обмен ICE кандидатами через сигнальный сервер, и уже на этом этапе устанавливается peer-to-peer соединение, т. е. формируется одноранговая сеть.

Если прямое соединение установить невозможно, то в качестве релей/прокси сервера выступает так называемый TURN сервер, который также заносится в список ICE-кандидатов.

За мультиплексирование, отправку, контроль перегрузок и надёжную доставку отвечают SCTP (данные приложения) и SRTP (аудио- и видеоданные) протоколы. Для обмена «рукопожатиями» и дальнейшего шифрования трафика используется DTLS.

Используются видеокодеки VP8, VP9, H.265, AV1 и аудиокодеки Opus, G.711, iLBS, iSAC. Максимальное поддерживаемое разрешение: до 4K, 60 кадров в секунду.

Минусом WebRTC технологии в плане безопасности считается определение реального IP даже за NAT`ом и при использовании сети Tor или прокси сервера. WebRTC не предназначен для большого количества одновременных пиров для просмотра (тяжело масштабируется) в силу архитектуры соединений, а также практически не поддерживается CDN`ами на текущий момент. Наконец, WebRTC уступает своим коллегам по качеству кодирования и максимальному объёму передаваемых данных.

Задержка, заявляемая компанией Google, – меньше секунды. При этом данный протокол может использоваться не только для видеоконференций, а, например, для передачи файлов.

Secure Reliable Transport (SRT) — протокол, разработанный компанией Haivision в 2012 году. Протокол работает на базе UDT (UDP-based Data Transfer Protocol) и технологии восстановления пакетов ARQ. Поддерживает шифрование AES-128 и AES-256. Помимо режима listener (server) поддерживает режимы caller (client) и rendezvous (когда обе стороны инициируют соединение), которые позволяют устанавливать соединения через брандмауэры и NAT. Процесс «рукопожатия» в SRT работает в рамках существующих политик безопасности, поэтому разрешаются внешние соединения без открытия постоянных внешних портов в брандмауэре.

SRT содержит временные метки внутри каждого пакета, что позволяет проигрывать ровно с той скоростью, с которой поток закодирован без необходимости большой буферизации, выравнивая джиттер (постоянно меняющуюся скорость прихода пакетов) и входящий битрейт. В отличие от TCP, где при потере одного пакета может пересылаться вся цепочка пакетов, начиная с потерянного, SRT идентифицирует конкретный пакет по его номеру и пересылает только его. Это положительно влияет на задержку и избыточность. Пересылка пакета происходит с более высоким приоритетом, чем стандартное вещание. В отличие от стандартного UDT, в SRT полностью переписана архитектура переотправки пакетов, чтобы реагировать сразу же, как только пакет потерян. Такая технология является вариацией selective repeat/reject ARQ. Стоит отметить, что конкретный потерянный пакет можно переслать только фиксированное количество раз. Скип пакета отправителем происходит, когда время на пакете составляет более 125 % от общей задержки. SRT поддерживает FEC, и пользователь сам определяет, какую из этих двух технологий использовать (либо использовать обе), чтобы балансировать между самой низкой задержкой или самой высокой надёжностью доставки.

Передача данных в SRT может быть двунаправленной: обе точки могут посылать данные одновременно, а также могут выступать как слушателем (listener), так и стороной, инициирующей соединение (caller). Может использоваться режим «рандеву» (rendezvous), когда обе стороны пытаются установить соединение. Протокол имеет механизм внутреннего мультиплексирования, который позволяет мультиплексировать несколько потоков одной сессии в одно соединение, используя один UDP порт. Также SRT подходит для быстрой передачи файлов, которая впервые была представлена в UDT.

В SRT существует механизм контроля сетевой перегрузки (congestion control). Каждые 10 мс отправитель получает последние данные об RTT (круговой задержке) и его изменениях, доступном размере буфера, скорости получения пакетов и примерный размер текущего линка. Есть ограничения на минимальную дельту между двумя пакетами, посылаемыми подряд. Если их невозможно доставить вовремя, они удаляются из очереди.

Разработчики утверждают, что минимальная задержка, которую можно достигнуть при использовании SRT, — 120 мс с минимальным буфером при передаче на маленькие расстояния в закрытых сетях. Общая задержка, рекомендуемая для стабильного вещания, равна 3–4 RTT. Кроме того, SRT лучше справляется с доставкой при больших расстояниях (несколько тысяч километров) и высоком битрейте (10 и выше Мбит/с), чем его конкурент RTMP.

На примере выше — измеренная в лаборатории задержка при вещании SRT в 3 фрейма при 25 кадрах в секунду. Т. е. 40 мс * 3 = 120 мс. Отсюда можно сделать вывод, что ultra low latency на уровне 0,1 секунды, которая может достигаться при вещании в UDP, доступна и при вещании в SRT. Способность к масштабированию в SRT не на таком уровне, как в HLS или DASH/CMAF, однако SRT активно поддерживается разными CDN`ами и перевещателями (рестримерами), а также поддерживает вещание напрямую конечным клиентам через медиа-сервер в режиме слушателя (listener mode).

В 2017 году Haivision открыла исходный код SRT библиотек и создала SRT Alliance, который насчитывает уже более 350 членов.

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

Сегодня всё опенсорсное и хорошо документированное довольно быстро приобретает популярность. Можно предположить, что такие форматы, как WebRTC и SRT, ждёт перспективное будущее в своих отраслях применения. По минимальной величине задержки эти протоколы уже опережают адаптивное вещание поверх HTTP, при этом сохраняют надёжность доставки, обладают низкой избыточностью и поддерживают шифрование (AES в SRT и DTLS/SRTP в WebRTC). Также в последнее время набирает популярность младший брат SRT (по возрасту протокола, но не по функционалу и возможностям) — протокол RIST, но это уже тема для отдельного обзора. RTMP же активно вытесняется с рынка новыми конкурентами, а из-за отсутствия нативной поддержки в браузерах, его вряд ли ожидает широкое применение в ближайшем будущем.

Автор: Виталий Сутурихин, руководитель отдела интеграции и сопровождения Elecard.