03 Другие стриминговые протоколы
Обзор ключевых медиапротоколов: RTMP, SRT, WebRTC, HLS и DASH
В этом разделе мы разберём набор медиапротоколов, с которыми вы будете сталкиваться в курсе и в практической работе: RTMP, SRT, WebRTC, HLS и DASH.
Разберемся:
- где и для чего каждый протокол используется;
- какие у него сильные и слабые стороны;
- как он соотносится с задачами стриминга, видеосвязи и массовой доставки контента;
- как все они «встречаются» в инструментах OBS и FFmpeg.
1. RTMP: классический протокол для стриминговых платформ
RTMP (Real-Time Messaging Protocol) — один из старейших и до сих пор широко используемых протоколов для передачи потокового аудио и видео на стриминговые платформы.
1.1. Основное назначение RTMP
RTMP исторически применялся для доставки видео в Adobe Flash‑плеер. Сейчас Flash как платформа исчез, но RTMP остался в качестве протокола “входа” (ingest) на стриминговые сервисы:
- YouTube Live
- Twitch
- VK
- и многие другие платформы
Типовой сценарий:
- Вы запускаете OBS или другой программный энкодер.
- Вводите URL RTMP‑сервера и ключ трансляции.
- OBS кодирует видео (например, в H.264) и отправляет поток по RTMP на сервер площадки.
- Платформа уже сама перекодирует и перераздаёт видео зрителям по другим протоколам (чаще всего HLS/DASH).
1.2. RTMP и транспорт TCP
RTMP работает поверх TCP — транспортного протокола, который:
- гарантирует доставку всех пакетов;
- обеспечивает порядок следования данных (ничего не «перемешивается»);
- при потере пакета выполняет ретрансляцию (повторную отправку).
Плюсы для медиа:
- высокая надёжность доставки;
- данные приходят в том порядке, в котором были отправлены, что удобно для декодера.
Минусы для живого видео:
- при потере пакетов TCP «задерживает» весь поток, пока не получит недостающие данные (эффект head-of-line blocking);
- это приводит к умеренной задержке: для онлайн‑стримов с RTMP задержка до зрителя обычно составляет несколько секунд.
На практике это означает: для классической трансляции (вы стримите концерт или лекцию в интернет) такая задержка приемлема. Для интерактивного общения (видеозвонки, онлайн‑игры с мгновенной реакцией) — уже нет.
::: info В среде Adobe Flash потоки FLV (Flash Video) по протоколу RTMP показывались с небольшой задержкой -- часто меньше 1 секунды, что позволяло использовать его для видеосвязи и у МИЭМ.ТВ был целый сервис видеоконференцсвязи, обеспечивавший поддержку медиаслужбы Департамента ЖКХ Москвы ~15 лет назад.
При настройке связи параллельный разговор по мобильному телефону мог иметь такую же задержку. Но вне своей родной среды RTMP обычно имеет задержку около 5 секунд и выше.
:::
2. SRT: надёжный транспорт через ненадёжный интернет
SRT (Secure Reliable Transport) — протокол, созданный специально для надёжной передачи профессионального видео по ненадёжным каналам, в первую очередь через интернет.
2.1. Цели и сценарии использования SRT
SRT ориентирован на ситуации, когда:
- сеть даёт потери пакетов;
- задержка должна быть ниже, чем у типичных HTTP‑протоколов (HLS/DASH);
- требуется защищённая передача (через публичный интернет).
Примеры сценариев:
- доставка сигнала с выездной камеры или кодера из другой страны в центральную студию;
- резервный канал для основной трансляции;
- соединение двух площадок продакшена, между которыми нет “идеального” канала.
2.2. Как SRT борется с потерями и снижает задержку
SRT сочетает низкую задержку с устойчивостью к потерям пакетов за счёт нескольких механизмов:
- FEC (Forward Error Correction) — прямое исправление ошибок.
Отправитель добавляет к потоку избыточную информацию. Если в пути теряется часть пакетов, приёмник может восстановить их, не запрашивая повторную отправку каждого потерянного пакета. - Ретрансляция (ARQ — Automatic Repeat reQuest)
Если ошибок слишком много и FEC не справляется, приёмник может запросить переотправку отдельных пакетов.
В отличие от TCP, SRT оптимизирован под видео: он старается минимизировать задержку, а не любой ценой доставить абсолютно все байты. - Настраиваемый буфер задержки
В SRT можно задавать размер буфера (latency buffer). Чуть увеличив задержку (например, на десятки миллисекунд или несколько сотен миллисекунд), мы даём протоколу «запас по времени» для восстановления потерянных пакетов и сглаживания джиттера (колебаний задержки).
Итог: для профессиональных стриминговых задач через интернет SRT часто предпочтительнее классического UDP‑RTP и удобнее, чем VPN+RTMP, потому что он заточен именно под видео с контролируемой задержкой и защитой от потерь.
::: info Опыт здесь расставляет акценты иначе:
RTMP уже давно -- ingest-протокол, нужный только для отправки потока с места трансляции на CDN (Content Delivery Network) или иную медиаплатформу вроде VK. Его преимущество в том, что вам не нужен "белый" IP адрес, чтобы началь вещание: вы на передатчике указываете, куда нужно отправить поток, а приёмник ничего не знает о вашем адресе и не сможет узнать в обычной жизни. Сервер здесь -- приёмник. Это накладывает особые требования к безопасности: нужно хранить ключ трансляции в секрете, чтобы на вашем канале не выступил кто-нибудь другой с удивительным контентом.
RTSP -- обычно используется для сбора потоков с камер и кодеров (кодер преобразует видеосигнал в сетевой видеопоток). Во всех учебниках его помещают в "медленные", но на деле это не совсем так, просто нужно уметь с ним работать. Здесь ключевая роль у движка GStreamer. Например, в МИЭМ вся технологическая цепочка видеопроизводства построена на RTSP и микшере OBS с плагином GStreamer. И это позволяет работать с видео с задержками, близкими к реальному времени (300-500 мс). Учитывая, что камеры сами имеют немалую задержку, на практике оказывается, что не только NDI не очень-то быстрее, а то и медленнее, но и передача видеосигнала по SDI с последующей оцифровкой платой захвата даёт те же результаты. Почему RTSP так хорош в системах видеонаблюдения? Потому что в нем сервер -- это камера. Сети видеонаблюдения обычно четко фиксированы и часто отделены от рабочих сетей предприятий, там порой камеры находятся на статических адресах. И, когда поток не показывается и не записывается, он и по сети не передается. Или, например, когда показывается "мультискрин" (много окошек на одном экране), то передается не основной, а "субпоток" -- маленькая версия основного потока -- все это существенно снижает трафик в сети, что актуально, когда камер у вас сотни. RTSP не предназначен для "тяжелых" потоков, обычный поток с IP камеры FullHD -- 3-6 Мбит/с. И попытки сделать его кратно тяжелее приводят не к улучшению качества, а к подвисанию потока в плеере.
SRT -- изначально позиционировался как быстрый и проходимый через Интернет. И вы увидите его в топе по минимальной задержке в разных рейтингах. На практике, может быть он в теории такой быстрый, но реализация в доступном ПО и отзывы в профессиональном сообществе показывают, что заявленные задержки не достигаются и протокол был явно переоценен и по скорости, и по проходимости.
:::
3. WebRTC: видеосвязь в браузере
WebRTC (Web Real-Time Communication) — технология для передачи аудио, видео и данных в режиме реального времени, изначально ориентированная на веб‑браузеры.
3.1. Где используется WebRTC
Основные области применения:
- видеозвонки один-на-один (peer-to-peer);
- групповые видеоконференции (через серверы‑мосты);
- онлайн‑вебинары и консультации, где критична обратная связь в реальном времени;
- встраивание видео‑ и аудио‑коммуникации прямо в веб‑страницы без установки дополнительного ПО.
Большинство современных браузеров (Chrome, Firefox, Safari, Edge) поддерживают WebRTC «из коробки».
3.2. Ключевая особенность: минимальная задержка
Для WebRTC критически важно, чтобы задержка передачи медиа была:
- меньше 0,5 секунды (полусекунды);
- а в идеале — в диапазоне 100–300 миллисекунд.
Такая задержка воспринимается пользователем как «почти мгновенная» связь. Это важно:
- при живом диалоге: собеседники не должны «перебивать» друг друга из‑за больших задержек;
- при интерактивных приложениях (например, удалённое управление, онлайн‑игры с видеоканалом).
3.3. Особенности WebRTC как медиапротокола
Без углубления в детали стека, важно понимать несколько моментов:
- WebRTC работает поверх UDP (чаще всего), чтобы избежать задержек TCP при потерях.
- Протокол оптимизирован под адаптацию к реальной сети:
- динамически меняет битрейт и качество (битрейт‑адаптация),
- борется с джиттером и потерями,
- использует механизмы обхода NAT (ICE, STUN, TURN).
- Поддерживает сквозное шифрование медиа (SRTP), что важно для безопасности видеосвязи.
В отличие от RTMP и SRT, WebRTC обычно не предназначен для трансляции «на миллионы зрителей», но идеально подходит для интерактивной связи и приложений, где каждый зритель — активный участник.
::: info WebRTC создавался как замена RTMP, который хоронить начали в 2011 году, а совсем отключили в браузерах только через 10 лет. И появился WebRTC в 2012, но делал он это очень постепенно: первые лет пять поддержка в браузерах была не гарантирована, а какие поддерживали, могли это делать частично. Сейчас детские болезни прошли и WebRTC активно используется в видеосвязи. Когда вы видите видеоконференцсвязь в браузере -- это WebRTC. Если платформа видеосвязи использует своё приложение, там может быть другой протокол и другие кодеки, которые в браузере не работают. Одной из имплементаций WebRTC является Jitsi -- движок, на котором построена миэмовская система видеосвязи Meet.miem.hse.ru.
Только важно понимать, что WebRTC -- это пиринговый протокол, а многосторонняя видеосвязь требует наличия медиасервера, который создает столько соединений, сколько участников находится в комнате видеоконференции. Чтобы на этом сэкономить, некоторые платформы используют приём "пассивного участника": при подключении вы смотрите сеанс видеосвязи, но чтобы участвовать, нужно нажать кнопку "выйти в эфир" или что-то подобное: по сути вам показывают трансляцию видеовстречи, а после нажатия на эту кнопку вы становитесь её участником с отдельной сессией WebRTC. Этим же обосновано ограничение максимального числа участников -- каждый участник нагружает медиасервер. Зато соеднинение 1:1 совершенно бесплатно для провайдера сервиса, он только помогает организовать соединение.
:::
::: info WebRTC интересен еще и тем, что он поддерживает не только видеосвязь. Вы можете сделать, например, чат или файлообменник, используя этот протокол.
:::
4. HLS и DASH: протоколы сегментной доставки контента
HLS (HTTP Live Streaming) и MPEG‑DASH (Dynamic Adaptive Streaming over HTTP) — это протоколы доставки медиаконтента, которые изначально проектировались для массовой раздачи видео большому числу зрителей.
4.1. Принцип сегментной (кусочной) доставки
И HLS, и DASH используют схожую идею:
- Исходный медиапоток (например, live‑стрим) разбивается на короткие сегменты — файлы длительностью несколько секунд (часто 2–6 секунд).
- Сервер хранит список этих сегментов в манифесте (playlist / manifest), который загружает плеер.
- Плеер по HTTP запрашивает:
- сначала манифест,
- затем по одному сегменту, последовательно.
Такая модель даёт два ключевых преимущества:
- Возможность использовать обычную веб‑инфраструктуру: HTTP‑серверы, CDN, кэширование.
- Масштабируемость при очень большом числе зрителей.
4.2. Адаптивное качество (adaptive bitrate)
HLS и DASH позволяют отдавать видео в нескольких вариантах качества и битрейта:
- 1080p (Full HD), высокий битрейт;
- 720p, средний битрейт;
- 480p и ниже — для слабых каналов.
Клиентский плеер:
- измеряет текущие сетевые условия (скорость загрузки, ошибки, задержки);
- автоматически выбирает подходящий вариант качества;
- может «переключаться вниз», если канал стал хуже, или «вверх», если улучшился.
Для зрителя это выглядит как временное ухудшение/улучшение качества картинки при сохранении более‑менее стабильного воспроизведения без постоянных остановок на буферизацию.
4.3. Масштабируемость и задержка
Сегментная модель и HTTP дают высокую масштабируемость:
- можно использовать CDN (Content Delivery Network), которые кэшируют сегменты ближе к зрителю;
- серверы и сеть могут обслуживать сотни тысяч или миллионы зрителей одновременно.
Однако за счёт сегментов неизбежно появляется дополнительная задержка:
- пока сегмент длиной, например, 4 секунды полностью сформирован и сохранён на сервер, проходит это время;
- плеер обычно буферизует ещё несколько сегментов вперёд для надёжного воспроизведения.
В итоге суммарная задержка для HLS/DASH при стандартных настройках часто составляет 10–30 секунд, хотя существуют специальные режимы низкой задержки (Low Latency HLS/DASH).
5. Особенности HLS и DASH: экосистема и совместимость
Хотя HLS и DASH похожи по принципам, у них есть различия в происхождении и экосистеме.
5.1. HLS
- Разработан компанией Apple.
- Широко используется в экосистеме Apple:
- iOS,
- macOS,
- tvOS и др.
- Де‑факто стандарт для мобильного и веб‑стриминга, особенно на устройствах Apple.
- Поддерживается большинством медиасерверов и плееров.
5.2. MPEG-DASH
- Открытый стандарт, разработанный консорциумом MPEG.
- Не привязан к конкретному вендору.
- Получил широкую поддержку в профессиональных инструментах:
- в том числе в FFmpeg,
- поддерживается в OBS для определённых сценариев (через плагины или внешние утилиты / серверы).
В реальных системах часто используют комбинацию: SRT или RTMP для доставки сигнала от энкодера до сервера, и HLS/DASH — для раздачи конечным зрителям.
6. Интеграция протоколов с OBS и FFmpeg
Все описанные протоколы активно используются в практических инструментах, с которыми вы будете работать на курсе: OBS и FFmpeg.
6.1. OBS (Open Broadcaster Software)
OBS — популярная программа для:
- захвата видеосигналов (веб‑камеры, окна, экраны);
- микширования (накладки, сцены, графика);
- кодирования и отправки потоков.
В контексте протоколов:
- RTMP: основное средство отправки трансляций на YouTube, Twitch и т.п.
- SRT: всё чаще поддерживается платформами и серверами как более надёжный способ доставки сигнала.
- HLS/DASH: обычно не используются напрямую в OBS как “выход к зрителю”, но OBS может передавать поток на сервер, который уже формирует HLS/DASH.
- WebRTC: как правило, не основной формат “выхода” OBS, но может быть частью сложной системы (например, через промежуточный сервер или шлюз).
6.2. FFmpeg
FFmpeg — хорошо знакомый вам из курса компьютерной графики универсальный командный инструмент для:
- захвата,
- кодирования и перекодирования (транскодирования),
- упаковки (muxing/demuxing),
- передачи и приёма медиапотоков.
С точки зрения протоколов:
- может отправлять и принимать RTMP (например,
-f flv rtmp://...); - поддерживает SRT как вход и выход (с указанием параметров надёжности, задержки и т.д.);
- умеет работать с HLS и DASH:
- генерировать сегменты и плейлисты;
- читать уже существующие;
- может участвовать в сложных цепочках, где вход идёт по одному протоколу, а выход — по другому:
- пример: вход SRT от удалённого кодера → транскодирование → выход HLS/DASH для зрителей.
7. Сводная таблица по протоколам
Для удобства восприятия сведём основные характеристики в таблицу:
| Протокол | Основное применение | Транспорт | Задержка (типичная) | Ключевые особенности |
|---|---|---|---|---|
| RTMP | Входной поток на стриминговые платформы | TCP | Несколько секунд | Надёжная доставка, проста интеграция с YouTube/Twitch |
| SRT | Профессиональная передача по интернету | поверх UDP | Низкая, настраиваемая | Защита от потерь (FEC, ретрансляция), шифрование |
| WebRTC | Видеосвязь, браузерные приложения | чаще UDP | Сотни миллисекунд (<0.5 c) | Сверхнизкая задержка, встроен в браузеры |
| HLS | Массовая доставка, особенно Apple | HTTP/TCP | Десятки секунд (обычно) | Сегменты, адаптивное качество, поддержка CDN |
| DASH | Массовая доставка, открытый стандарт | HTTP/TCP | Похожа на HLS | Открытый стандарт, поддержка в FFmpeg/OBS |
8. Как эти протоколы используются вместе
В реальных системах редко используется только один протокол на всём пути. Типичная цепочка может выглядеть так:
- Производство сигнала (студия, OBS, кодер):
- выход по RTMP или SRT на медиасервер.
- Медиасервер (обработка, транскодирование, упаковка):
- принимает RTMP или SRT;
- транскодирует в несколько качеств;
- формирует HLS или DASH для конечных зрителей.
- Зритель (браузер, мобильное приложение):
- получает HLS или DASH по HTTP через CDN.
Параллельно может существовать отдельный канал на WebRTC для спикеров, модераторов или интерактивных участников, где важна минимальная задержка.