Заголовки в духе Low-latency Streaming и Ultra Low-latency Streaming сегодня встречаются буквально на каждом шагу: в рекламных брошюрах, на презентациях стриминговых сервисов и стендах отраслевых выставок. Кажется, сегодня уже не осталось вендоров решений для транскодирования и рестриминга, которые не заявляли бы о поддержке вещания с низкой задержкой. К сожалению, конкретики в таких маркетинговых материалах обычно мало. В лучшем случае можно увидеть красивую цифру вроде «200 мс» или «500 мс», хотя очевидно, что один и тот же продукт не сможет выдавать такие показатели абсолютно во всех сценариях. Международных стандартов, которые бы четко определяли эти термины, по сути нет. Реальная же задержка зависит от множества факторов — даже если сигнал передается в полностью контролируемой среде.
Авторы публикаций по теме нередко делают фокус на последнем этапе — протоколе доставки, называя его «протоколом с низкой задержкой» и игнорируют все остальные составляющие процесса обработки видео. При этом суммарная задержка процессов захвата сигнала, его компрессии, упаковки в необходимый медиа-контейнер, прием и декодирование может кратно превосходить само время доставки.
В этой статье мы разберем, какие реальные величины могут стоять за маркетинговыми утверждениями, из чего складывается время обработки и доставки видео, когда имеет смысл погоня за миллисекундами, а также чем за все это придется платить.
Вопросы терминологии
Наиболее недавняя попытка разобраться в терминологии вещания с (ультра)-низкой задержкой была предпринята Streaming Video Technology Alliance (SVTA) в 2025 году, по инициативе входящей в него Low-Latency Streaming Working Group. В эту рабочую группу входят представители компаний Elecard, TAG Video Systems, Sky, IMAX и других, силами которых был проведен опрос среди релевантной аудитории по ряду вопросов, касающихся вещания с низкой задержкой. За время опроса получено 102 ответа, что, безусловно, не является впечатляющим результатом, но все же до некоторой степени отражает мнение отрасли о предмете. С полным отчетом можно ознакомиться здесь: https://www.svta.org/product/svta7111.
Пока работает с задержками от 10 до 40 секунд. Еще 24% укладываются в диапазон 2–10 секунд, и 28% уже смогли выйти на показатель меньше 2 секунд. При этом подавляющее большинство (86% респондентов) ставит перед собой цель опустить задержку ниже 5 секунд.
Таким образом, разрыв между текущим состоянием технологий, используемых в индустрии, и ожиданиями пользователей остается значительным. При этом и сами ожидания заметно различаются в зависимости от характера контента.
Например, для просмотра новостей или развлекательных программ задержка в несколько секунд обычно приемлема. Другое дело — спортивная трансляция: неприятно, когда зритель узнает о забитом голе из уведомления на телефоне раньше, чем увидит его по телевизору. Но и здесь не существует фиксированного значения, после которого задержка становится «низкой». Для обычного OTT-вещания пять секунд могут быть вполне приемлемым результатом, для специально подготовленного IPTV-тракта целью может быть одна секунда, а в некоторых профессиональных сценариях речь идет о 250 – 300 миллисекунд.
Очевидно, что термин «Low Latency» без указания конкретной величины в миллисекундах, способов измерения и условий достижения задержки почти ничего не говорит о технических характеристиках системы.
Из чего состоит задержка при вещании
Рассмотрим типовые тракты доставки видео:
- В DVB это может быть последовательность из SDI-источника, A/V-энкодеров, TS-мультиплексора, передачи TS по UDP на DVB-модулятор и приема на телевизоре или STB.
- Для классического multicast IPTV схема похожая, но без DVB-модулятора — TS передается по IP-сети непосредственно на TV/STB.
- В OTT после энкодера появляются пакетайзер, Origin, CDN и абонентский плеер, который загружает сегменты, выбирает профиль и следит за своим буфером.
На каждом этапе обработки видео и его доставки существует определенная задержка, и в большинстве случаев она существует не просто так. Одни буферы нужны для более эффективной компрессии видео, другие — для согласования элементарных потоков, третьи — для сглаживания неравномерностей передачи, четвертые — для устойчивого воспроизведения на стороне приемника.
Поэтому решение задачи вещания с низкой задержкой заключается не столько в выборе протокола доставки, сколько в определении того, какой временной запас действительно необходим на каждом этапе и насколько его можно сократить, не нарушив работу системы.
Lookahead
Одним из наиболее заметных источников задержки на этапе видеокодирования является lookahead — анализ будущих кадров. Энкодер буферизирует некоторое количество поступающих кадров, оценивает их сложность и использует полученную информацию для более эффективного распределения битрейта. Например, если через некоторое время появится сложная сцена, требующая большого количества битов, энкодер может несколько ограничить их расход на предыдущих кадрах.
По смыслу это напоминает двухпроходное кодирование, используемое для файлов, хотя, конечно, не является его прямым аналогом. При кодировании файлов первый проход может проанализировать весь файл, а при live-вещании энкодер располагает только ограниченным окном будущих кадров.
Размер этого окна зависит от настроек кодирования. Предположим, что lookahead составляет 50 кадров при частоте 25 fps. В таком случае для анализа будущих кадров необходимо накопить две секунды видео — одно это может в несколько раз превысить весь допустимый бюджет задержки.
Lookahead, как правило, можно полностью отключить в настройках энкодера. Однако за это придется заплатить снижением эффективности сжатия — при том же битрейте качество изображения может ухудшиться, а для сохранения качества потребуется увеличить битрейт. Причем выигрыш в качестве от включения lookahead сильно зависит от характера контента и наиболее заметен он для сложного, динамичного видео.
Спортивные трансляции, например, часто содержат сложное движение, большое количество деталей и смены сцен, то есть это именно тот контент, для качественного кодирования которого анализ будущих кадров мог бы быть особенно полезен. Но именно такие трансляции нередко требуют минимальной задержки.
B-кадры
Другой источник задержки — использование B-кадров.
B-кадры позволяют использовать для межкадрового предсказания не только предыдущие, но и будущие кадры. Это повышает эффективность сжатия, но требует предварительно получить будущий кадр, на который будет сделана ссылка.
Предположим, B-кадр использует опорный кадр, находящийся на три кадра впереди него в порядке отображения. При 25 fps длительность одного кадра составляет 40 мс, следовательно, такая структура предсказания требует около 120 мс видео из будущего. Для обычного вещания это не слишком много, но если целевая задержка 200 – 300 мс, одно только ожидание будущего опорного кадра уже занимает заметную ее часть.
Эта задержка обусловлена структурой GOP и будет существовать даже при отключенном lookahead. Можно уменьшить количество B-кадров до 1 или даже полностью отказаться от B-кадров. Однако компромисс снова тот же самый — меньшая задержка достигается ценой снижения эффективности сжатия.
Мультиплексирование и синхронизация аудио и видео
TS-мультиплексор также вносит свой вклад в общую задержку. Само по себе мультиплексирование — операция относительно легкая с точки зрения вычислений и выполняется она быстро. Задержка здесь вызвана в основном необходимостью согласовать несколько элементарных потоков (аудио, видео, субтитры и др.), чтобы обеспечить их одновременную доставку приемнику.
Аудио и видео, даже если они поступают от одного SDI-источника, кодируются независимо друг от друга, поэтому время появления соответствующих фреймов аудио и видео на входе мультиплексора может различаться. При формировании TS необходимо организовать интерливинг таким образом, чтобы данные каждого элементарного потока поступали в приемник до того, как они потребуются декодеру, но и не настолько заранее, чтобы переполнить его буферы.
На стороне STB существуют отдельные буферы для аудио и видео, и размер их конечен. Поэтому временное расположение данных в транспортном потоке нельзя выбирать совершенно произвольно.
Если входные элементарные потоки имеют значительный разбег по времени поступления, мультиплексору может потребоваться больший буфер. Альтернативой является уменьшение этого разбега на предыдущих этапах или увеличение буфера на стороне приемника.
В качестве примера можно посмотреть на реальный TS, исследованный в Elecard Stream Analyzer. На графике Time Dynamics показана разница PTS между выбранными аудио- и видеопотоками. В рассматриваемом фрагменте она достигает трех секунд.
Согласно практическим наблюдениям, разница PTS должна укладываться в интервал до одной секунды: превышение может сопровождаться проблемами при мультиплексировании и воспроизведении. Уменьшая размер буфера в мультиплексоре, мы уменьшаем временной запас для согласования элементарных потоков и тем самым повышаем требования к их подготовке.
Передача транспортного потока в сеть
Еще один источник задержки связан с формированием UDP-потока на выходе, причем сам по себе протокол UDP не является значительным источником задержки. Однако данные после кодирования и мультиплексирования могут поступать на сетевой выход неравномерно, и если передавать их немедленно, без дополнительного регулирования темпа выдачи, эта неравномерность может практически напрямую перейти в UDP-трафик.
Для оценки временной структуры потока можно использовать Inter-packet Arrival Time (IAT) — интервал между поступлениями соседних пакетов.
В одном из наших тестов при полностью отключенном выходном буфере пиковые значения IAT, по данным Elecard Boro, находились примерно в диапазоне 200 – 400 мс:
DVB-модуляторам требуется получать данные с достаточно предсказуемой скоростью, поэтому для них такая структура входного потока может оказаться неприемлемой.
Чтобы уменьшить IAT на сетевом выходе, используются rate control и дополнительный буфер, позволяющий накопить определенный объем данных и выдавать их более равномерно.
В том же тесте мы сравнили 3 варианта настройки выходного буфера при неизменных остальных параметрах.
При нулевом буфере Max IAT составлял примерно 200 – 400 мс и при увеличении буфера до 700 мс сократился примерно до 10 – 20 мс. При увеличении буфера до 1400 мс основная часть измеренных значений находилась уже на уровне 3 – 4 мс, с отдельными небольшими всплесками.
С точки зрения равномерности вещания последний вариант выглядит лучшим, но цена этого результата — дополнительная задержка в 1400 мс, которая для сценариев вещания с низкой задержкой совершенно неприемлема.
На данном этапе обработки сигнала задача заключается не в том, чтобы добиться минимального IAT, а в подборе минимального размера буфера, при котором временная структура потока уже соответствует требованиям последующего оборудования.
В профессиональных решениях для транскодирования, мультиплексирования и стриминга присутствует возможность управления всеми этими параметрами.
Задержка в OTT
В OTT к уже рассмотренным источникам задержки добавляются еще несколько: формирование сегментов, их публикация на Origin, доставка через CDN до клиента и буферизация в плеере.
В классических вариантах HLS и DASH плеер работает с сегментами фиксированной длительности (обычно от 2 до 10 секунд), накапливая несколько сегментов в буфере для устойчивого воспроизведения, поэтому даже при достаточно быстрых настройках кодирования суммарная задержка может составлять десятки секунд.
Существуют LL-варианты HLS и DASH, которые позволяют передавать и воспроизводить небольшие части сегмента, не дожидаясь готовности целого сегмента.
Реализация Low Latency OTT в Elecard CodecWorks
Разберем на примере реального проекта по организации LL-OTT вещания на стадионах в США во время одного из самых больших футбольных событий в мире. Задача заключалась в подготовке четырех OTT-каналов для просмотра на планшетах в VIP-зонах с минимально возможной задержкой. При этом требовалось сохранить возможность перемотки прямого эфира до четырех часов назад.
Решение Elecard включало сервер CodecWorks, принимающий SDI-сигналы, кодирующий видео, формирующий LL-DASH и раздающий поток клиентским плеерам. Низкая задержка достигалась, в частности, за счет разделения сегментов на небольшие фрагменты, доступные плееру до завершения формирования и загрузки целого сегмента.
На внутренних тестах с THEO Player, установленным на планшетах, была получена задержка между контрольным SDI-сигналом и воспроизведением около одной секунды — для OTT это весьма неплохой результат. При этом система проектировалась под ограниченную аудиторию (до 40 планшетов) и работу в полностью контролируемой сети.
Однако, просто перенести те же настройки на тысячи пользователей, подключающихся через публичный интернет, без каких-либо изменений нельзя. Небольшой буфер плеера, позволяющий получить задержку около секунды в локальной сети, может привести к частым остановкам воспроизведения при нестабильной доставке. Это одно из основных различий между Low Latency в профессиональном вещательном тракте и Low Latency для массового OTT.
В полностью контролируемой инфраструктуре мы можем подобрать оборудование, настроить буферы и ограничить число клиентов. При массовом вещании в публичном интернете ситуация существенно сложнее: у пользователей различаются устройства, доступная пропускная способность и возможности программных плееров. Поэтому для массового OTT недостаточно просто уменьшить продолжительность сегментов или отключить часть буферизации. Необходимо сохранить устойчивость работы системы в условиях, когда характеристики доставки постоянно изменяются.
Одним из направлений развития LL-OTT является более тесная интеграция механизма доставки с логикой приложения. Например, HTTP/3 использует транспортный протокол QUIC поверх UDP, который позволяет приложению получать сведения о состоянии соединения и в определенных реализациях более гибко управлять передачей данных. Однако все новые механизмы LL-OTT дают результат только в том случае, если их поддерживают серверная часть, сеть доставки и клиентское приложение.
Заключение
Низкая задержка в вещании — это не характеристика какого-либо протокола доставки или LL-пресет в энкодере. Задержка складывается из задержек всех элементов тракта, начиная с захвата исходного изображения и заканчивая его отображением на устройстве клиента.
Каждый из этих элементов использует определенный временной запас для решения собственной задачи, и его сокращение всегда имеет последствия.
Получить нужное число миллисекунд в специально подготовленной тестовой конфигурации — лишь часть задачи. Гораздо сложнее удерживать эту задержку при реальном вещании, с различным контентом, в разных сетевых условиях и на большом количестве абонентских устройств.
Вопрос к любым заявлениям о «Ultra Low Latency — 200 мс» заключается не столько в том, действительно ли продукт способен достичь такой величины. Не менее важно понимать, между какими точками она измерена, в каких условиях получена и чем именно пришлось пожертвовать ради этих миллисекунд.
Автор
Дмитрий Шмаков
Ведущий инженер компании Elecard. Работает в сфере видеоанализа с 2021 года. Дмитрий отвечает за работу с крупнейшими клиентами Elecard, такими как Telstra, Globo, Amagi, Innet и др.
Elecard CodecWorks — профессиональный программный транскодер HEVC/H.265, AVC/H.264 и MPEG-2 видео в режиме реального времени, с поддержкой адаптивного вещания HLS, CMAF и MPEG-DASH и совместимостью c различными системами условного доступа CAS.