Low-Latency Live

Зрители покидают стрим, если отставание от реального времени превышает 30 секунд - они переходят к тем, кто пишет спойлеры в чате. Задержка в 2 секунды против 30 секунд - это разница между интерактивным live и записью.

• **Twitch** перешёл с legacy HLS (20-30 с) на LL-HLS в 2022 году - latency упала до 2-5 с. Для спортивных событий активируется WebRTC-путь: зрители получают картинку быстрее, чем задержка ТВ-трансляции.
• **TikTok LIVE** обслуживает 100M+ одновременных зрителей через WebRTC SFU, развёрнутые в каждом регионе. Sub-200ms latency критична для функции "подарков" - зритель должен видеть реакцию стримера до следующего подарка.
• **YouTube Live** использует LL-HLS с 2-секундным ultra-low-latency режимом для прямых трансляций. В стандартном режиме (30 с) включается агрессивное CDN-кеширование и снижается стоимость раздачи в ~3 раза.
• **Cloudflare Stream** реализовал WHIP/WHEP стандарты для WebRTC-инжеста и egress, обеспечивая <500 мс latency из 200+ PoP без необходимости управлять собственной SFU-инфраструктурой.

LL-HLS: частичные сегменты

Классический HLS буферизует 6-30 секунд видео в сегменты, что делает latency неприемлемой для live-событий. Low-Latency HLS (LL-HLS), стандартизированный Apple в 2019 году, режет эти сегменты на **partial segments** размером 200-500 мс и отдаёт их клиенту ещё до завершения сегмента через HTTP/2 Push или Blocking Playlist Reload.

Twitch перешёл на LL-HLS в 2022 году - latency упала с 20-30 с до 2-5 с при сохранении CDN-совместимости. YouTube Live использует аналогичный подход и декларирует 2 с для событий с активированным ultra-low-latency режимом.

Blocking Playlist Reload - ключевой механизм LL-HLS: клиент отправляет запрос с указанием ожидаемого MSN (media sequence number) и номера парта. Сервер отвечает только когда этот парт готов. Это устраняет polling и снижает time-to-first-byte.

WebRTC для стриминга: WHIP/WHEP

WebRTC обеспечивает sub-200ms latency, работая поверх DTLS/SRTP/UDP. Изначально WebRTC создавался для p2p звонков, но масштабирование на тысячи зрителей потребовало SFU (Selective Forwarding Unit) - сервера, который получает один поток от стримера и пересылает нужные слои каждому зрителю без транскодинга.

В 2022-2023 годах отрасль стандартизировала WHIP (WebRTC-HTTP Ingestion Protocol) для публикации и WHEP (WebRTC-HTTP Egress Protocol) для просмотра. Cloudflare Stream, Dolby.io и Mux реализовали оба протокола, упростив интеграцию. TikTok LIVE использует WebRTC-стек с собственными SFU в каждом регионе - суммарно 100M+ одновременных зрителей.

SFU vs MCU: SFU пересылает пакеты без обработки (низкий CPU, масштабируется до 100k зрителей), MCU микширует потоки на сервере (высокий CPU, нужен только если зрители видят комбинированный поток). Для стриминга всегда SFU.

Sub-second delivery: стек и компромиссы

Sub-second латентность (< 1 с) достижима несколькими путями с разными компромиссами. WebRTC даёт 50-200 мс, но масштабирование дорого и сложно. LL-HLS даёт 2-5 с при CDN-совместимости и дешёвой доставке. RTMP (legacy) даёт 3-10 с и по-прежнему используется для инжеста (OBS -> сервер).

• **WebRTC/WHIP**: 50-200 мс, требует SFU, плохо кешируется CDN, дорого масштабировать выше 100k
• **LL-HLS**: 2-5 с, CDN-нативный, ABR из коробки, широкая совместимость браузеров
• **LHLS (Low-Latency HLS, Twitch-spec)**: 2-4 с, нестандартизирован, устарел
• **SRT (Secure Reliable Transport)**: 0.5-1 с latency, оптимален для инжеста через плохие сети
• **CMAF Chunked Transfer**: 2-4 с, DASH/HLS-совместимый, используется в Netflix live events

Latency Optimization: буферы, GOP и ABR

Главные источники latency в видео-пайплайне: encoder buffer (0.5-2 с), packager buffer (1-3 с), CDN propagation (50-200 мс), player buffer (1-10 с). Для LL-стриминга каждый из них нужно тюнить.

**GOP (Group of Pictures)** - ключевой параметр: чем длиннее GOP, тем выше сжатие, но тем дольше клиент ждёт ключевого кадра для начала декодирования. Twitch использует GOP=2 с для live (против 10+ с в VOD). Более короткий GOP повышает битрейт на ~15-20%.

ABR (Adaptive Bitrate) на LL-стриминге опирается на CTE (Content-Type Encoding) hints и CMCD (Common Media Client Data) - клиент сообщает серверу пропускную способность, а сервер может заранее подготовить нужное качество. Cloudflare Stream и Mux реализуют это для сокращения rebuffering на 40%.

Итоги

• **LL-HLS** снижает latency до 2-5 с через partial segments (250 мс) + Blocking Playlist Reload - CDN-совместимый компромисс между sub-second и масштабируемостью
• **WebRTC SFU** даёт <200 мс через DTLS/SRTP/UDP, но требует SFU-инфраструктуры и не кешируется CDN - оправдан при интерактивности (чат-реакции, подарки, e-sports)
• **GOP length** - главный параметр latency на encoder-уровне: LL требует GOP <= 2 с, `-tune zerolatency` в FFmpeg убирает B-frames и снижает encoder-буфер

Связанные темы

Low-latency live опирается на несколько смежных областей realtime-бекенда:

• WebRTC Internals — Базовый транспортный стек для sub-second streaming: ICE, DTLS, SRTP, SCTP
• CDN Architecture — LL-HLS масштабируется через CDN - понимание edge caching критично для оптимизации
• Multiplayer Game Networking — Те же принципы latency-бюджета и компромиссов между задержкой и качеством

Вопросы для размышления

• При каком сценарии лучше выбрать LL-HLS вместо WebRTC, несмотря на более высокую latency (2-5 с против 200 мс)?
• Как бы изменилась архитектура стриминга, если бы CDN научились кешировать WebRTC-потоки так же эффективно, как HLS-сегменты?
• Почему encoder-буфер рекомендуют устанавливать в 0.5x от битрейта, а не 2x, как в обычном VOD-стриминге?

Связанные уроки

• net-01-intro