Протоколы для вещания с низкой задержкой

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

Что такое задержка в вещании

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

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

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

Протокол UDP

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

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

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

Протокол TCP

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

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

Также приложения, которые вещают по 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-протокола, который работает поверх TCP и по умолчанию использует порт 1935. Nginx может выступать в качестве RTMP-сервера и раздавать контент, который он получает от RTMP-стримеров. Кроме того, RTMP по-прежнему пользуется популярностью для доставки трафика до CDN, а в дальнейшем трафик передается по другим протоколам.

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

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

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

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

Протокол CMAF

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

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

1. Chunk Encoding — разделение сегментов на подсегменты (маленькие фрагменты с MOOF+MDAT-MP4-боксами, которые в итоге составляют целый сегмент, пригодный для проигрывания) и их пересылка до того, как весь сегмент собран воедино;
2. Chunked Transfer Encoding — использование HTTP 1.1 для отправки подсегментов на CDN: отправляется только один HTTP-запрос методом POST для всего сегмента в 4 секунды (25 кадров/с), а в дальнейшем внутри этой сессии могут быть отправлены 100 маленьких фрагментов (в каждом по одному кадру). Плеер также может пытаться скачивать не полностью готовые сегменты, CDN, в свою очередь, при помощи Chunked Transfer Encoding отдает уже готовую часть и далее держит соединение до добавления новых фрагментов в скачиваемом сегменте. Передача сегмента плееру завершится, как только весь сегмент будет сформирован на стороне CDN.

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

Протокол Low Latency HLS

Компания Apple опубликовала его спецификацию в июне 2019 года. Она состоит из следующих составляющих:

1. Генерация частичных сегментов (fragmented MP4 или TS) с минимальной длительностью вплоть до 200 мс, которые доступны еще до формирования полного сегмента (чанка), состоящего из таких частей (x part). Устаревшие частичные сегменты регулярно удаляются из плейлиста.
2. Серверная сторона может использовать режим HTTP/2 Server Push, чтобы отправлять обновленный плейлист вместе с новым сегментом (или фрагментом). Однако в последней правке спецификации в январе 2020 года эту рекомендацию исключили.
3. Обновленные плейлисты отправляются после их появления/обновления, а не после непосредственного запроса.
4. Вместо полного плейлиста отправляется разница в плейлистах (сохраняется изначальный плейлист, и далее отправляется только добавочная разница/дельта — x skip — при ее появлении вместо отправки полного плейлиста).
5. Сервер объявляет о предстоящей доступности новых частичных сегментов (preload hint).
6. Информация о плейлистах загружается параллельно в соседних профилях (rendition report) для более быстрого переключения.

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

Протокол WebRTC

Разработан компанией Google в 2011 году. Используется в сервисах Google Hangouts, Slack, BigClueButton и YouTube Live. Представляет собой набор стандартов, протоколов и JavaScript-интерфейсов, который реализует сквозное шифрованное благодаря DTLS-SRTP в рамках peer-to-peer-соединения. При этом технология не использует сторонние плагины или ПО, проходя через брандмауэры без потери качества и задержки (например, при видеоконференциях в браузерах). При вещании видео обычно применяется реализация WebRTC поверх UDP.

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

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

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

В качестве кодеков используются Opus и VP8. Максимальное разрешение — 720p, фреймрейт — 30 кадров/с, битрейт — 2 Мбит/с.

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

WebRTC недоступен в браузере Safari и частично недоступен в Microsoft Edge и UC Browser. Задержка, заявляемая Google, составляет меньше секунды. При этом данный протокол может использоваться не только для видеоконференций, но и для передачи файлов.

Протокол SRT

Создан компанией Haivision в 2012 году. Работает на базе UDT (UDP-based Data Transfer Protocol) и технологии восстановления пакетов ARQ. Поддерживает шифрование AES-128 бит и AES-256 бит. Помимо режима listener (сервер), поддерживает режимы caller (клиент) и 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.

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

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

Не поддерживается CDN для доставки конечным пользователям. Доступен для передачи контента до последней мили, например, на CDN или рестример. Не поддерживается в браузерах. Недоступен в Safary.

Резюме

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

Теги