Russian
Видеонаблюдение

RTP, RTSP, RTMP и ONVIF: в чём разница протоколов и какой выбрать для видеонаблюдения и стриминга

2025-11-25 13:00 VMS программы В фокусе Новости видеонаблюдения
Что такое ONVIF и rtsp
Потоковое видео давно перестало быть «фокусом для избранных». Камеры на заводе, 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 – завершить сессию.
Типичный сценарий:
  1. Клиент по TCP стучится на сервер rtsp://camera/stream.
  2. Получает SDP с описанием потоков (кодеки, порты, параметры RTP).
  3. Командой SETUP договаривается о транспорте (UDP/ TCP, порты).
  4. Командой PLAY запускает RTP-потоки с видео/аудио.
  5. Управляет сессией командами 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), но хуже для ультра-низкой задержки.
  • HTTP-базированные протоколы (HLS/DASH) отлично кэшируются CDN.
Разные уровни стека.
  • RTP — транспорт медиапакетов.
  • RTSP/RTMP — управление сессией и доставка.
  • ONVIF — уровень устройств и управления.
Поэтому в реальных системах чаще не «выбрать один», а комбинировать:
камера → 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, где-то — половина секунды задержки в диспетчерской, а где-то — совместимость с десятилетними камерами на объекте. Поэтому и в ближайшие годы нас ждёт не «один протокол, чтобы править всеми», а аккуратные гибридные схемы, в которых каждый элемент стека делает своё дело на своём уровне.