О низкой задержке и протоколах её реализации

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

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

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

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

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

UDP

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

Рис. 1. Измерение задержки при вещании в UDP в лаборатории

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

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

TCP

Рассмотрим технологии, которые базируются на протоколе 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

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

Рис. 2. Пример реализации 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 клиент).

CMAF

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

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

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

Рис. 3. Стандартный и фрагментированный CMAF

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

Low Latency HLS

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

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

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

Рис. 4. Принцип работы LL HLS

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

WebRTC

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.

Рис. 5. Стек протоколов WebRTC

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

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

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

SRT

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, и пользователь сам определяет, какую из этих двух технологий использовать (либо использовать обе), чтобы балансировать между самой низкой задержкой или самой высокой надёжностью доставки.

Рис. 6. Принцип работы SRT в открытых сетях

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

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

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

Рис. 7. Измерение задержки при вещании в SRT в лаборатории

На примере выше — измеренная в лаборатории задержка при вещании 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 членов.

Резюме

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

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

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

Запросить демоверсию Elecard CodecWorks энкодера с поддержкой RTMP, HLS и SRT протоколов.

Автор

Виталий Сутурихин

Руководитель отдела интеграции и сопровождения Elecard с 2015 года. С 2006 года работает в сфере информационных технологий.

4 июня 2020