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

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

TL;DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть ещё один термин, который путают со всеми тремя. Linear streaming – это каналы с фиксированным расписанием, как в традиционном телевидении: зрители подключаются к текущему эфиру и не могут перематывать за пределы окна DVR. Linear может быть 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 и историю развития протоколов доставки. Цифры «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-сервисов считается приемлемой; однако такая же задержка в 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-оригин, отправляющий CMAF с чанками по секунде, будет тратить ресурсы впустую, обслуживая каталог Netflix; VOD-сегмент длиной 6 секунд с буфером в 30 секунд невозможно адаптировать под букмекерский продукт задним числом. Архитектура должна подстраиваться под реальные сроки, которые у вас есть.»

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

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

Заголовочный показатель – задержка – складывается из бюджета. Задержка glass-to-glass – время между событием перед объективом и моментом, когда зритель его видит, – представляет собой сумму времени всех стадий конвейера. Типичный workflow для 2026 года в классическом 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-каналов заметно ниже, чем у VOD: по данным CDN-провайдеров, он составляет 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-трансляция с намеренно увеличенным буфером плеера, а также (в большинстве систем производства) программируемая задержка, добавляемая на стороне энкодера. В результате получается лучшее из двух миров для широкого класса продуктов, которым не требуется задержка менее секунды.

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

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

Инженерия здесь – самая дружелюбная из трёх категорий. Near-live использует тот же HLS / DASH / CMAF-пайплайн, что и VOD, а также стандартный live; отличаются только политика буфера и встроенная задержка. Протокол HTTP-основанный, поэтому экономика 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 – по сути задача хранения и вывода данных: после обработки каждый следующий зритель обходится дёшево. Продукт B – задача CDN: пиковая параллельная аудитория сильно влияет на счёт, а 12-секундный буфер – это ключевой приём, позволяющий обойтись стандартной 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-трафиком требует тщательного инструментирования и жёстких on-call-смен.

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

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

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

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

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

• Live, VOD и near-live используют один и тот же конвейер, но с разными дедлайнами – именно дедлайн определяет стоимость.
• VOD – это задача хранения и доставки (egress); live – задача масштабирования и отказоустойчивости; near-live – экономичный компромисс между ними.
• Выбор протокола вторичен по сравнению с требованиями к задержке: HLS/ DASH подходят для VOD и near-live, LL-HLS/LL-DASH – для низколатентного live, WebRTC – для задержек менее секунды.
• 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.