Live и VOD: два конвейера, одна платформа

Кратко

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

Почему это важно

Если вы основатель, продакт-менеджер или CTO стримингового стартапа, фраза «live добавим потом» – одна из самых дорогих, которые можно сказать, не понимая, что меняется. Live – это не фича, которую прикручивают к VOD-платформе; это второй конвейер со своим транскодингом в реальном времени, своим путём приёма и режимом отказа – трансляцию нельзя переснять, – которого у VOD нет. Эта статья даёт модель, позволяющую увидеть, что вы действительно строите дважды, а что строите один раз и переиспользуете. К концу вы сможете прочитать предложение «live + VOD» и понять, переиспользует ли подрядчик общий стержень или тихо выставляет счёт за две платформы.

Два продукта в одном здании

Самый чистый способ удержать обе идеи сразу. VOD (video on demand, видео по запросу) – это контент, который уже существует как файл: фильм, эпизод, запись урока, – его зритель может запустить в любой момент. Live – это контент, который происходит сейчас: матч, концерт, вебинар, – к нему зритель подключается на ходу. Разница звучит очевидно, но уходит вглубь инженерии, потому что один конвейер работает заранее, а другой обязан успевать за реальностью.

Представьте одно здание с двумя линиями. VOD-линия – это типография: приходит готовая рукопись, вы спокойно вёрстаете её ночью и печатаете столько копий, сколько закажут, когда закажут. Live-линия – это аппаратная прямого эфира: шоу идёт прямо перед вами, у вас один проход, и эфир выходит по мере создания. То же здание, та же погрузочная площадка, те же машины доставки – но у линий разные станки на входе и разные ставки, когда что-то заклинивает.

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

Сначала пройдём VOD-линию как более простую, затем live-линию, затем бюджет задержки, который делает live трудным, и наконец общую заднюю половину, позволяющую одной платформе обслуживать оба сценария.

VOD-конвейер: закодировать один раз, хранить, отдавать

У VOD-конвейера есть роскошь времени. Исходное видео – мастер высокого качества, называемый мезонином (mezzanine, чистая копия, из которой вы перекодируете и которую никогда не показываете зрителю напрямую) – приходит как файл и попадает в объектное хранилище. Ничего не гонится за секундомером. Поэтому каждый следующий шаг можно оптимизировать под качество и стоимость, а не под скорость.

Транскодер строит лестницу кодирования (encoding ladder) – набор версий одного видео в разных разрешениях и битрейтах, между которыми плеер переключается при изменении сети, – и может не спешить. Он способен выполнить per-title encoding, анализируя каждую единицу контента и подстраивая лестницу под неё: фильм, который посмотрят миллион раз, стоит лишних минут вычислений. Транскод здесь – пакетная (batch) задача: поднять машины, перемолоть каталог, погасить машины. Вы платите за вычисления только во время кодирования и можете прогнать тысячу тайтлов параллельно за ночь.

После кодирования и упаковки контент лежит на ориджине и отдаётся по запросу. Те же файлы отвечают и зрителю в январе, и зрителю в декабре. Поэтому VOD-доставка так дружелюбна к кэшу: популярный тайтл запрашивают снова и снова, поэтому пограничные (edge) серверы CDN держат его рядом со зрителями и редко беспокоят ориджин. Высокий коэффициент попадания в кэш (cache-hit ratio) – доля запросов, которые edge отдаёт из своего кэша, – для VOD норма, и именно он держит счёт за доставку разумным.

Определяющее свойство VOD: закодировать один раз, хранить, отдавать многократно. Время на вашей стороне, приоритет – качество, и вся работа сделана до прихода первого зрителя.

Live-конвейер: кодировать в реальном времени, без второго шанса

Live-конвейер переворачивает каждую из этих роскошей. Нет файла в хранилище – есть поток, приходящий прямо сейчас, и конвейер должен кодировать, упаковывать и доставлять его, пока он ещё происходит. Линию live определяют два свойства, и оба стоят денег и инженерии.

Во-первых, транскод идёт в реальном времени и не останавливается во время события. Live-кодирование нельзя пакетировать – машины должны работать и быть рассчитаны на трансляцию до её начала, и остаются «горячими» всю её длительность. Если VOD-вычисления эластичны и оплачиваются по факту кодирования, то live-вычисления – это постоянно работающий парк, выделенный под шоу. Форма затрат меняется с «дёшево за тайтл, оплачено один раз» на «счётчик крутится всю длину события и рассчитан на пик».

Во-вторых, второго шанса нет. Потерянный на входе кадр потерян; ошибку упаковки во время финала кубка не исправить в пост-продакшене. Этот единственный факт рождает целую дисциплину резервирования: запасные потоки приёма, дублирующие энкодеры в параллель, отказоустойчивые ориджины и доставку через несколько CDN, чтобы сбой одной сети доставки не погасил событие. VOD терпит перекодирование и повтор; live относится к каждому компоненту как к тому, у чего обязан быть горячий резерв.

Как приходит live-видео: путь приёма

Прежде чем live-конвейер сделает что-либо, видео должно попасть внутрь. Канал, несущий видео к вашей платформе, – это путь приёма (contribution, в отличие от distribution, несущего его дальше к зрителям), и он говорит на протоколе приёма. В 2026 году значимы три, и профессиональная live-платформа поддерживает все, потому что они балансируют задержку против охвата и надёжности:

• RTMP (Real-Time Messaging Protocol) – старый, работает поверх TCP, поддерживается практически любым энкодером и инструментом (OBS, vMix, аппаратные энкодеры). Восстанавливается после потерь повторной передачей TCP-потока, что даёт всплески задержки на загруженном канале, но остаётся самым частым студийным путём приёма.
• SRT (Secure Reliable Transport) – современный вещательный выбор. Работает поверх UDP, восстанавливается после потерь выборочной повторной передачей (выдерживает около 25% потерь при буфере в одну секунду) и несёт встроенное шифрование AES-256. SRT – стандарт 2026 года для полевого приёма через публичный интернет и сотовые каналы.
• WHIP (WebRTC-HTTP Ingestion Protocol) – дверь с наименьшей задержкой, 200–500 миллисекунд, идеальна для приёма из браузера и интерактивных форматов.

Внутренности этих протоколов – тема раздела Video Streaming; здесь важно, что live-видео должно прийти до запуска любого другого блока, а точке приёма нужен запасной поток, иначе единственный оборванный канал приёма обрывает трансляцию.

Бюджет задержки: почему live труден, а VOD – нет

Для VOD задержка почти не важна – секунда-две до старта нормальны, контент никуда не денется. Для live задержка и есть продукт, и стоит показать, куда уходят секунды.

Задержка «стекло-в-стекло» (glass-to-glass) – это задержка от попадания света на объектив камеры до появления картинки на экране зрителя. Это сумма всех этапов: захват и приём, кодирование в реальном времени, упаковка в сегменты, путь через CDN и собственный буфер плеера. Самый крупный единичный рычаг – длительность сегмента (сколько секунд в каждом загружаемом куске видео), потому что плеер обычно ждёт буферизации двух-трёх сегментов перед стартом.

Пройдём арифметику один раз – она объясняет каждую жалобу «почему мой эфир отстаёт на 30 секунд»:

Обычный HLS, сегменты по 6 с, буфер плеера 3 сегмента:
  буфер плеера     = 3 × 6 с = 18 с
  + кодир./упаковка ≈ 2–4 с
  + CDN + сеть     ≈ 1–2 с
  стекло-в-стекло  ≈ 18 с (буфер доминирует над всем)

Эти 18 секунд и есть причина, почему наивный HLS ощущается далёким от реального времени. Решение – уменьшить кусок, которого ждёт плеер. Low-Latency HLS (LL-HLS), определённый в спецификации Apple HTTP Live Streaming Authoring (low-latency-дополнения, текущая редакция – сентябрь 2025), сокращает ожидание, разбивая каждый сегмент на частичные сегменты примерно по 0,2–0,5 секунды (тег EXT-X-PART), так что плеер забирает медиа «на лету», не дожидаясь целого 6-секундного блока. С preload-подсказками и блокирующей перезагрузкой плейлиста LL-HLS достигает 2–5 секунд «стекло-в-стекло» на масштабе CDN. Его DASH-аналог, Low-Latency DASH (LL-DASH), использует chunked CMAF и попадает в тот же диапазон.

Ниже находится связь в реальном времени. WebRTC даёт менее 500 миллисекунд «стекло-в-стекло», но меняет экономику масштаба CDN и широкий охват устройств на эту скорость, поэтому это правильный инструмент для настоящей интерактивности (торги, ставки, двусторонние звонки) и неправильный – для трансляции на миллион зрителей.

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

Дисциплина в том, чтобы брать самый медленный уровень задержки, который реально терпит ваш сценарий, потому что каждый шаг вниз стоит охвата, денег или того и другого. Совместный просмотр кинофестиваля устроит и 18 секунд. Live-ставкам нужна задержка меньше секунды, и они за это платят. У VOD этого разговора нет вовсе.

Где они расходятся: масштабирование и отказоустойчивость

Конвейеры масштабируются по-разному, и путать две задачи масштабирования – классическая и дорогая ошибка.

VOD-трафик предсказуем и размазан. Спрос каталога растёт и падает с релизами и временем суток, но редко приходит весь в одну и ту же секунду. VOD масштабируют, держа высокий коэффициент попадания в кэш и давая CDN поглощать длинный хвост.

Live-трафик пиковый и синхронизированный. Когда матч стартует, сто тысяч зрителей запрашивают самый новый сегмент в один миг – громовое стадо (thundering herd). Каждый запрос, который edge не отдаёт из кэша, – промах кэша (cache miss) – идёт обратно на ориджин, поэтому синхронный live-старт способен затопить незащищённый ориджин и обрушить событие сразу для всех. Защита – экранирование ориджина (origin shield, промежуточный кэш, схлопывающий множество промахов edge в один запрос к ориджину), прогрев edge до запланированного старта и запас мощности под пик, а не под среднее. Подробности – в разделе про доставку; суть в том, что live-премьера – это DoS-атака, которую вы планируете на собственный ориджин, и вы готовитесь к ней или она случается с вами.

Где они сходятся: общий стержень

Хорошая новость, делающая «одна платформа, оба конвейера» реальной. Как только видео закодировано и нарезано, live- и VOD-линии передают эстафету одной и той же задней половине. Доставку, защиту, плееры и аналитику не строят дважды.

• Упаковка. Оба конвейера упаковывают в CMAF (Common Media Application Format, ISO/IEC 23000-19) – единый формат фрагментированного MP4, на который ссылаются и манифест HLS .m3u8, и манифест DASH .mpd. Упаковать раз, отдавать на любое устройство – будь источником файл или поток.
• Защита контента. Оба используют один шаг Common Encryption (CENC, ISO/IEC 23001-7): зашифровать сегменты один раз схемой cbcs, затем выдавать лицензии Widevine, PlayReady и FairPlay из тех же файлов – «зашифровать раз, лицензировать много». Multi-DRM – уникальное ядро этого раздела; см. multi-DRM: один workflow, все устройства.
• Доставка. Оба конвейера доставляют через один и тот же CDN и ориджин. Поведение кэша различается (VOD дружелюбен к кэшу, live пиковый), но инфраструктура общая.
• Плееры. Те же приложения-плееры на web, мобильных и TV воспроизводят оба. Live-поток и VOD-тайтл – оба просто манифест, указывающий на CMAF-сегменты; плеер адаптируется.
• Права доступа и аналитика. Один и тот же сервис прав (entitlement) решает, кому можно смотреть (подписка, права, гео, конкурентность), для обоих, и один и тот же приёмник аналитики записывает обе сессии.

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

Архитектурное правило: конвейеры различны до транскодера включительно и одинаковы начиная с упаковщика. Стройте общий стержень один раз; стройте в него два фронтенда.

Live-реклама и мост live-to-VOD

Два места, где конвейеры соприкасаются, стоит рассмотреть ближе – там команды недооценивают объём работы.

Вставка рекламы в live опирается на SCTE-35, двоичный стандарт меток (недавно переструктурирован в SCTE 35-1, с упрощённым дополнением SCTE 35-2 в 2025 году), который размечает точный кадр начала и конца рекламного перерыва внутри live-потока. Метка splice_insert или time_signal сообщает рекламной системе «перерыв начинается здесь, такой длины», а серверная вставка (SSAI) сшивает рекламу в манифест в этой точке. VOD-рекламу можно планировать по известной таймлинии; live-перерывы нужно сигнализировать и заполнять, пока идёт событие. Рекламная сантехника – это монетизация, другое уникальное ядро раздела; см. SCTE-35 и сигнализация рекламы.

Live-to-VOD – мост, превращающий завершённую трансляцию в актив по запросу. Те же сегменты, что отдавались в live, записываются – часто с окном DVR, которое уже позволяет зрителям ставить на паузу и перематывать live-поток, – а затем публикуются как догоняющий (catch-up) или архивный тайтл. Поскольку live-метки (SCTE-35) тоже записаны, догоняющая версия может переиспользовать те же точки рекламных перерывов. Сделанное хорошо, live-событие становится VOD-тайтлом через минуты после окончания, без перекодирования: вывод live-конвейера просто перетекает в VOD-библиотеку.

Частая ошибка: запас под live как под VOD

Самая дорогая live-ошибка, которую мы видим, – рассчитывать live-вычисления и доставку как для VOD. Команда, отгрузившая VOD, считает, что live – это «то же самое, но в эфире», ставит парк транскодинга среднего размера и один CDN, а затем приходит первое реальное событие: энкодер не успевает за потоком в реальном времени, незащищённый ориджин плавится от синхронного старта, и второго шанса переснять трансляцию нет. Live нужно рассчитывать на пик и всплеск, с дублирующими энкодерами, экранированным ориджином, отказоустойчивостью на нескольких CDN и прогретым edge. Эластичный, средний, дружелюбный к повторам подход VOD сюда не переносится.

Сравнение затрат на примере

Формы затрат различаются достаточно, чтобы показать их рядом. Простой случай: каталог VOD на 100 часов против одного live-события на 2 часа, оба на лестнице из четырёх ступеней.

Числа иллюстративны (облачные ставки транскода и egress меняются – уточняйте при сборке), но урок – в форме: затраты VOD определяются хранением и ровной доставкой, затраты live – постоянными вычислениями в реальном времени и резервированием, которого требует правило «второго шанса нет».

Где здесь Фора Софт

Большинство стриминговых продуктов не чисто live и не чисто VOD – это каталог с live-событиями сверху, и требование масштаба в том, чтобы запускать оба, не удваивая платформу. Фора Софт с 2005 года строит видеостриминг, OTT/Internet TV, live-вещание, видеоконференции и e-learning – 250+ отгруженных проектов для 400+ клиентов, – а это ровно опыт проектирования одного общего стержня доставки, защиты и аналитики, который питают два разных фронтенда: пакетный VOD-энкодер и live-энкодер реального времени. Мы разводим расхождение там, где ему место (приём, транскодинг, бюджет задержки), и сводим там, где это окупается (упаковка, DRM, CDN, плееры, права доступа), чтобы платформа получила live, не оплачивая вторую копию себя.

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

• VOD кодирует один раз и отдаёт всегда; live кодирует в реальном времени без второго шанса.
• Конвейеры расходятся только на приёме, транскодинге и цели задержки.
• Начиная с упаковщика – CMAF, DRM, CDN, плеер, аналитика – они общие.
• Задержку «стекло-в-стекло» определяет буфер сегментов: 18 с наивно, 2–5 с LL-HLS, <1 с WebRTC.
• Live масштабируют под синхронные пики; закладывайте пик, резерв и origin shield.
• Live-to-VOD превращает трансляцию в догоняющий тайтл без перекодирования.

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

• Что такое OTT-платформа, от начала до конца
• Конвейер стриминга, блок за блоком
• Масштабирование и конкурентность: от 1 000 до 1 000 000 зрителей