LL-HLS, WebRTC и CMAF-LL: гид по стримингу с низкой задержкой в 2026 году

TL;DR

Low-latency-стриминг – это передача видео от камеры до экрана зрителя с задержкой меньше, чем у обычного HLS, который традиционно отстаёт на 15–30 секунд. К 2026 году рынок сузился до трёх проверенных решений: LL-HLS (LL-HLS) снижает задержку до 2–5 секунд и легко масштабируется через любую CDN, CMAF-LL (фрагменты CMAF поверх DASH или HLS) обеспечивает тот же диапазон задержек – 2–5 секунд – на основе открытого стандарта, а WebRTC выходит за рамки этих показателей – его задержка составляет 200–800 миллисекунд, – но требует иной инфраструктуры. Выбор здесь не вопрос предпочтений: каждый протокол выигрывает в одном из трёх параметров – задержка, масштабируемость, совместимость с плеерами – и проигрывает в двух других. Именно баланс этих трёх характеристик определяет оптимальное решение для конкретного продукта.

Зачем это знать

Если ваш продукт транслирует видео в реальном времени – спортивная передача, аукцион, платформа для ставок, видеоконференция, телемедицина, live-шопинг, тренировка с тренером, трансляция киберспорта, удалённое управление техникой – задержка определяет успех или провал. Когда зрители футбола в соседнем приложении видят гол на 25 секунд раньше, чем ваши, они уходят туда; когда ставка на лошадь принимается через 8 секунд после старта забега, букмекерская математика рушится; когда хирург на удалённой консультации видит реакцию пациента с опозданием в 4 секунды, доверие к продукту тоже отстаёт на 4 секунды.

Эта статья предлагает ментальную модель, в которой LL-HLS, CMAF-LL и WebRTC занимают свои ниши, а не конкурируют между собой как «лучше против хуже». Мы разберём, откуда вообще берётся задержка в стриминге, подробно рассмотрим каждый из трёх протоколов – что они делают, какие приёмы позволяют им работать быстро, где и почему они могут давать сбои, – а в конце составим дерево решений, которое можно использовать без привлечения инженера. Прочитав статью, продакт-менеджер сможет уже на этапе планирования назвать нужный протокол одним словом и одним числом – допустимой задержкой.

Что такое задержка в стриминге и из чего она складывается

Задержка стриминга – это время между событием перед камерой и моментом, когда изображение этого события появляется на экране зрителя. В индустрии её называют glass-to-glass-задержкой – от стекла объектива до стекла экрана. У современных протоколов она варьируется от 200 миллисекунд до 30 секунд – разница почти в два порядка. Чтобы понять, где возникает эта разница, разберём пайплайн по шагам.

Когда камера делает кадр, он сначала проходит через кодировщик – программу или чип, сжимающий несжатый кадр в компактный поток битов с помощью кодека, например H.264, H.265 или AV1. Кодировщик буферизует несколько кадров, поскольку для эффективного сжатия ему необходимо учитывать движение сцены в нескольких кадрах вперёд (для оценки движения, motion estimation). Реалтайм-кодировщик добавляет задержку буфера порядка 50–100 миллисекунд; качественный кодировщик для видеофайлов (VOD) буферизует несколько секунд.

Дальше сжатый поток упаковывается. Упаковка – это разделение непрерывного потока битов на короткие медиафайлы: сегменты или фрагменты. Обычный HLS делит поток на сегменты по 6 секунд; LL-HLS также использует сегменты по 6 секунд, но дополнительно разбивает каждый на «части» длительностью 200–500 миллисекунд; CMAF-LL сразу формирует чанки по 200–500 миллисекунд; WebRTC не применяет сегментацию – каждый кадр передаётся отдельным сетевым пакетом по UDP.

Дальше эти файлы или пакеты передаются по сети зрителю. При этом возникает сетевая задержка – время, за которое пакет проходит туда и обратно. Типичные значения: 20–100 миллисекунд внутри одного континента и 150–300 миллисекунд между континентами. К этой задержке прибавляется задержка сети доставки контента (CDN) – цепочки серверов-кэшей, хранящих копии видео ближе к пользователям. CDN добавляет 50–500 миллисекунд, в зависимости от того, есть ли у ближайшего кэша нужный сегмент видео.

Наконец, плеер на устройстве зрителя использует буфер воспроизведения – запас видео на несколько секунд, который держит в готовности, чтобы избежать задержек при кратковременных обрывах сети. Обычный HLS-плеер хранит 3–4 сегмента в буфере – это составляет 18–24 секунды. LL-HLS-стриминг (LL-HLS) сокращает буфер до 3–6 сегментов – менее 3 секунд. WebRTC-плеер работает с буфером всего 50–100 миллисекунд – один-два кадра, и сразу выводит их на экран.

Суммируем по шагам: кодировщик + упаковка + сеть + CDN + буфер плеера. Запомните эту последовательность – она ключ к пониманию всего, что будет дальше. Каждый из трёх протоколов решает проблему на своём этапе этого пайплайна. LL-HLS оптимизирует упаковку и буфер плеера, оставляя сеть и CDN такими же, как в обычном HLS. CMAF-LL делает то же самое, но использует другой манифест и единый формат файлов. WebRTC оптимизирует все этапы сразу – минимальный буфер кодировщика, отсутствие сегментов, прямая передача по UDP, мгновенное воспроизведение – но платит за это всем остальным.

Нажмите, чтобы увеличить

Числа, которые действительно важны

Прежде чем переходить к протоколам, договоримся о цифрах. В 2026 году типичные задержки glass-to-glass в продакшене составляют следующие значения.

Это не маркетинговые цифры с пресс-релизов – это типичные задержки, измеренные в продакшене при консервативных настройках плеера. Маркетинговый минимум всегда на 20–50 % ниже реального значения в продакшене, потому что в реальных условиях каждый уровень системы требует большего запаса, чем на стенде.

Из этой таблицы видно главное: WebRTC и LL-HLS – это разные классы технологий, а не просто «низколатентный и ещё более низколатентный». Между ними разрыв в 5–10 раз по задержке, и закрыть его частично невозможно. Если вашему продукту нужна интерактивность – двусторонняя связь, аукцион, многопользовательская игра – вам нужен WebRTC. Если двусторонней связи нет, но всё равно требуется быстрая доставка – спорт, новости, киберспорт, live-шопинг – вы остаётесь в HTTP-семействе с LL-HLS или CMAF-LL.

Нажмите, чтобы увеличить

LL-HLS – как Apple сократила задержку, не нарушая совместимости

LL-HLS – сокращение от Low-Latency HLS – расширение протокола HLS, которое Apple впервые представила на WWDC 2019 и включила в окончательном виде во вторую редакцию протокола, известную как draft-pantos-hls-rfc8216bis. По состоянию на май 2026 года актуальная версия черновика – 22, опубликованная 1 мая 2026 года; документ в IETF приближается к статусу RFC, который заменит исходный RFC 8216. 1

Главная задача LL-HLS – снизить задержку HLS с 15–30 до 2–5 секунд, не теряя двух ключевых преимуществ, благодаря которым обычный HLS стал лидером на рынке: обратной совместимости с CDN (всё ещё HTTP, всё ещё статические файлы) и нативной поддержки в Safari (не требуется переписывать плеер). Apple достигает этого с помощью четырёх взаимосвязанных механизмов.

Первый механизм – partial segments, или части. Обычный HLS записывает один файл сегмента каждые 6 секунд видео; плеер не может начать воспроизведение, пока сегмент полностью не будет записан. LL-HLS дополнительно делит каждый сегмент на «части» длиной 200–500 миллисекунд и добавляет их в манифест отдельными строками с тегом EXT-X-PART. Увидев эти строки, плеер может скачивать части по мере их появления – не дожидаясь полной сборки сегмента. Это снижает задержку упаковки с шести секунд до полусекунды. 1

Второй механизм – blocking playlist reload, или блокирующая перезагрузка плейлиста. Обычный HLS-плеер периодически опрашивает манифест с интервалом в несколько секунд: «появились новые сегменты?» – и если нет, ждёт заданное время и повторяет запрос. LL-HLS предлагает иной подход: сервер, установив флаг CAN-BLOCK-RELOAD=YES в теге EXT-X-SERVER-CONTROL, гарантирует, что задержит ответ на запрос плеера до тех пор, пока в манифесте не появится новый сегмент. Плеер отправляет запрос с параметрами _HLS_msn (номер следующего ожидаемого сегмента) и _HLS_part (номер следующей ожидаемой части); сервер удерживает ответ до готовности новой части, а затем мгновенно его возвращает. Такой подход устраняет задержку, связанную с периодическим опросом, которая в обычном HLS добавляла ещё несколько секунд. 2

Третий механизм – preload hints, или подсказки о предзагрузке. Сервер заранее объявляет в манифесте URL следующей части или карты инициализации с помощью тега EXT-X-PRELOAD-HINT, ещё до того как сам файл существует. Плеер отправляет GET-запрос по этому URL; сервер удерживает соединение открытым и начинает стримить ответ с использованием chunked transfer encoding в тот самый момент, когда часть становится доступна. Это устраняет лишний round-trip между моментом «часть готова» и моментом «плеер узнал об этом». 3

Четвёртый механизм – render-side rate control, или умное управление воспроизведением. Плееру необходимо поддерживать стабильное расстояние до live-точки: иначе при сетевом всплеске буфер опустошается, и видео останавливается. LL-HLS-лееры применяют тонкие техники подстройки скорости воспроизведения (играют чуть быстрее или медленнее на 5–10 %) и динамически меняют битрейтную лестницу, чтобы оставаться в пределах целевого окна задержки. 2

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

Но у LL-HLS есть и слабости. Главная – сложность настройки CDN. Чтобы LL-HLS работал с задержкой в 3 секунды, каждый узел CDN должен корректно поддерживать chunked transfer encoding, не буферизовать ответ целиком перед отправкой клиенту, правильно обрабатывать блокирующие запросы манифеста и не объединять одинаковые запросы плеера в кэш. В 2024 году часть популярных CDN всё ещё не обеспечивала это автоматически; к 2026 году ситуация улучшилась, но настройка LL-HLS на CDN по-прежнему остаётся задачей, на которой новички теряют недели. 4

Вторая слабость – нагрузка на origin-сервер. Каждый зритель отправляет запрос на каждый партс (200–500 мс), а не на сегмент (6 с). Это в 20–30 раз увеличивает количество запросов в секунду, и origin должен с этим справляться. Большинство CDN справляются с этим за счёт объединения повторяющихся запросов, но при сбое CDN-кэша в пиковый момент нагрузка на origin возрастёт в десятки раз по сравнению с обычным HLS.

Третья слабость – плеер должен поддерживать LL-HLS. Safari и AVPlayer на iOS и tvOS поддерживают его нативно, а к 2026 году поддержка появилась у большинства плееров на JavaScript: hls.js, Shaka Player, Video.js v10, THEOplayer. Но «поддерживает» – ещё не значит «работает быстро». Неоптимизированный hls.js на LL-HLS-стриме даёт задержку 6–8 секунд, что мало отличается от обычного HLS. Чтобы достичь заявленных 3 секунд, плеер нужно настраивать: target latency, max latency, sync controller. 5

В сухом остатке LL-HLS – правильный выбор, если нужна задержка 2–5 секунд и при этом важно охватить широкую аудиторию через готовый CDN и нативное воспроизведение в Safari. Такой формат по-прежнему доминирует среди стриминговых решений в 2026 году.

Нажмите, чтобы увеличить

CMAF-LL – открытый стандарт с той же логикой

CMAF – сокращение от Common Media Application Format – это контейнерный формат, утверждённый как ISO/IEC 23000-19 в 2017 году. 6 Первоначально CMAF был разработан для того, чтобы один и тот же набор медиафайлов мог использоваться как с манифестом HLS, так и с манифестом DASH, избавляя стримеров от необходимости дублировать упаковку видео. Сегодня такой подход стал стандартом в любой серьёзной стриминговой платформе.

CMAF-LL – расширение CMAF для сценариев с низкой задержкой, также известное как chunked CMAF или CMAF chunked transfer encoding (CTE). Идея та же, что и у LL-HLS: сегмент разбивается на небольшие чанки длительностью 200–500 миллисекунд, которые передаются по мере готовности с использованием chunked transfer encoding, без ожидания завершения всего сегмента. Главное отличие в том, что CMAF-LL реализуется в рамках стандарта CMAF, а не как расширение протокола HLS.

Когда CMAF-LL обрабатывается DASH-плеером, это называется LL-DASH. DASH-IF (DASH Industry Forum) – отраслевое сообщество, поддерживающее стандарт MPEG-DASH в реальных условиях эксплуатации, – ещё в 2020 году опубликовало специализированные рекомендации по low-latency DASH и с тех пор обновляет их раз в 1–2 года. 7 Главным новым элементом в DASH-манифесте стал параметр @availabilityTimeOffset (ATO), который сообщает плееру, насколько раньше сегмент становится доступен по сравнению с расчётным временем его появления. Без ATO плеер не узнаёт, что фрагмент уже можно загружать; при наличии ATO он начинает скачивание сразу после появления первого чанка. 7

Второй важный элемент LL-DASH – Resync Element. Если плеер по каким-либо причинам потерял синхронизацию (например, отстал от точки вещания из-за сетевого всплеска), Resync Element позволяет ему найти точку, с которой можно продолжить воспроизведение, не загружая весь сегмент заново. Это снижает риск того, что плеер при кратковременном обрыве перейдёт в состояние полной буферизации. 7

Когда тот же CMAF-LL воспроизводится через LL-HLS-плеер, это и есть LL-HLS – Apple явно создала LL-HLS с учётом совместимости с CMAF-чанками. Это означает, что один и тот же набор CMAF-файлов можно одновременно использовать в LL-HLS-манифесте для Safari и в LL-DASH-манифесте для Chrome, Firefox и Android. Издатель кодирует видео один раз, упаковывает один раз и доставляет через оба плеера с одного и того же CDN. К 2026 году это станет золотым стандартом low-latency-стриминга для крупных вещателей.

В чём CMAF-LL объективно отличается от LL-HLS?

Во-первых, подача данных одинакова: те же chunked transfer encoding, те же чанки 200–500 мс, та же логика блокирующих запросов в LL-DASH-варианте. В этом смысле CMAF-LL и LL-HLS – два манифеста над одним и тем же набором файлов.

Во-вторых, охват плееров различается: LL-HLS (LL-HLS) воспроизводится нативно в Safari, iOS и tvOS, а на других платформах – через JS-плееры; LL-DASH работает через JS-плееры повсеместно, кроме Safari (официальной поддержки DASH в нативном режиме AVPlayer нет). Если у вашего продукта значительная аудитория на iOS, вы либо отдаёте LL-HLS и теряете часть гибкости DASH, либо транслируете оба манифеста параллельно.

В-третьих, зрелость стандарта. CMAF-LL базируется на стабильных стандартах ISO, что важно для крупных вещателей и регуляторов; LL-HLS живёт в черновике IETF, который ещё не утверждён как RFC. На практике это не мешает внедрению, но в тендерах и долгосрочных контрактах такой фактор может иметь значение.

В-четвёртых, DRM-упаковка. DASH исторически лучше подходит для PlayReady и Widevine, а HLS – для FairPlay. CMAF поддерживает все три DRM-системы в одном пакете благодаря Common Encryption (CENC) – стандарту ISO/IEC 23001-7. Если ваш продукт защищён DRM, CMAF – естественный выбор, поскольку упаковка для всех систем осуществляется одним набором файлов. 8

В сухом остатке CMAF-LL – это тот же протокол доставки, что и LL-HLS, но с использованием DASH-манифеста и/или единого CMAF-стека. Архитектурно это разумный выбор, если вы разрабатываете новый продукт с нуля и хотите единый формат упаковки для всех плееров. В уже работающих продуктах LL-HLS и LL-DASH часто сосуществуют параллельно, опираясь на один и тот же CMAF-набор.

Нажмите, чтобы увеличить

WebRTC – другая лига и другая архитектура

WebRTC – сокращение от Web Real-Time Communication – это набор браузерных API и сетевых протоколов, изначально разработанный Google в 2011 году для организации двусторонней связи прямо в браузере. Спецификация WebRTC распределена по нескольким источникам: API стандартизированы в W3C Recommendation, а сетевые протоколы описаны в серии RFC от IETF (RFC 8825 – обзор архитектуры, RFC 8829 – JSEP, RFC 8835 – транспорт и так далее). К 2026 году WebRTC стал неотъемлемой частью стандартного браузерного стека: Chrome, Edge, Firefox и Safari поддерживают его нативно, без использования плагинов. 9

С точки зрения низколатентного стриминга WebRTC – это другой класс протокола, и важно понимать почему. LL-HLS и CMAF-LL – это HTTP-протоколы поверх TCP: данные передаются по сети упорядоченно, с подтверждением доставки, через CDN из кэшей. WebRTC – это сетевой протокол поверх UDP с двусторонней связью в реальном времени: пакеты передаются без подтверждения, без разбиения на файлы и без строгой упорядоченности, через специализированные серверы ретрансляции.

Эта разница меняет всё. Каждый шаг пайплайна, который в LL-HLS добавлял задержку в секундах, в WebRTC сжимается до миллисекунд:

Кодировщик WebRTC буферизует один–два кадра (40–80 мс при 25 fps), а не несколько секунд. Упаковки как таковой нет – каждый кадр передаётся отдельным RTP-пакетом, без накопления в файл. Сеть передаёт пакет напрямую через UDP, минуя накладные расходы TCP-рукопожатия и повторной передачи. На стороне приёма работает jitter buffer – буфер размером 50–100 мс, сглаживающий неравномерность поступления пакетов. Этот буфер минимален в отличие от 6–30 секунд, характерных для HLS-плеера.

Результат – типичная задержка 300–800 миллисекунд «стекло к стеклу», в идеальных условиях стенда – около 150 мс. Это в 5–20 раз ниже, чем у LL-HLS (LL-HLS). И это единственный реалистичный протокол для двусторонних сценариев: видеоконференции, телемедицина, прямые аукционы, многопользовательские игры.

Но WebRTC платит за это всем остальным.

Первая цена – сложность инфраструктуры. У HTTP-протоколов origin-сервер и CDN давно стали стандартными решениями: AWS CloudFront, Akamai, Cloudflare и так далее. WebRTC требует иной тип серверов: SFU (Selective Forwarding Unit) или MCU (Multipoint Conferencing Unit). SFU принимает один входной поток от источника и рассылает его множеству зрителей, не декодируя его; MCU же декодирует и объединяет потоки – это дороже, но удобнее для конференций с большим числом участников. В обоих случаях речь идёт о специализированных серверах: LiveKit, mediasoup, Janus, Jitsi, Pion, Twilio Video Stack. Развёртывание и масштабирование SFU – отдельная инженерная задача, которой нет в HTTP-стеке.

Вторая цена – стоимость масштаба. CDN с HTTP-стримингом работает по простой логике кэширования: миллион зрителей одного матча обходится недорого, потому что 99 % запросов обслуживает ближайший edge-узел без обращения к origin. WebRTC устроен иначе: каждое соединение между источником и зрителем – индивидуальное, SFU отправляет каждому зрителю отдельный поток. Стоимость трафика растёт пропорционально числу зрителей. В 2026 году появились WebRTC-CDN (Cloudflare Stream, Phenix, Subspace, nanoStream Cloud), которые маршрутизируют WebRTC через edge-сеть и снижают затраты на масштабирование, но цена за одного зрителя всё равно остаётся в 3–10 раз выше, чем у LL-HLS. 10

Третья цена – охват плееров. WebRTC работает в любом современном браузере (Chrome, Edge, Firefox, Safari начиная с iOS 11) и через нативные SDK на iOS, Android, Windows и Mac. Но: WebRTC не поддерживается на смарт-ТВ массово (только отдельные модели LG и Samsung 2024+ имеют экспериментальную поддержку), на старых set-top box’ах, в встроенных плеерах роутеров и в большинстве IPTV-устройств. Если ваша целевая аудитория включает смарт-ТВ и приставки, через WebRTC до неё не дотянуться.

В 2026 году стриминг через WebRTC для широкой аудитории был стандартизован с помощью двух относительно молодых протоколов: WHIP (WebRTC-HTTP Ingestion Protocol) – простой HTTP POST для передачи WebRTC-потока в инфраструктуру стриминга, и WHEP (WebRTC-HTTP Egress Protocol) – простой HTTP GET для запуска WebRTC-плеера. Оба протокола являются драфтами IETF и активно поддерживаются многими вендорами. В начале 2026 года WHIP был принят в качестве RFC, что значительно ускорило его внедрение в OBS, FFmpeg и другие инструменты вещания. 11

Главная роль WHIP – заменить устаревший RTMP в качестве протокола ингеста со стороны вещателя. До 2024 года типичная схема выглядела так: OBS отправляет RTMP, сервер принимает RTMP, конвертирует его в WebRTC и раздаёт зрителям через WebRTC. С 2025 года OBS Studio поддерживает нативный WHIP-вывод, а в 2026 году FFmpeg получил WHIP-муксер – теперь вещатель может отправлять WebRTC напрямую, минуя RTMP-посредника. 12

WHEP делает то же самое на стороне плеера: одна HTTP-команда – и плеер начинает воспроизводить WebRTC-поток, не требуя разбираться с сигналлингом, ICE-кандидатами и обменом SDP. WHEP-совместимые плееры есть в Cloudflare Stream, Phenix, nanoStream, LiveKit, Mux. 10

В сухом остатке WebRTC – правильный выбор, если нужна задержка ниже секунды и вы готовы пожертвовать частью аудитории смарт-ТВ, перейти на другую архитектуру (SFU вместо CDN) и заплатить больше за каждого зрителя. Это естественное решение для интерактивных продуктов: видеоконференции, телемедицина, аукционы, ставки, многопользовательские игры, удалённое управление техникой, live-шопинг с двусторонней связью.

Нажмите, чтобы увеличить

Числовой пример: один футбольный матч, три протокола

Представим спортивный стартап, транслирующий футбольный матч в прямом эфире для 200 000 зрителей одновременно. Рассмотрим три сценария.

Сценарий А – обычный HLS. Задержка «glass-to-glass» составляет около 22 секунд. Это значит, что когда зрители у соседнего вещателя на LL-HLS видят гол на 25-й секунде матча, ваши зрители увидят его только на 47-й. Стоимость трафика: пусть будет 1080p при 5 Мбит/с, 200 000 зрителей одновременно, 90 минут эфира. Считаем:

Битрейт × зрители × длительность = объём трафика
5 Мбит/с × 200 000 × 90 × 60 с = 5 400 000 000 Мбит = 675 ТБ

При типичной цене CDN в 0,02 $/ГБ это составляет 0,02 × 675 000 = 13 500 $ за матч. Дёшево.

Сценарий Б – LL-HLS поверх CMAF. Задержка «glass-to-glass» составляет около 4 секунд. Зритель видит игру синхронно с соседним вещателем – продукт остаётся живым. Объём трафика – те же 675 ТБ, та же стоимость CDN; итоговая цена – 13 500 $ за матч. LL-HLS не влияет на архитектуру и схему тарификации.

Сценарий В – WebRTC через WebRTC-CDN. Задержка glass-to-glass составляет около 600 миллисекунд. Зрители видят гол на 0,6 с позже, чем у вещателей с LL-HLS, но на 25 с раньше, чем у зрителей обычного HLS – это даёт преимущество для интерактивных функций: мгновенные ставки, мгновенные комментарии, мгновенные стикеры на экране. Стоимость трафика здесь в 3–5 раз выше, чем у обычного HTTP-CDN, поскольку каждый зритель получает отдельный поток через SFU-сеть. При типичной цене WebRTC-CDN в 0,08 $/ГБ итоговая стоимость составит 0,08 × 675 000 = 54 000 $ за матч – в 4 раза дороже.

Этот пример показывает экономический выбор. Если ваш продукт не извлекает из 0,6-секундной задержки качественно нового пользовательского опыта (новые типы интерактивности, новые виды монетизации), переплата в 4 раза за инфраструктуру бессмысленна – LL-HLS даёт ту же зрительскую ценность за четверть цены. Если же продукт построен вокруг этой 0,6-секундной задержки (in-play ставки, аукционы в режиме матча, прямой чат с тренером, многопользовательская реакция в реальном времени), WebRTC окупает себя многократно через дополнительный revenue per user.

Частая ошибка: «давайте сделаем LL-HLS, всё равно дёшево»

Самая частая ошибка product-команд, которые приходят в стриминговое планирование без техлида, звучит так: «у нас обычный HLS, давайте включим low-latency-режим на сервере, обновим плеер – и всё, у нас будет задержка в 2 секунды». Реальность оказывается сложнее.

Чтобы LL-HLS работал с задержкой в 3 секунды в продакшене, должны одновременно выполняться пять условий:

• Упаковщик записывает partial segments и preload hints в манифест с правильной частотой и оптимальными размерами партов.
• Origin-сервер отдаёт partial segments с использованием chunked transfer encoding, не накапливая их в полные сегменты.
• CDN-узлы поддерживают chunked transfer encoding на всём пути доставки, не буферизуя ответ целиком.
• CDN-узлы корректно обрабатывают блокирующие запросы манифеста (_HLS_msn, _HLS_part), не возвращая 304 и не объединяя запросы.
• Плеер настроен с подходящими значениями target latency, max latency и sync controller, а также поддерживает расширения LL-HLS.

Если нарушается хотя бы одно из пяти условий, реальная задержка возрастает до 6–12 секунд – то есть LL-HLS (LL-HLS) превращается в обычный HLS с дополнительной нагрузкой на сервер. По нашему опыту в Фора Софт (мы разрабатывали стриминговую инфраструктуру для нескольких OTT-платформ и спортивных продуктов), типичный новичок правильно настраивает первые два условия, а остальные три – нет, и неделями пытается понять, «почему наш LL-HLS работает с задержкой в 8 секунд». Единственное решение – тестировать систему end-to-end с реальной CDN и настоящим плеером, измерять задержку каждые 30 секунд и не доверять маркетинговым цифрам вендоров плееров до проверки на реальной аудитории.

Где Фора Софт помогает

Мы разрабатываем стриминговую инфраструктуру для клиентов с 2005 года. Из 250+ проектов значительная часть – это решения с низкой задержкой: спортивные платформы, букмекерские системы in-play, телемедицина, интерактивное e-learning, видеоконференц-связь, системы видеонаблюдения с прямым просмотром. Наши инженеры настраивали LL-HLS и LL-DASH на популярных CDN (Akamai, Cloudflare, Bunny, KeyCDN), интегрировали WebRTC-серверы на основе LiveKit, mediasoup, Janus, Pion, а также помогали клиентам перейти с RTMP на WHIP. Если задержка в вашем продукте стала ключевой бизнес-метрикой – мы знаем, где её можно сократить.

Дерево решений: какой протокол выбрать

В сухом остатке выбор сводится к двум вопросам, на которые продакт может ответить без участия инженера.

Первый вопрос: есть ли в продукте двусторонняя связь или реакция зрителя на действие в реальном времени? Если зритель может что-то отправить – поставить ставку, нажать кнопку «купить эту вещь сейчас», написать в чат, отреагировать стикером – и эта реакция должна успеть к событию на экране, нужна задержка менее одной секунды. Это WebRTC.

Второй вопрос: насколько чувствителен ваш контент к опозданию относительно эфира или соседних вещателей? Если задержка в 3 секунды не критична для продукта (большинство VOD, обучение, новости, развлекательный live), вам подойдут LL-HLS или CMAF-LL – выбор между ними зависит от вашего технического стека и требований к DRM. Если допустима задержка 15–30 секунд (фильмы по подписке, лекции в записи, повторы матчей), обычного HLS вполне достаточно – за low-latency платить не имеет смысла.

Принимая это решение, не забывайте о долгосрочных последствиях. Замена обычного HLS на LL-HLS – это постепенное улучшение в рамках той же инфраструктуры; переход от LL-HLS к WebRTC – смена архитектуры, требующая 3–9 месяцев работы команды, ранее не занимавшейся WebRTC. Выбирайте осознанно, исходя из бизнес-задачи, а не из моды.

Нажмите, чтобы увеличить

Что выбирают в продакшене в 2026 году

По данным Bitmovin Video Developer Report 2025/26, среди опрошенных стриминговых инженеров HLS как протокол доставки используют 87 % продуктов, DASH – 41 %, LL-HLS для low-latency – 24 %, LL-DASH – 12 %, WebRTC для low-latency-доставки массовой аудитории (то есть не для конференций, а именно как замена HLS) – около 9 %, с быстрым ростом за последние два года. 4 Цифры пересекаются – крупные продукты используют два-три протокола одновременно: LL-HLS для большинства зрителей, WebRTC – для интерактивной аудитории.

Это распределение также показывает: LL-HLS и CMAF-LL – основные технологии low-latency на рынке, WebRTC – нишевая, но быстро набирает популярность. И наоборот – не так.

Ключевые выводы

• В 2026 году низколатентный стриминг свёлся к трём основным решениям: LL-HLS, CMAF-LL и WebRTC. Разрыв в задержке между LL-HLS/CMAF-LL и WebRTC составляет 5–20 раз.
• LL-HLS и CMAF-LL обеспечивают задержку 2–5 секунд и легко масштабируются с помощью любого стандартного HTTP-CDN; WebRTC даёт задержку 200–800 мс, но требует дорогих специализированных SFU-серверов для масштабирования.
• Выбор протокола – не вопрос «лучше или хуже»: оптимальный вариант зависит от наличия двусторонней связи и критичности задержки для продукта.
• LL-HLS работает эффективно только при правильной настройке CDN, origin-сервера и плеера – необходимо одновременное выполнение пяти условий. Половина новичков нарушает три из них и месяцами тратят время на отладку.
• WebRTC с использованием WHIP/WHEP значительно упростился в 2025–2026 годах: OBS, FFmpeg и облачные платформы поддерживают этот стек нативно, что существенно снизило порог входа для вещателей.
• Использование CMAF поверх chunked encoding позволяет единожды упаковать контент и одновременно доставлять его в форматах LL-HLS и LL-DASH – это стал золотой стандарт для крупных вещателей, использующих DRM.

Что читать дальше

• Протоколы стриминга: 8 главных в 2026 году – подробный обзор всех протоколов в одном месте, чтобы понять low-latency в контексте.
• WebRTC глубокий разбор: SDP, ICE, STUN/TURN, SFU vs MCU – следующий уровень для тех, кто решил использовать WebRTC.
• Контейнеры: MP4, fMP4, MKV, WebM, MOV, MPEG-TS – основы для работы с CMAF и LL-HLS.