Real-Time Backend
Live Streaming - HLS/DASH
Super Bowl 2024: 120 млн зрителей смотрят онлайн-трансляцию. Разные у всех скорости интернета, разные устройства. Почему ни у кого не крутится буферизация?
- **YouTube** (500 часов видео загружается каждую минуту) использует DASH с ML-based ABR: нейросеть предсказывает пропускную способность и снизила rebuffering на 15%
- **Twitch** перешёл на LL-HLS в 2020 году: latency упала с 15-20с до 3-5с - зрители стали видеть голы одновременно со стадионом
- **Netflix** (247 млн подписчиков) использует DASH с CENC DRM и кодирует каждый тайтл в 120+ качеств для разных устройств и условий сети
- **Apple** изобрела HLS в 2009 для трансляции WWDC - сейчас это стандарт поддерживаемый всеми устройствами без плагинов
HLS: HTTP-стриминг от Apple
HLS (HTTP Live Streaming) - протокол Apple из 2009 года, ставший индустриальным стандартом. Идея: разбить видеопоток на маленькие .ts файлы (2-10 секунд) и раздавать их через обычный HTTP. Плеер читает playlist (.m3u8) и запрашивает следующий сегмент.
Twitch обслуживает 2.5 млн одновременных зрителей через HLS. Каждый стримерский поток кодируется в 6 качеств параллельно на 4000+ серверах. .ts сегменты попадают на CDN за 1-2 секунды после кодирования.
HLS поддерживается нативно во всех iOS и macOS устройствах через `<video>` тег. На Android и Windows требуется hls.js - JavaScript-реализация. YouTube перешёл с Flash на HLS в 2016 году.
HLS плеер запрашивает master.m3u8 и видит три качества. Как плеер определяет с какого сегмента начать?
DASH: открытый стандарт для VOD
DASH (Dynamic Adaptive Streaming over HTTP) - открытый ISO-стандарт 2012 года, разработанный как ответ на проприетарный HLS. Вместо .m3u8 playlist использует MPD (Media Presentation Description) - XML файл с описанием всех качеств и сегментов.
YouTube использует DASH для большинства видео на Desktop (через Media Source Extensions API). Netflix использует DASH с собственными DRM расширениями (CENC). Основное преимущество перед HLS: фрагменты в формате .mp4 (fMP4) вместо устаревшего .ts контейнера.
- **HLS vs DASH**: HLS - нативная поддержка iOS, DASH - открытый стандарт с лучшей гибкостью
- **Сегменты**: HLS использует .ts (MPEG-TS), DASH - .m4s (fragmented MP4)
- **DRM**: DASH лучше поддерживает Widevine (Google) + PlayReady (Microsoft) + FairPlay (Apple)
- **Low-latency**: оба стандарта имеют low-latency расширения (LL-HLS, LL-DASH) с сегментами 0.5-1с
Netflix хочет защитить контент DRM. Почему DASH предпочтительнее HLS для этого?
ABR: алгоритм выбора качества
Adaptive Bitrate (ABR) - алгоритм на клиенте который выбирает качество следующего сегмента на основе скорости загрузки предыдущих. Это балансирование между качеством и rebuffering: лучше чуть снизить качество чем остановить воспроизведение.
Netflix использует BOLA (Buffer Occupancy based Lyapunov Algorithm) - академически обоснованный ABR алгоритм. При 200 млн подписчиках 1% снижение rebuffering = ~2 млн человеко-часов сэкономленного ожидания в день. Netflix тратит значительные ресурсы на исследование ABR.
YouTube в 2019 году перешёл на ML-based ABR: нейросеть предсказывает пропускную способность на следующие 5 сегментов на основе истории загрузок. Это снизило rebuffering rate на 15% и повысило среднее качество на 8%.
ABR плеер показывает 1080p, буфер 20 секунд. Сеть внезапно упала до 500 kbps (недостаточно для 720p). Что делает ABR?
Latency: от камеры до зрителя
Latency в live streaming - это задержка от момента съёмки до момента отображения у зрителя. Стандартный HLS с 6-секундными сегментами даёт 15-30 секунд задержки. Для Twitch это приемлемо, для онлайн-аукционов и интерактивного стриминга - катастрофа.
Twitch использует Low-Latency HLS (LL-HLS) с 2020 года: задержка снизилась с 15-20с до 3-5с для большинства зрителей. При этом стандартный HLS остался для регионов с нестабильным интернетом - больший буфер = меньше rebuffering.
- **Standard HLS/DASH**: сегменты 4-10с, latency 15-30с - для VOD и казуального viewing
- **Low-Latency HLS/DASH**: частичные сегменты 0.5-1с, latency 2-5с - для live events
- **WebRTC**: peer-to-peer, latency < 1с - для interactive streaming (не масштабируется на 1M+)
- **RTMP → HLS transcoding**: стример использует RTMP (низкая latency при upload), сервер транскодирует в HLS для зрителей
Для низкой latency в live streaming нужно уменьшить размер файлов сегментов (меньше байт = быстрее)
Latency определяется длительностью сегмента в секундах, а не размером файла. 1-секундный сегмент в 4K и 1-секундный сегмент в 360p дают одинаковую latency
Плеер не начинает воспроизводить сегмент до его полной публикации на сервере. Чтобы получить сегмент нужно ждать пока encoder накопит N секунд видео. Уменьшение N (длительности) - единственный способ снизить эту составляющую latency
Twitch хочет снизить latency с 15с до 3с. Самое эффективное изменение в HLS pipeline - это...
Итоги
- **HLS/DASH = HTTP + playlist + сегменты**: видеопоток разбивается на 1-10 секундные файлы раздаваемые через обычный CDN
- **ABR выбирает качество по буферу**: цель - не максимальное качество, а минимальное rebuffering при доступной полосе
- **Latency = длительность сегмента**: LL-HLS/LL-DASH уменьшают сегменты до 0.5с и достигают 2-5с latency вместо 15-30с
Связанные темы
Live streaming строится на пересечении нескольких технологий:
- CDN архитектура — HLS/DASH сегменты раздаются через CDN - без него latency upload сегментов убивает экономику
- WebRTC — Альтернативный протокол для sub-second latency в интерактивном стриминге
- Video encoding — H.264/H.265/AV1 кодеки определяют качество и размер сегментов при заданном битрейте
Вопросы для размышления
- Twitch показывает чат с реакциями зрителей в реальном времени рядом с потоком с 5-секундной задержкой. Как синхронизировать события чата с видео?
- Netflix кодирует тайтл в 120+ версий. Какие параметры варьируются (не только разрешение)?
- При LL-HLS сегменты 0.5 секунды: как это влияет на количество HTTP-запросов и нагрузку на CDN по сравнению со стандартными 6-секундными сегментами?