Потоковое видео давно перестало быть «фокусом для избранных». Камеры на заводе, baby-monitor дома, вебинары, Twitch, видеодомофоны — везде лезут одни и те же базовые задачи: как доставить картинку вовремя, не уронив качество и не убив сеть. Отсюда и зоопарк протоколов: RTP, RTSP, RTMP, ONVIF и ещё целая армия других аббревиатур.
Разберёмся, чем они отличаются, откуда взялись и почему до сих пор живут все разом, а не один «идеальный» протокол.
Слои: кто за что отвечает
Важно сразу разделить роли:
Кодек – как сжата картинка/звук (H.264, H.265, Opus…).
Контейнер – как всё упаковано в файл/поток (MP4, TS, MKV…).
Транспорт – как пакеты ходят по сети (UDP, TCP, QUIC).
Протокол передачи/управления – как организован сам поток (RTP, RTSP, RTMP, HLS, WebRTC и т.п.).
Сигналинг / API – как устройства друг друга находят и договариваются (ONVIF, SIP, WebRTC-сигналинг, проприетарные API).
RTP, RTSP, RTMP и ONVIF находятся на разных уровнях, поэтому напрямую сравнивать их как «альтернативы» не совсем корректно — они часто работают в связке.
RTP: «грузовик», который реально везёт медиапакеты
RTP (Real-time Transport Protocol) появился в середине 90-х под задачи IP-телефонии и видеоконференций. Его задача — упаковать аудио/видео в UDP-пакеты так, чтобы их можно было воспроизвести с правильным таймингом.
Ключевые особенности:
Работает в паре с RTCP (контрольный протокол) — передаёт статистику, потери, jitter.
Добавляет timestamp и sequence number, чтобы ресивер мог:
восстановить порядок пакетов;
компенсировать сетевые задержки и дрожание.
Обычно идёт поверх UDP, иногда поверх других транспортов (например, SRTP — шифрованный RTP).
Где живёт RTP:
IP-телефония, SIP-звонки.
Видеоконференции, WebRTC (там поверх SRTP).
Потоки от IP-камер (в том числе внутри RTSP-сессий).
Профессиональные системы вещания и мониторинга.
Важно: RTP сам по себе не говорит, где взять поток и как его включать/пауить — он просто мешки с пакетами таскает.
RTSP: «пульт управления» для медиасервера
RTSP (Real-Time Streaming Protocol) — это протокол управления, придуманный примерно в то же время (RealNetworks, Netscape, Columbia University, RFC 2326). Он выглядит похоже на HTTP, но вместо «дай страницу» там команды уровня пульта:
DESCRIBE – дай описание медиа (SDP).
SETUP – настроить транспорт (куда и как слать RTP).
PLAY – начать воспроизведение.
PAUSE – пауза.
TEARDOWN – завершить сессию.
Типичный сценарий:
Клиент по TCP стучится на сервер rtsp://camera/stream.
Получает SDP с описанием потоков (кодеки, порты, параметры RTP).
Командой SETUP договаривается о транспорте (UDP/ TCP, порты).
Командой PLAY запускает RTP-потоки с видео/аудио.
Управляет сессией командами RTSP.
Важно: RTSP почти никогда не передаёт само видео. Видео идёт через RTP, иногда через RTP поверх TCP (интерливинг), если UDP режется фаерволами.
Почему RTSP так любят в видеонаблюдении:
Улучшенный контроль: можно легко переключать каналы, делать паузу, склейку, трюк-режимы.
Поддержка множества кодеков и транспортов.
Стал де-факто стандартом для IP-камер: почти у каждой есть RTSP-URL вида
rtsp://user:pass@ip:554/Streaming/Channels/101.
RTMP: наследие эпохи Flash, которое до сих пор живёт на входе
RTMP (Real-Time Messaging Protocol) придумала Macromedia (потом Adobe) для стриминга в Flash-плеер. Протокол бинарный, поверх TCP, с постоянным соединением. Массово использовался для:
онлайн-стриминга (игры, вебинары, телевидение через браузер);
чатов/видеоконференций внутри Flash-решений.
Характеристики RTMP:
TCP, порт 1935 по умолчанию.
Низкая задержка (по меркам веба 2000-х).
В одном соединении мультиплексируются аудио, видео и служебные сообщения.
Исторически — самый популярный протокол приёма на медиа-серверы.
После смерти Flash браузеры перестали напрямую играть RTMP, но протокол не умер:
Его используют как ингест-протокол от OBS/энкодера до сервера.
Сервер уже сам раздаёт поток зрителям в HLS, DASH, WebRTC и т.д.
ONVIF: это вообще не «протокол видео», а набор стандартов для IP-камер
ONVIF (Open Network Video Interface Forum) — это организация и набор спецификаций для совместимости устройств видеонаблюдения (камеры, видеорегистраторы, VMS).
ONVIF решает другие задачи:
Обнаружение устройств (discovery).
Получение списка потоков и их параметров.
Настройка кодеков, разрешения, fps.
Управление PTZ, событиями, I/O.
Авторизация и безопасность.
Технически это:
SOAP/HTTP-web-сервисы;
WS-Discovery для поиска в сети;
несколько «профилей» (S, G, T и т.д.), описывающих минимальный набор функций.
Что важно понять: ONVIF почти всегда использует RTSP/RTP как транспорт видео. То есть:
Через ONVIF вы находите камеру, спрашиваете у неё медиапрофили.
Получаете от неё RTSP-URL.
Дальше уже RTSP+RTP занимаются доставкой медиапотока.
Почему столько разных протоколов?
Короткий ответ: потому что задачи разные, интернет менялся, а назад совместимость никто не отменял.
Чуть подробнее:
Разные эпохи и экосистемы.
RTP/RTSP — дети эпохи VoIP и первых медиа-серверов. RTMP — ребёнок Flash и «богатого веба» нулевых. ONVIF — реакция CCTV-рынка на зоопарк проприетарных API.
Разные требования к задержке.
Видеонаблюдение и конференции: нужны доли секунд → RTP/RTSP, WebRTC.
Онлайн-кинотеатры: терпим 5–30 секунд, но хотим стабильность и адаптивный битрейт → HLS/DASH.
Магистральные фиды и студийные линейки: важна надёжность → SRT, RIST, MPEG-TS over UDP.
Разные проблемы с сетью.
UDP хорошо для реального времени, но его не любят фаерволы и NAT.
TCP проще протащить через всё что угодно (порты 80/443), но хуже для ультра-низкой задержки.
Поэтому в реальных системах чаще не «выбрать один», а комбинировать:
камера → RTSP/RTP → медиа-сервер → HLS/WebRTC → браузеры/мобильные клиенты, а конфигурация камеры при этом идёт по ONVIF.
Какие ещё протоколы используются для передачи видео через интернет
Список далеко не полный, но основные игроки такие.
HTTP-адаптивные протоколы
HLS (HTTP Live Streaming) – формат от Apple. Видео режется на сегменты (обычно 2–6 секунд), лежит на HTTP-сервере. Клиент скачивает плейлист .m3u8, подбирает нужный битрейт. Плюсы: простота, поддержка браузерами, легко раздавать через CDN. Минус – задержка.
MPEG-DASH – стандартный аналог HLS от MPEG. Схема похожая: сегменты, манифест, адаптивный выбор качества.
Они идеально подходят для видео-по-запросу и масс-доставки трансляций миллионам зрителей, но не для управления камерой в реальном времени.
WebRTC
WebRTC — это целая платформа для двусторонних медиа-соединений с минимальной задержкой, ориентированная на браузеры.
Использует SRTP поверх UDP, DTLS для шифрования, ICE/STUN/TURN для обхода NAT.
Нормально работает прямо в браузере без плагинов.
Идеален для видеозвонков, удалённого рабочего стола, low-latency превью с камер.
Многие современные VMS/стриминг-сервисы делают так: ingest по RTSP/RTMP → трансляция в браузер по WebRTC.
SRT и RIST
SRT (Secure Reliable Transport) — протокол с открытым исходным кодом от Haivision.
Заточен под «грязный» интернет: добавляет ARQ-повторы, джиттер-буфер.
Шифрует трафик.
Используется для доставки профессиональных фидов между площадками, студиями, дата-центрами.
RIST (Reliable Internet Stream Transport) — похожая по идеологии инициатива от Video Services Forum.
Цель та же: сделать надёжный IP-транспорт для вещания поверх непредсказуемых сетей.
MPEG-TS over UDP / RTP
Классика IPTV:
Видео и аудио мультиплексируются в MPEG-TS, который идёт:
либо в UDP-мультикасте по локальной сети;
либо в RTP-потоках.
Очень устойчив в управляемых сетях провайдеров, хорошо ложится в существующую телеком-инфраструктуру.
Проприетарные решения
Камеры любят приносить с собой:
собственные облачные протоколы поверх HTTPS/WebSocket;
P2P-схемы с пробросом через relay-серверы;
закрытые API для мобилок.
Они редко документируются, но активно используются в потребительских устройствах.
Итог
RTP – «голый» транспорт для аудио/видео в реальном времени.
RTSP – «сетевой пульт управления» потоком, который обычно запускает RTP.
RTMP – наследие Flash, до сих пор популярный протокол доставки потока от энкодера до сервера.
ONVIF – не протокол передачи видео, а стандарт взаимодействия устройств видеонаблюдения, который использует RTSP/RTP как один из инструментов.
Разнообразие протоколов – не ошибка, а отражение реальных компромиссов: где-то важнее миллионы зрителей через CDN, где-то — половина секунды задержки в диспетчерской, а где-то — совместимость с десятилетними камерами на объекте. Поэтому и в ближайшие годы нас ждёт не «один протокол, чтобы править всеми», а аккуратные гибридные схемы, в которых каждый элемент стека делает своё дело на своём уровне.