04 Протоколы реального времени vs доставки контента
Протоколы реального времени и массовой доставки: зачем их различать
При проектировании любой видеосистемы — от простой IP‑камеры до онлайн‑трансляции для десятков тысяч зрителей — почти всегда встаёт один и тот же вопрос:
Что важнее: минимальная задержка (почти «живое» видео) или возможность обслужить большую аудиторию?
Ответ на этот вопрос определяет выбор класса медиапротоколов. В этой части мы разберём две большие группы:
- протоколы реального времени (RTP, RTSP, NDI, SRT);
- протоколы массовой доставки контента (HLS, DASH, CMAF).
1. Протоколы «реального времени»
1.1. Что значит «реальное время» для медиа
Под протоколами реального времени в контексте аудио‑видео понимаются протоколы, которые:
- ориентированы на минимальную задержку — доли секунды или единицы секунд;
- стараются доставить кадр как можно ближе к моменту его захвата;
- допускают небольшие потери качества или отдельных пакетов, если это позволяет не задерживать весь поток.
Идея: пользователю важно видеть «почти сейчас», даже если иногда картинка чуть дернулась или качество слегка просело.
Пример в жизни:
Когда оператор управляет поворотной камерой (PTZ‑камерой) во время живого мероприятия, он должен видеть реакцию камеры сразу после поворота джойстика. Задержка в 10–20 секунд сделает управление практически невозможным.
1.2. Типичные области применения
Протоколы реального времени используются там, где важен живой отклик и оперативный контроль:
-
Лайв‑продакшен (live production)
Это внутренняя технологическая цепочка на мероприятии, в студии или на площадке:- камеры → видеомикшер;
- видеомикшер → режиссёрские мониторы;
- сигнал между студийными узлами.
Здесь оператору нужно моментально видеть результат переключений, наложения графики и т.д.
-
Видеомониторинг и безопасность
Пример:- Охранник смотрит на экраны с камеры на складе;
- Инженер следит за производственной линией.
В обоих случаях важно увидеть событие в момент его возникновения, а не спустя десятки секунд.
-
Внутренние студийные сети
Это локальные сети внутри телестудий, продакшен‑комплексов, концертных площадок, где:- устройства связаны между собой напрямую или через управляемые коммутаторы;
- сеть, как правило, не рассчитана на тысячи зрителей, но должна обеспечивать надежную и быструю доставку сигнала между узлами.
::: warn Даже в этих примерах есть большая разница в понятии «реальное время». Если в работе охранника задержка даже в секунду ничего не изменит, то при сборке потоков с камер в микшере важно попадать «кадр-в-кадр», и оператор PTZ камеры (управляемой дистанционно) тоже должен видеть поток без задержек, иначе при повороте он уведет камеру дальше, чем нужно. Здесь задержка больше одного кадра (40 мс) уже не совсем реальное время.
:::
::: info На практике есть компромиссное значение, которого стоит придерживаться и которое более реалистично достичь в сетевом видео -- 200-300 мс. Это примерное время реакции человека от получения зрительной информации до мышечной команды.
:::
1.3. Протоколы реального времени: RTP, RTSP, NDI, SRT
Рассмотрим протоколы, относящиеся к этой группе, на концептуальном уровне.
1.3.1. RTP (Real-time Transport Protocol)
- Назначение: базовый транспортный протокол для передачи аудио и видео в реальном времени.
- Особенности:
- работает, как правило, поверх UDP (User Datagram Protocol);
- использует номера последовательности и метки времени в заголовке для восстановления порядка кадров и синхронизации.
RTP обычно «спрятан» внутри других протоколов. Например, при использовании RTSP именно RTP физически переносит медиоданные.
1.3.2. RTSP (Real Time Streaming Protocol)
- Назначение: протокол управления (сигналинга) для сессий потокового видео.
- Особенности:
- управляет сессией: команды вида SETUP, PLAY, PAUSE, TEARDOWN;
- для передачи самих медиа обычно использует RTP/UDP;
- широко применяется в IP‑камерах: видеопоток с камеры чаще всего доступен по RTSP.
::: warn Важно: RTSP сам по себе не несёт видео. Он описывает, как и откуда его получать, а реально кадры передаются по RTP.
:::
1.3.3. NDI (Network Device Interface)
- Назначение: протокол для передачи видео по IP внутри студий и продакшена.
- Особенности:
- ориентирован на низкую задержку внутри локальной сети;
- поддерживает высокие битрейты и качество, иногда близкое к SDI;
- содержит механизмы обнаружения источников (NDI Discovery) и передачу служебных данных.
NDI удобно использовать как «виртуальный SDI по IP» внутри студии, когда нужно быстро «протянуть» видео между программами и устройствами в одной сети.
1.3.4. SRT (Secure Reliable Transport)
- Назначение: надёжная передача потокового видео через нестабильные сети, например, через Интернет.
- Особенности:
- использует механизмы коррекции ошибок и повтора пакетов;
- шифрует поток (Secure в названии);
- при грамотной настройке позволяет удерживать задержку на уровне отдельных секунд даже при потерях пакетов.
SRT часто выбирают, когда нужно доставить сигнал от удалённой площадки до студии, сохраняя приемлемую задержку для лайв‑работы.
1.4. Почему они часто работают поверх UDP
Большинство протоколов жёсткого реального времени используют UDP:
- UDP не гарантирует доставку и порядок пакетов;
- зато он не ждёт подтверждений, не блокирует очередь пакетов;
- это позволяет не задерживать поток из‑за потери одного пакета.
В медиаконтенте допустимо:
- иногда потерять один‑два пакета (короткий «глюк» картинки),
- но недопустимо задержать весь поток на секунды из‑за ожидания повторной передачи.
Поэтому типичный стек выглядит так:
- IP → UDP → RTP → медиаданные;
- управление сессией: RTSP (поверх TCP), но сами медиа — по RTP/UDP.
1.5. Ограничения по количеству получателей
Протоколы реального времени изначально не оптимизированы под ситуацию «один источник — тысячи зрителей»:
- каждое новое соединение — это новая сессия;
- сервер или устройство (например, камера) должны отправлять поток отдельно каждому клиенту;
- нагрузка на сеть и устройство быстро растёт.
Для локальных задач (пара‑тройка клиентов, несколько десятков в пределах продакшена) это приемлемо. Но для массового интернет‑вещания этого уже недостаточно.
2. Протоколы массовой доставки контента
2.1. Основная цель: масштабируемость и устойчивость
Протоколы массовой доставки (HLS, DASH, CMAF) проектируются с другой приоритетной целью:
Обслужить большое количество зрителей (сотни, тысячи, десятки тысяч) с приемлемым качеством и стабильностью.
Ключевые особенности:
- работают поверх HTTP (обычно HTTP/HTTPS поверх TCP);
- поток делится на небольшие фрагменты (сегменты);
- сегменты отдаются через обычные web‑серверы и CDN (Content Delivery Network).
Здесь уже не столь критична задержка, зато очень важно:
- чтобы выдержалась высокая нагрузка,
- чтобы зрители в разных регионах получили поток без сбоев.
2.2. Как устроена фрагментация потока
Вместо непрерывного потока (как при UDP/RTP) медиа разбивается на отдельные файлы‑фрагменты:
- Видеосервер или энкодер записывает, например, каждые 2–6 секунд видео в отдельный сегмент.
- Параллельно формируется плейлист (манифест) — файл, в котором перечислено:
- какие сегменты есть;
- в каком порядке их воспроизводить;
- какие есть варианты качества (битрейты, разрешения).
- Плеер у зрителя периодически:
- скачивает актуальный плейлист по HTTP;
- загружает указанные сегменты по мере необходимости;
- добавляет их в буфер воспроизведения.
Сегменты могут храниться и кэшироваться на серверах CDN, что существенно снижает нагрузку на исходный сервер.
2.3. Кратко о HLS, DASH и CMAF
2.3.1. HLS (HTTP Live Streaming)
- Изначально разработан Apple.
- Долгое время был де‑факто стандартом для онлайн‑вещания, особенно на устройствах Apple.
- Использует плейлист (обычно
.m3u8) и сегменты (обычно.tsили фрагментированный.mp4).
2.3.2. MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
- Открытый стандарт, не привязан к одному вендору.
- Похож по идее на HLS: есть манифест и сегменты.
- Поддерживает адаптивный битрейт: плеер может динамически переключаться между разными качествами потока.
2.3.3. CMAF (Common Media Application Format)
- Формат, стандартизирующий контейнер и структуру сегментов для совместимости между разными системами.
- Часто используется в связке с HLS и DASH, чтобы унифицировать хранение и доставку сегментов.
Общая идея у всех: разложить медиапоток на части, которые удобно доставлять и кэшировать через стандартную веб‑инфраструктуру.
2.4. Роль HTTP и CDN
HTTP (HyperText Transfer Protocol) — стандартный протокол, который используют браузеры для загрузки веб‑страниц, файлов, изображений и т.п.
Использование HTTP в видеостриминге даёт ключевые преимущества:
- Можно применить CDN (Content Delivery Network):
- распределённая сеть серверов по всему миру;
- зритель запрашивает сегменты не с одного центрального сервера, а с ближайшего к нему узла;
- уменьшается задержка сети и нагрузка на исходный сервер.
- Легче проходить через файрволы и NAT:
- HTTP‑трафик обычно разрешён и не блокируется;
- не нужно настраивать сложные сетевые правила под нестандартные протоколы.
- Можно использовать привычную инфраструктуру:
- балансировщики нагрузки;
- обычные веб‑серверы (Nginx, Apache);
- стандартные средства мониторинга и логирования HTTP.
2.5. Задержка как плата за масштабируемость
Главный минус такой схемы — увеличенная задержка:
- Плеер обычно буферизует несколько сегментов (например, 2–3 сегмента по 4 секунды),
- плюс время на генерацию нового сегмента на стороне сервера.
В результате:
- задержка от момента захвата кадра до его отображения может достигать:
- нескольких секунд (при агрессивной настройке на низкую задержку),
- до 20–30 секунд и более (при стандартных настройках буферизации и длины сегмента).
Для массового зрителя, смотрящего трансляцию концерта или лекции, задержка в 15–30 секунд обычно приемлема, если поток стабилен и не прерывается.
Но для задач интерактивного управления или точной синхронизации действий такая задержка слишком велика.
3. Сравнение протоколов по ключевым параметрам
Ниже — краткое сравнение двух классов протоколов с точки зрения основных требований.
| Критерий | Протоколы жёсткого реального времени (RTP, RTSP, NDI, SRT) | Протоколы массовой доставки (HLS, DASH, CMAF) |
|---|---|---|
| Основная цель | Минимальная задержка, живой отклик | Масштабируемость, работа с большой аудиторией |
| Типичная задержка | Доли секунды – несколько секунд | От нескольких до десятков секунд |
| Базовый транспорт | Чаще всего UDP (иногда + механизмы надёжности) | HTTP поверх TCP |
| Количество зрителей | Небольшое (единицы, десятки, иногда сотни) | Большое (сотни, тысячи, десятки тысяч и более) |
| Отношение к потерям пакетов | Лучше допустить мелкие потери, чем увеличить задержку | Стремление к надёжной доставке каждого фрагмента |
| Типичная область применения | Мониторинг, продакшен, внутренняя передача сигнала | Публичное интернет‑вещание, VOD, массовые стримы |
| Использование CDN | Обычно нет или ограниченно | Ключевой элемент архитектуры |
4. Как выбирать протокол: привязка к задачам
Выбор между протоколами жёсткого реального времени и протоколами массовой доставки всегда зависит от конкретной задачи.
4.1. Когда важен живой контроль и управление
Если система используется для:
- просмотра и управления IP‑камерой в режиме реального времени;
- работы с видеомикшером (переключение камер, наложение графики и т.п.);
- технологического мониторинга (оператор должен моментально видеть, что происходит);
то приоритетом будет минимальная задержка.
В таких случаях обычно выбирают:
- RTSP — для доступа к потокам IP‑камер;
- SRT — для передачи сигнала между объектами (например, от удалённой площадки в студию) с небольшой задержкой и повышенной надёжностью;
- NDI — для передачи видео внутри студийной сети между программами и устройствами.
4.2. Когда важен широкий охват и массовая аудитория
Если задача — трансляция в Интернет для большой аудитории:
- онлайн‑лекции и вебинары;
- концерты, спортивные мероприятия;
- новостные трансляции на платформах;
то приоритетом становятся:
- способность обслужить много зрителей;
- устойчивость к всплескам нагрузки;
- возможность использовать существующую веб‑инфраструктуру.
В таком случае обычно выбирают:
- HLS — как один из наиболее распространённых протоколов для HTTP‑стриминга;
- DASH — как открытый стандарт с адаптивным битрейтом.
При этом часто используется комбинированная схема:
- Внутри продакшен‑цепочки — протоколы реального времени (NDI, SRT, RTSP/RTP).
- На выход в Интернет — HLS/DASH для массового зрителя.
5. Итог: два класса протоколов — два разных приоритета
Протоколы реального времени (RTP, RTSP, NDI, SRT) и протоколы массовой доставки (HLS, DASH, CMAF) решают разные задачи:
- первые минимизируют задержку и подходят для управления, мониторинга и внутреннего продакшена;
- вторые обеспечивают масштабируемую доставку контента большому числу зрителей, но вводят дополнительную задержку.
При проектировании видеосистемы важно:
- Ясно сформулировать приоритет: задержка или масштаб.
- Подобрать протоколы, которые соответствуют этому приоритету.
- Понимать, что в реальных проектах часто используются комбинации:
низкая задержка внутри системы + масштабируемая доставка наружу.