Прямая трансляция ломается не на экране плеера, а там, где сигнал нужно принять, перекодировать в несколько качеств и за секунды раздать миллионам зрителей, пока событие ещё идёт.
Глава собирает в одну систему приём потока (ingest), онлайн-транскодирование в лестницу качеств, упаковку в сегменты с манифестом и раздачу через сеть доставки контента, где всё держится на бюджете задержки.
В интервью и инженерных обсуждениях этот кейс полезен тем, что заставляет явно назвать целевой режим задержки, отделить видеоконвейер от realtime-контура чата и объяснить, как пережить пик одновременных зрителей.
Бюджет задержек
Каждый межсервисный переход в критическом пути должен иметь чёткий режим работы и предсказуемое поведение в рамках общего бюджета задержек.
Стратегия раздачи
Выбор отправки заранее, чтения по запросу или гибридной схемы напрямую влияет на масштабируемость и сложность системы.
Состояние сессии
Важно учитывать присутствие пользователя, повторное подключение, порядок событий и семантику доставки для клиента.
Плавная деградация
При пиках нагрузок система должна понижать качество сервиса без массового отказа.
Граница
Video Hosting (VOD)
Соседний кейс про загрузку и видео по запросу: оффлайн-транскодирование и доставку готовых файлов. Здесь же речь про прямой эфир в реальном времени.
Прямая трансляция () — это не «видео, которое смотрят сразу». Это конвейер, который должен в реальном времени принять сигнал, перекодировать его в несколько качеств, нарезать на сегменты и раздать через при от одного источника к миллионам зрителей. Ключевая ось проектирования здесь — не объём хранилища, а : сколько секунд проходит от момента съёмки до картинки на экране зрителя.
Важно сразу отделить этот кейс от соседнего разбора Video Hosting. Там речь про загрузку и VOD (видео по запросу): тяжёлый путь записи, очередь оффлайн-транскодирования и многократно более дешёвую отдачу одного и того же ролика. Здесь же файл не лежит готовым — он рождается прямо сейчас, и каждый сегмент нужно закодировать и доставить, пока событие ещё идёт. Это меняет всё: транскодирование становится онлайн-операцией с дедлайном, а задержка превращается в продуктовое требование.
Чем live отличается от VOD
- Источник: в VOD файл готов заранее, в live он создаётся в момент трансляции и не имеет «конца».
- Транскодирование: в VOD — оффлайн, можно ретраить и оптимизировать; в live — онлайн, с жёстким дедлайном на каждый сегмент.
- Главная метрика: в VOD — стоимость хранения и старт воспроизведения; в live — и устойчивость к пикам зрителей.
- Перемотка: в VOD доступна вся длительность; в live зритель «гонится» за live edge и ограничен окном DVR.
Требования
Функциональный список здесь короткий — публикация, просмотр, перемотка. Архитектуру определяет не он, а нефункциональные ограничения: задержка, доступность на пике и поведение плеера, когда канал зрителя начинает проседать.
Функциональные
- Стример публикует поток (камера/энкодер → ).
- Зритель смотрит трансляцию в нескольких качествах.
- Перемотка к live edge и назад в пределах окна DVR.
- Опционально: чат, реакции, счётчик зрителей в реальном времени.
- Опционально: запись эфира в VOD после завершения.
Нефункциональные
- Контролируемая под целевой режим (секунды или суб-секунда).
- Высокая на пике одновременных зрителей.
- Адаптивность к сети: между качеством картинки и плавностью при падении канала.
- Глобальная раздача с близким к зрителю edge.
Пайплайн: от захвата до зрителя
Базовый контур — это четыре стадии: (ingest), онлайн- в лестницу качеств, упаковка в сегменты с манифестом и раздача через . Каждая стрелка на схеме добавляет к бюджету задержки.
Ingest: как сигнал попадает в систему
- RTMP: исторический стандарт публикации от энкодера; широко поддержан, но поверх и без защиты от потерь.
- SRT: транспорт поверх с восстановлением потерь — устойчивее на нестабильных каналах contribution-сети.
- WebRTC: публикация прямо из браузера и путь к суб-секундной задержке — но раздача уже не ложится на обычную сеть доставки контента и требует отдельной сети реле.
Упаковка: почему сегменты
- Поток нарезается на короткие файлы-сегменты (обычно 2–6 секунд) плюс манифест-плейлист.
- Сегменты — обычные -объекты, поэтому раздаются и кешируются стандартным .
- Манифест описывает доступные качества и список сегментов; клиент сам решает, какое качество тянуть.
- Граница сегмента должна совпадать с ключевым кадром, иначе переключение качества рвёт картинку.
Протоколы доставки: HLS и MPEG-DASH
На клиент трансляция доставляется не одним непрерывным потоком, а как манифест плюс цепочка сегментов поверх обычного . Два доминирующих формата — HLS (Apple) и MPEG-DASH (стандарт ISO/MPEG, доводимый до практики DASH Industry Forum). Оба строятся на сегментах и манифесте, оба полагаются на как на масштабируемый слой раздачи.
HLS
- Манифест — плейлист
.m3u8, сегменты в TS или fMP4 (CMAF). - Базовый формат для Apple-устройств и Safari; через hls.js работает почти везде.
- Формализован в RFC 8216, развивается спецификациями Apple (включая Low-Latency HLS).
MPEG-DASH
- Манифест —
.mpd(XML), сегменты в fMP4/CMAF. - Не привязан к кодеку и вендору; в браузере работает через Media Source Extensions и dash.js.
- Интероп-гайдлайны и профиль ведёт DASH Industry Forum.
ABR на клиенте
Adaptive Bitrate (ABR) означает, что плеер измеряет пропускную способность канала и буфер, а затем выбирает, какое качество из манифеста запросить для следующего сегмента. Логика адаптации живёт на клиенте: сервер лишь публикует доступные варианты. Именно поэтому сегментирование так важно — на каждой границе сегмента клиент может безболезненно переключиться вверх или вниз по .
Бюджет задержки: три режима
Главная ось live-стриминга — задержка против масштаба. Чем ниже задержка, тем сложнее и дороже раздать поток на миллионы зрителей: короче сегменты, меньше буфер, выше требования к энкодеру и сети. Поэтому первым делом стоит назвать целевой режим — для спорта и аукционов важна суб-секунда, для обычного эфира приемлемы несколько секунд, и это разные системы, а не одна с разной настройкой.
| Режим | Типичная задержка | Компромисс |
|---|---|---|
| Обычный HLS / DASH | ≈ 10–30 c (оценка) | Длинные сегменты и большой буфер дают максимальный масштаб и устойчивость, но «отстают» от реального времени. |
| Low-Latency HLS / LL-DASH | ≈ 2–5 c (оценка) | Частичные сегменты, preload-подсказки и блокирующая перезагрузка плейлиста сокращают задержку, оставаясь поверх /. |
| WebRTC | суб-секунда (оценка) | Прямая peer-доставка по даёт минимальную задержку, но масштабирование на миллионы требует отдельной сети SFU/реле и дороже. |
Числа — порядковые ориентиры из инженерной практики и спецификаций (Apple Low-Latency HLS, DASH-IF), а не гарантированные значения конкретной системы; реальная задержка зависит от длины сегмента, размера буфера и сети. Если меняется длительность сегмента, политика кеширования манифеста или скорость энкодера, весь бюджет задержки надо пересчитать заново.
Масштаб раздачи: CDN, edge и фан-аут
Один стример порождает поток, который смотрят миллионы. Это классический 1→N, и держит его не (origin), а с многоуровневым кешированием. Сегменты и манифест — обычные -объекты, поэтому большая часть запросов обслуживается из , не доходя до источника.
Многоуровневое кеширование
- Edge-узлы рядом с зрителем держат горячие сегменты; промежуточный слой ( ) гасит запросы к источнику.
- Сегменты иммутабельны, поэтому кешируются надолго; манифест меняется на каждом новом сегменте и кешируется коротко.
- Грамотные критичны: слишком долгий кеш манифеста увеличивает задержку, слишком короткий бьёт по на пике.
Пик одновременных зрителей
- Нагрузка не размазана: финал матча или премьера дают резкий пик, к которому edge должен быть прогрет заранее.
- «Громовое стадо» на манифест: тысячи плееров синхронно перечитывают плейлист — нужна защита от cache stampede.
- Подробнее про слои и — в соседнем разборе CDN.
Транскодирование: лестница битрейтов и стоимость
Из одного входящего потока система строит лестницу качеств (ABR ladder) — набор вариантов от низкого до высокого разрешения и битрейта. В отличие от VOD, где это идёт оффлайн, в live кодировать нужно в реальном времени, с дедлайном на каждый сегмент.
Лестница и выравнивание
- Несколько вариантов (например 1080p / 720p / 480p / 360p) кодируются параллельно из одного источника.
- Ключевые кадры (IDR) во всех вариантах должны стоять в одних точках, а границы сегментов — совпадать.
- Без выравнивания клиент не сможет переключаться между качествами без артефактов — это типичная ловушка, которую разбирает инженерный блог Twitch.
Стоимость и аппаратное кодирование
- Транскодирование в реальном времени — самый дорогой компонент по CPU/GPU на каждый активный канал.
- GPU и аппаратные энкодеры дают плотность и предсказуемую задержку, но хуже по сжатию, чем медленный софт.
- Один декодер на источник и общий конвейер вместо N независимых процессов экономят ресурсы — именно к этому пришёл Twitch вместо набора независимых инстансов FFmpeg.
Глубокие разборы
Запись live → VOD и DVR-окно
- Те же сегменты, что раздаются вживую, можно сохранять и собирать в VOD-ресурс после эфира — мост к кейсу Video Hosting.
- DVR-окно — это сколько прошлого эфира доступно для перемотки; задаётся длиной плейлиста и хранением сегментов.
- Зритель «гонится» за live edge; уход назад в DVR увеличивает буфер, но теряет реальное время.
Защита контента
- Подписанные URL и токены ограничивают доступ к манифесту и сегментам по времени и пользователю.
- DRM (FairPlay для HLS, Widevine/PlayReady для DASH) шифрует сегменты и управляет ключами.
- Защита от перезахвата потока (geo-блокировки, ротация ключей) — отдельный продуктовый контур.
Чат и реакции как отдельный контур реального времени (real-time)
Чат, реакции и счётчик зрителей — это не часть видеоконвейера. Это отдельный канал со своим фан-аутом, обычно поверх и шины сообщений, со своей и семантикой доставки. На большом эфире его масштаб (сообщений в секунду) может превосходить нагрузку самого видео по числу событий. Контур фан-аута, подтверждений и повторов ближе к разбору Distributed Message Queue, чем к видеоупаковке.
Компромиссы и типовые ошибки
- Гнаться за суб-секундой везде: WebRTC «по умолчанию» там, где хватило бы LL-HLS, резко усложняет масштаб и стоимость.
- Игнорировать выравнивание сегментов: несовпадение ключевых кадров рвёт переключение качества при ABR.
- Считать live как VOD: закладывать оффлайн-транскодирование и забывать про дедлайн на каждый сегмент.
- Недооценивать пик: не греть edge и не защищать манифест от синхронного перечитывания на старте события.
- Смешивать контуры: тащить чат через тот же путь, что и видео, вместо отдельного канала .
Что важно проговорить на интервью
- Какой целевой бюджет задержки и почему именно он (спорт vs обычный эфир vs интерактив).
- Где проходит граница между видеоконвейером и отдельным контуром чата/реакций.
- Как устроена раздача на пике: слои , edge, защита манифеста от «громового стада».
- Что происходит после эфира: запись в VOD, DVR-окно, защита токенами и DRM.
Источники и материалы
Связанные главы
- Video Hosting - Соседний кейс про загрузку и VOD: оффлайн-транскодирование, хранение исходников и доставку готовых файлов по запросу.
- CDN - Многоуровневое кеширование, edge и защитный слой origin (origin shield). Без этого слоя фан-аут сегментов на миллионы зрителей упирается в origin на первом же пике.
- Real-Time Gaming - Другой класс систем реального времени (real-time) с жёстким бюджетом задержки, где видно цену суб-секундной доставки и обратной связи.
- Distributed Message Queue - Чат и реакции — это не часть видеоконвейера, а отдельный канал реального времени (real-time): фан-аут, подтверждения, повторы. Здесь видно, во что обходится их доставка.