Live, VOD и near-live: три задачи, которые выглядят одинаково, но решаются по-разному

Опубликовано: 2026-05-20 · Время чтения: 14 мин · Автор: Николай Сапунов, CEO Фора Софт

TL;DR

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

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

Если вы прорабатываете видеопродукт, оцениваете бюджет стриминга, ставите задачи инженерам или сравниваете протоколы на слайдах вендора, ответ на каждый важный вопрос начинается с одного: «это live, VOD или near-live?». Выбор между HLS с задержкой 20 секунд и WebRTC с 300 миллисекундами – это не вкусовщина, это следствие дедлайна. То же касается битрейт-лестниц, кэш-политик CDN, экономики DRM-лицензий и тех режимов отказа, которые вы будете отлаживать следующие двенадцать месяцев. Эта статья написана прежде всего для смышлёного нетехнического читателя; senior-инженер стриминга всё равно должен уважать каждую цифру. К последнему абзацу вы сможете сказать, какую из трёх задач решает любая презентация по стримингу – и откуда там берётся счёт.

Три дедлайна, один конвейер

Любой стриминг-продукт проходит один и тот же пятистадийный конвейер – захват, кодирование, упаковка, доставка, воспроизведение, – который мы нарисовали в статье Что такое доставка видео и почему это сложнее, чем отдать JPEG. Между live, VOD и near-live меняются не стадии. Меняется дедлайн на каждой стадии – и, следовательно, какие компромиссы команде разрешены.

Дедлайн – самая полезная оптика. Он объясняет, почему 30-минутный эпизод Netflix и 30-минутный Twitch-стрим для зрителя выглядят как один продукт, а изнутри это совершенно разные задачи.

В VOD никто из конвейера не гонится за часами. Файл существует ещё до того, как зритель нажмёт play, поэтому энкодер может потратить часы на один актив, packager заранее нарезает все сегменты, CDN – chain серверов рядом со зрителями – спокойно реплицирует всё на edge-узлы, а плеер набивает буфер с запасом. Ограничение – стоимость, не время.

В live на часах вся цепочка. Энкодер гонится за камерой, packager режет сегменты, которых секунду назад не существовало, CDN обязан распространять свежие сегменты до того, как они истекут, а плеер держит буфер, достаточно тонкий, чтобы ощущаться «вживую», но толстый ровно настолько, чтобы пережить чихающий Wi-Fi-роутер. Ограничение – задержка, а задержка стоит масштаба, денег или устойчивости – обычно всего сразу.

В near-live контент производится в режиме live, но между захватом и зрителем намеренно вставляется фиксированная задержка – обычно от 5 до 90 секунд, – так что система получает почти всю свежесть live и почти всю устойчивость VOD. Ограничение – выбранная задержка; инженерная задача – соблюсти её точно и предсказуемо, а не минимизировать.

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

Пара слов о терминах

Словарь в этой области – маленькая война за точность. Три определения стоит зафиксировать заранее, потому что вендоры используют их вольно, а вольное использование – это место, где переплачивают.

Video on demand (VOD), «видео по требованию», в эфирной классификации иногда «нелинейное» видео – это доставка контента, который полностью закодирован, упакован и сохранён до того, как зритель его запросит. Зритель может начать, поставить на паузу, перемотать назад, перемотать вперёд и продолжить с того же места. Примеры: сериал Netflix, запись вебинара, загрузка на YouTube, архив университетских лекций.

Live-стриминг – это доставка контента, который производится прямо во время просмотра. Камера издателя и экран зрителя связаны во времени; вопрос только в том, насколько плотно. Примеры: Twitch-трансляция, спортивный матч, live-фид новостей, видеозвонок.

Near-live – это live с намеренно вставленной задержкой. Термин – индустриальный жаргон, ISO-определения нет, но на практике он покрывает любые пайплайны, где издатель закладывает зазор от 5 до 90 секунд между захватом и воспроизведением. Примеры: спорт под букмекерское окно, live-шоппинг с премодерацией, live-новости с буфером на нецензурную лексику и графику, корпоративный town-hall с задержкой на перевод.

Есть ещё один термин, который путают со всеми тремя. Linear streaming – это каналы с фиксированной сеткой вещания, как у традиционного телевидения: зрители подключаются к тому, что идёт прямо сейчас, и не могут перемотать дальше окна DVR. Linear может быть live (канал live-новостей), может быть near-live (спортивный канал с пятисекундным букмекерским буфером) и даже круглосуточный луп предзаписанного VOD. Это понятие про упаковку, а не про дедлайн – и мы рассматриваем его как ортогональное к трём категориям выше.

Дедлайн определяет протокол

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

Нетехнический читатель может вытянуть отсюда две вещи. Во-первых, слова «live-стриминг» прячут разброс в 30 000 процентов по задержке – от sub-second WebRTC до 30-секундного классического HLS, – и ваш таргет задержки – это самый большой проектный вход. Во-вторых, VOD на оси задержки вообще не лежит: это другая задача и другая кривая стоимости, даже если она едет по тому же протоколу.

Каждой строке посвящена своя статья в этом разделе. Мы пишем про HLS подробно, LL-HLS подробно, WebRTC для доставки от peer-to-peer до масштаба, SRT и семейное древо delivery-протоколов. Цифры glass-to-glass выше взяты из диапазонов, заданных IETF RFC 8216 (HLS), Apple HLS Authoring Specification (ревизия 2025-09) для LL-HLS, ISO/IEC 23009-1:2022 для DASH, а также из текущих продакшен-развёрток Netflix, Twitch, Mux и Cloudflare; диапазон WebRTC ограничен снизу W3C WebRTC Candidate Recommendation и семейством RFC 8825–8866.

VOD простыми словами

VOD – самый дешёвый стриминг, который можно выкатить в масштабе, и почти все инженерные рычаги направлены в одну сторону: сделай всё заранее.

Энкодер получает целый файл и неограниченное время. Современный VOD-энкодер прогоняет несколько битрейт-лестниц – список версий одного видео с возрастающими битрейтами, эти версии называются «ступенями», – на скоростях, которые подбираются под качество, а не под стенные часы. Двухчасовой фильм можно проанализировать сцена за сценой, закодировать один раз на высоком качестве и хранить вечно; такой же бюджет на кодировании live-события невозможен. Дизайну лестниц мы посвящаем статью Битрейт-лестница: классический Netflix ladder, per-title, per-shot.

У packager-а и CDN – тот же подарок. Сегменты – короткие самодостаточные куски видео, обычно 2–6 секунд, – нарезаются один раз, хранятся один раз и копируются на edge-узлы CDN, которые обслуживают зрителей из ближайшего города. Один VOD-актив может лежать на edge-узле неделями; как только кэш прогрет, cache hit ratio – доля запросов, которые отвечаются без обращения к origin-серверу, – стабильно держится на уровне 95–99% для VOD-платформ по данным Akamai и Cloudflare. Чем выше это число, тем дешевле каждый байт доставки.

У плеера та же свобода. Live-дедлайна нет, и плеер может буферизовать на десять, двадцать, шестьдесят секунд вперёд. Большие буферы поглощают джиттер – разброс времени прихода последовательных пакетов – и почти полностью убирают видимые подвисания на здоровой сети. Стартовая задержка в 1–2 секунды для VOD приемлема; стартовая задержка в 1–2 секунды в live-спортивном приложении сделала бы продукт неюзабельным для части аудитории.

Арифметика VOD-экономики дружелюбная. Возьмём сервис с каталогом из 1000 тайтлов, каждый по 90 минут со средней ступенью 4 Мбит/с. Реплицировать один тайтл в один регион CDN стоит:

4 000 000 бит/с × 5400 с ÷ 8 = 2,7 ГБ на одну ступень
× 6 ступеней (240p, 360p, 540p, 720p, 1080p, 4K) ≈ 16 ГБ на тайтл
× 1000 тайтлов = 16 ТБ хранилища на регион

Шестнадцать терабайт – это пара подписок на облачное хранилище средней руки. Реальные деньги в VOD уходят на egress – счёт за трафик каждый раз, когда зритель скачивает сегмент с edge-узла, – а не на кодирование и хранение. Когда кэш прогрет, маржинальная стоимость дополнительного зрителя в регионе, где актив уже лежит, ничтожно мала. Доллары мы разворачиваем в Экономика CDN: 95-й перцентиль, commit, overage, transit.

«Ошибка: относиться к VOD как к «live без часов». Самый частый промах в ранних продуктах – переиспользовать одну и ту же низкозадерживающую live-инфраструктуру под VOD или наоборот. Live-origin, гоняющий CMAF chunked transfer с чанками по секунде, будет жечь HTTP-overhead зря, обслуживая Netflix-каталог; VOD-сегмент в 6 секунд с буфером в 30 секунд нельзя задним числом всунуть в букмекерский продукт. Архитектура выбирается под тот дедлайн, который у вас реально есть.»

Live простыми словами

В live дедлайн ставит камера. Каждая последующая стадия получает байты через фиксированное время и обязана сделать свою работу до того, как плеер зрителя захочет нарисовать следующий кадр. Дешёвые трюки, которые делают VOD прибыльным, – предкодирование, предупаковка, длинный edge TTL, глубокие буферы, – просто недоступны.

Заголовочный показатель – задержка, она складывается из бюджета. Задержка glass-to-glass – время между тем, что случилось перед объективом, и моментом, когда это увидел зритель, – это сумма времени каждой стадии конвейера. Типичный 2026-й workflow классического HLS выглядит примерно так:

Захват         5–20 мс
Кодирование    50–500 мс
Packager       200 мс – 4 с (нарезка сегмента доминирует)
Origin / CDN   50–500 мс (распространение, промах кэша)
Буфер плеера   6–30 с (главная статья)
ИТОГО         ~6–35 с

Самый большой вклад – буфер плеера. Буфер не опциональный: это единственное, что прячет джиттер сети от глаз. Опускание буфера до секунды даёт LL-HLS или LL-DASH с glass-to-glass около 2–5 секунд. Опустить ещё ниже – придётся уйти с HTTP полностью: WebRTC, Media over QUIC, перестройка части пайплайна вокруг транспортов поверх UDP. Бюджет мы разворачиваем в Задержка, glass-to-glass, end-to-end.

CDN-экономика тоже переворачивается. Live-сегменты быстро устаревают. Сегмент тридцатисекундной давности уже почти никому не интересен – зрители ушли вперёд по программе. Cache hit ratio для live-edge заметно ниже VOD: отчёты CDN-вендоров ставят live-кэш в диапазон 70–90%, и на масштабе эта разница стоит реальных денег. Live ещё и нагружает инвалидацию кэша, потому что манифест – маленький текстовый файл, из которого плеер узнаёт, какие сегменты тянуть, – переписывается каждые несколько секунд. Edge-конфигурации, идеальные для VOD, тихо ломаются на live, если TTL манифеста не отличается от TTL сегментов.

Масштаб не размазывается, а концентрируется. На live-событии с миллионом зрителей все миллион людей запрашивают примерно одни и те же сегменты в один и тот же момент. Edge CDN обязан вытянуть эту параллельность; origin обязан вовремя опубликовать сегмент; сеть между ними обязана прокачать трафик. Сравните с VOD-библиотекой, где миллион зрителей в день распределяются по тысяче тайтлов и 24 часам – разные сегменты, разное время, разные edge-узлы.

Модель зрительского опыта тоже другая. У live режим отказа – это подвисание или просадка качества ровно в момент гола; у VOD режим отказа – просадка качества, которую можно переждать. Live-аудитории прощают сильно меньше, и live-команды иначе одержимы метриками QoE, чем VOD-команды.

Near-live: недоиспользуемая середина

Near-live – это live с намеренно увеличенным буфером плеера плюс (в большинстве продакшен-систем) программируемая задержка, вставленная на стороне энкодера. Получается лучшее из двух миров для широкого класса продуктов, которым sub-second не нужен.

Причины ввести задержку чисто практические:

• Букмекерские и торговые окна. Спортивному букмекеру нужно, чтобы каждый клиент увидел игровой момент в пределах нескольких секунд друг от друга и уже после того, как контора закрыла приём ставок. Индустриальные таргеты держатся около 5–10 секунд для in-play-ставок – это отчёт Stats Perform о Super Bowl 2026 и материалы Dolby OptiView; жёстче – появится арбитраж между быстрыми и медленными зрителями, шире – пропадает ставка.
• Модерация. Live-шоппинг, live-аукционы и live-конкурсы талантов вставляют 5–30 секунд модерационного буфера, чтобы модератор успел снять стрим, который пошёл не туда. Задержка – это инструмент модерации.
• Live-новости и broadcast-графика. Эфирные cue, экранные графики, субтитры, оверлеи бренда требуют форы. Задержка в 10–60 секунд даёт рендеру время наложить счёт, нижнюю плашку и перевод на live-фид до того, как его увидит зритель.
• Синхронизация очень разных путей. Когда один и тот же контент должен попасть на спутник, эфирное цифровое ТВ, IPTV и OTT-зрителей в пределах нескольких секунд друг от друга, самый медленный путь задаёт бюджет всем остальным. Near-live делает эту синхронизацию возможной, придерживая быстрые пути.

Инженерия здесь самая дружелюбная из трёх категорий. Near-live едет на том же HLS / DASH / CMAF-пайплайне, что VOD и стандартный live; разница только в политике буфера и вставленной задержке. Протокол HTTP-based, поэтому CDN-экономика близка к VOD. Cache hit ratio ближе к VOD, чем к low-latency live, потому что более длинный буфер означает, что один сегмент запрашивается многими зрителями в широком временном окне. Плееру разрешён глубокий буфер, поэтому режим отказа щадящий.

Мы видим near-live как самую недоиспользуемую категорию в ранних продуктовых scope. Основатели регулярно просят «live с самой низкой возможной задержкой», потому что им кажется, что low-latency – это солидно; на деле, когда мы перебираем вертикали, им нужен предсказуемый 5–15-секундный near-live, который стоит в разы дешевле sub-second WebRTC-стека. Near-live ещё и место жительства большинства телевизионно-форматных продуктов: live-спортивный канал на connected TV почти всегда near-live с задержкой 10–45 секунд.

Разбор: один матч, три продукта

Возьмём один и тот же источник – 90-минутный футбольный матч, – упакованный под три разных продукта. Цифры ниже типичны для стека 2026 года и из тех, под которые мы планируем engagement-ы.

Три разные кривые стоимости. Продукт A – по сути задача хранения и egress: после нарезки каждый следующий зритель дёшев. Продукт B – задача CDN: пиковая параллельная аудитория тянет счёт, а 12-секундный буфер – это и есть трюк, который оставляет всё на commodity-HTTP-инфраструктуре. Продукт C – реал-тайм-задача: основная стоимость – SFU (selective forwarding unit, топология WebRTC-серверов, которую мы описываем в SFU, MCU, Mesh: три топологии WebRTC) и региональные мосты, которые предотвращают ситуацию, когда два зрителя оказываются по разные стороны трансокеанского кабеля.

Стриминг-продукт почти никогда не выходит ровно с одним из трёх. Оператор выше с большой вероятностью выкатывает все три сразу: near-live-фид для массового болельщика, sub-second WebRTC-фид для букмекерского продукта и VOD-каталог нарезок после финального свистка.

Что меняется внутри инженерной команды

Категория дедлайна формирует и команду. Мы вели engagement-ы во всех трёх; форма инженерной работы узнаваемо разная.

Проекты в VOD-форме живут в каталоге, кодеках и стоимости. Где сидит лестница? Какая per-title-политика кодирования? Сколько мы платим за ТБ на 95-м перцентиле? Как балансировать охват H.264 против битрейтной экономии AV1? Работа повторяемая, предсказуемая и поощряет аккуратные измерения.

Проекты в live-форме живут в цепочке часов и режимах отказа. Какой контрибуционный протокол с площадки? Как восстановиться после 200-миллисекундной сетевой просадки между энкодером и origin? Как держать манифест свежим на edge, не инвалидируя кэш сегментов? Как недорого наблюдать задержку в продакшене? Live-работа поощряет инструментирование и беспощадные оn-call-смены.

Near-live-проекты выглядят как live с более спокойным ритмом. Нагрузка на on-call ниже, потому что буфер прячет больше, но команда всё ещё владеет часами – таргетная задержка должна быть точной и предсказуемой, потому что и букмекеры, и модераторы, и broadcast зависят от того, чтобы знать, где именно на таймлайне каждый зритель. Мы научились выкатывать near-live с явными timecode-метками в каждом сегменте, чтобы поддержка отвечала на вопрос «что зритель видел в 14:32:07» без догадок.

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

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

Мы выкатывали все три типа стриминга для клиентов в видеоконференциях, OTT, e-learning, телемедицине и live-вещании. Наши live e-learning-стеки регулярно идут в near-live с 6–15-секундной задержкой, чтобы преподаватель успевал работать с чатом, не пропуская вопросы студентов; в OTT-проектах мы выкатываем CMAF-пайплайны live+VOD с общей CDN-экономикой; в телемедицине и видеонаблюдении мы используем WebRTC с sub-second-задержкой, где реакция врача или цикл наблюдения оператора задаёт бюджет. Разговор о выборе архитектуры – это первый день engagement-а; второй уже про то, какая комбинация – почти всегда не одна – нужна продукту на самом деле.

Ключевые тезисы

• Live, VOD и near-live используют один конвейер, но разные дедлайны; именно дедлайн задаёт стоимость.
• VOD – задача хранения и egress; live – задача часов и режимов отказа; near-live – экономичная середина.
• Выбор протокола вторичен относительно задержки: HLS/DASH для VOD и near-live, LL-HLS/LL-DASH для low-latency live, WebRTC для sub-second.
• Near-live – самая недоиспользуемая категория в ранних продуктах: большинство запросов «нам нужен low-latency» на деле near-live.
• Cache hit ratio падает по мере ужесточения задержки: ~99% для VOD, ~90% для LL-HLS, около нуля для WebRTC.
• Большинство реальных продуктов выкатывают сразу больше одной категории; перестраивать всю архитектуру под самый жёсткий дедлайн стоит только тогда, когда он реально нужен.

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

• Что такое доставка видео и почему это сложнее, чем отдать JPEG – общий конвейер, который делят все три категории.
• Задержка, glass-to-glass, end-to-end – бюджет, который решает, какую категорию вы можете себе позволить.
• Семейное древо delivery-протоколов – как соотносятся HLS, DASH, LL-HLS, WebRTC и Media over QUIC.