LL-HLS, WebRTC и CMAF-LL: гид по low-latency-стримингу в 2026 году

TL;DR

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

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

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

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

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

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

Когда камера снимает кадр, он сначала проходит через кодировщик – программу или чип, который сжимает несжатый кадр в компактный поток битов кодеком вроде H.264, H.265 или AV1. Кодировщик буферит несколько кадров, потому что для эффективного сжатия ему нужно знать, как сцена движется через несколько кадров вперёд (для оценки движения, motion estimation). Real-time-кодировщик добавляет порядка 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-плеер режет буфер до 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. Если двусторонней связи нет, но всё равно требуется быстрая доставка – спорт, новости, esports, 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, не буферизовать ответ целиком до отправки клиенту, корректно проходить блокирующие запросы манифеста и не схлопывать одинаковые запросы плеера в кэш. Часть популярных CDN ещё в 2024 году не делала всё это автоматически; в 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 на low-latency-сценарии, известное также как 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 в продакшене – выпустила специфические руководства по low-latency DASH ещё в 2020 году, и обновляет их с тех пор раз в 1–2 года. 7 Главный новый элемент в DASH-манифесте – @availabilityTimeOffset (ATO), который говорит плееру, насколько раньше сегмент доступен по сравнению с расчётным временем доступности. Без ATO плеер не знает, что чанк уже можно скачивать; с ATO он начинает скачивание именно в момент появления первого чанка. 7

Второй важный элемент LL-DASH – Resync Element. Если плеер по каким-то причинам потерял синхронизацию (например, отстал от live-точки из-за сетевого всплеска), 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 играется нативно в Safari/iOS/tvOS и через JS-плееры на других платформах; LL-DASH играется через JS-плееры везде, кроме Safari (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 – естественный выбор, потому что упаковка для всех DRM делается одним набором файлов. 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

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

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

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

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

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

Первая цена – сложность инфраструктуры. У HTTP-протоколов origin-сервер и CDN – давно стандартизованные продукты: AWS CloudFront, Akamai, Cloudflare, и так далее. WebRTC требует другого вида серверов: SFU (Selective Forwarding Unit) или MCU (Multipoint Conferencing Unit). SFU принимает один upstream от источника и рассылает его множеству downstream-зрителей, не декодируя; 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 boxes, в встроенных плеерах роутеров, в большинстве IPTV-устройств. Если ваша целевая аудитория включает смарт-ТВ и приставки, через WebRTC до неё не дотянуться.

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

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

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

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

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

*Рис. 5. Архитектурная разница. LL-HLS и CMAF-LL раздаются миллиону зрителей через цепочку CDN-кэшей дёшево. WebRTC раздаётся теми же зрителями через цепочку SFU с прямыми RTP-соединениями – дороже на зрителя, но за то с задержкой в пять-десять раз ниже.</em>

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

Представим спортивный стартап, который раздаёт 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 – преимущество для интерактивных функций (мгновенные ставки, мгновенные комментарии, мгновенные стикеры на экране). Стоимость трафика – здесь WebRTC-CDN тарифицирует в 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 на всём пути, без re-buffering ответа целиком.
• CDN-узлы корректно обрабатывают блокирующие запросы манифеста (_HLS_msn, _HLS_part), не возвращая 304 и не схлопывая запросы.
• Плеер настроен с правильным target latency, max latency, sync controller и поддерживает LL-HLS extensions.

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

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

Мы пишем стриминговую инфраструктуру под клиента с 2005 года. Из 239+ проектов значительная часть связана с low-latency-доставкой – спортивные платформы, букмекерские системы in-play, телемедицина, e-learning с интерактивом, видеоконференц-решения, surveillance-VMS с live-просмотром. Наши инженеры разворачивали LL-HLS и LL-DASH на популярных CDN (Akamai, Cloudflare, Bunny, KeyCDN), интегрировали WebRTC-SFU на 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 – нишевая, но быстро растёт. Не наоборот.

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

• Low-latency-стриминг свёлся в 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-сервера.
• Выбор не вопрос «лучше vs хуже»: правильный протокол определяется тем, есть ли в продукте двусторонняя связь, и насколько критична задержка.
• 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.