ONVIF vs RTSP vs RTP: как движется видео наблюдения

Кратко (TL;DR)

Видео камеры наблюдения везут три разных протокола, и путаница между ними – причина большинства заявок «камера не подключается»: ONVIF находит камеру и согласует поток, RTSP – это пульт, который поток запускает и останавливает, а RTP – грузовик, который реально везёт сжатое видео, и рядом с ним едет тонкий спутник RTCP, который отчитывается о качестве доставки. RTSP (Real-Time Streaming Protocol, IETF RFC 2326) знает несколько команд – DESCRIBE, SETUP, PLAY, TEARDOWN – и работает по TCP-порту 554; RTP (IETF RFC 3550) оборачивает каждый кусок видео в 12-байтный заголовок с порядковым номером, временной меткой и идентификатором источника, чтобы получатель восстановил порядок пакетов и держал видео со звуком в синхро. Одно решение определяет, переживёт ли поток сеть здания, – как именно поедет RTP: напрямую по UDP (минимальная задержка, но блокируется firewall), внутри RTSP/TCP-соединения (interleaved) или в туннеле RTSP-over-HTTP для враждебных сетей. Эта статья разбирает каждый протокол, показывает, что лежит внутри RTP-пакета, объясняет, как один кадр превращается в десятки пакетов, и приводит расчёт полосы для одной камеры.

Почему это важно

Если вы проектируете или эксплуатируете систему наблюдения, «ONVIF или RTSP» звучит как выбор, который надо сделать, – и это не так: это разные задачи, идущие вместе, и ошибка здесь – корень удивительно большого числа сбоев. Поток, который идеально играет на столе, может зависать или пропадать, как только пересекает firewall, маршрутизатор или VPN, и причина почти всегда – решение по транспорту, которое никто не принимал осознанно. Понимание четырёх протоколов – что каждый делает, чего не может и где ломается – позволяет читать спеку камеры без догадок, задавать вендору правильные вопросы и предсказывать полосу и задержку, которые система реально выдаст. Вы не напишете ни строки сетевого кода; вы получите ту модель в голове, которая отличает систему, переживающую плохой день сети, от той, что лишь красиво показывается на демо. Это слой под обзором подключения камеры – сама сеть, в деталях.

ONVIF, RTSP и RTP: кто что делает

Начнём с вопроса, который задаёт почти каждый покупатель: «добавлять камеру по ONVIF или по RTSP?» Честный ответ: эти двое – не конкуренты, а разные этапы одного разговора, и обычная система использует оба сразу. Путать их – всё равно что спрашивать, связаться с коллегой «по телефону или разговором»: одно – это соединение, другое – то, что по нему идёт.

Видео камеры в записывающий софт переносят четыре именованные технологии, и у каждой ровно одна работа. Софт, который принимает и записывает множество потоков с камер, называется системой управления видео (Video Management System, VMS); ниже описано, как видео камеры до неё доходит.

ONVIF – это консьерж. ONVIF – стандарт Open Network Video Interface Forum – даёт камерам и софту от разных производителей понимать друг друга. Его задача здесь: найти камеру в сети и отдать адрес её видеопотока. ONVIF не везёт ни одного кадра видео. Когда вы «добавляете камеру по ONVIF», VMS через ONVIF обнаруживает устройство, авторизуется и спрашивает: «какой адрес у твоего потока?» – а камера отвечает RTSP-адресом. (Полный разбор ONVIF – в статье ONVIF для инженеров; коммерческий обзор – в гиде Фора Софт по профилям ONVIF в системах безопасности.)

RTSP – это пульт. Получив адрес потока, VMS подключается по Real-Time Streaming Protocol и нажимает кнопки: опиши себя, настрой поток, играй, стоп. RTSP везёт команды, а не картинки. Когда вы «добавляете камеру по RTSP», вы пропускаете консьержа ONVIF и вводите адрес потока вручную – поэтому RTSP-only работает, но теряет обнаружение, события и конфигурацию ONVIF.

RTP – это грузовик. Real-Time Transport Protocol – то, что реально везёт сжатое видео по сети, по пакету за раз. Всё, что вы видите на экране, приехало как RTP.

RTCP – это блокнот доставки. RTP Control Protocol едет рядом с RTP, не везёт видео – лишь короткие отчёты в обе стороны о том, как идёт доставка: сколько пакетов дошло, сколько потеряно, насколько «дёрганым» был тайминг.

Таблица 1. Разделение труда. «ONVIF или RTSP» – ложный выбор: ONVIF устанавливает вызов, RTSP им управляет, RTP его везёт. Видео двигает только RTP.

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

RTSP: пульт управления

RTSP лучше всего понять словами самого стандарта: RTSP «действует как „сетевой пульт“ для мультимедийных серверов» (IETF RFC 2326, §1.1). Он не двигает видео; он нажимает кнопки на камере, а камера отвечает. Он слушает на известной двери – TCP-порту 554 (RFC 2326, §3.2).

Кнопок – короткий именованный набор. Четыре обязательны для любой RTSP-системы – OPTIONS, SETUP, PLAY и TEARDOWN – и ещё две в почти повсеместном ходу: DESCRIBE и PAUSE (RFC 2326, §10). Пройдём последовательность так, как делает её VMS. OPTIONS спрашивает, какие команды поддерживает камера. DESCRIBE просит камеру описать, что у неё есть, и камера отвечает небольшим текстовым документом – блоком Session Description Protocol (SDP), – где перечислены доступные потоки и, что важно, кодек каждого из них. SETUP согласует, как поедет видео (решение по транспорту – ниже). PLAY запускает поток. TEARDOWN аккуратно закрывает сессию.

Одно свойство RTSP сбивает с толку инженеров, ждущих от него поведения веб-запроса: RTSP с состоянием (stateful). Обычная веб-страница – без состояния: каждый запрос сам по себе. RTSP – наоборот: «RTSP-серверу почти во всех случаях по умолчанию нужно хранить состояние, в отличие от безсессионной природы HTTP» (RFC 2326, §1.1). Камера помнит между командами, что настроила сессию и сейчас её играет; она ведёт каждую сессию через состояния, которые стандарт называет INIT, READY и PLAYING. Эта память – причина, почему полузакрытая RTSP-сессия может оставить камеру с занятыми ресурсами и почему хорошая VMS всегда шлёт TEARDOWN, а не просто рвёт соединение.

Современная заметка о версиях: RTSP 2.0 вышел как IETF RFC 7826 в декабре 2016 года и формально замещает RFC 2326 (1998). На практике подавляющее большинство камер в поле всё ещё говорит на RTSP 1.0, поэтому VMS, принимающая реальное железо, строится прежде всего под RFC 2326, а 2.0 считает исключением. Внутренности протокола – полная грамматика, поведение прокси, стык с общей стриминговой инфраструктурой – относятся к стриминговой дисциплине; наш раздел про видеостриминг разбирает теорию транспорта вглубь, а эта статья держит рамку наблюдения.

RTP: что на самом деле внутри грузовика

Когда PLAY запускает поток, видео идёт по сети чередой RTP-пакетов. RTP определён в IETF RFC 3550, это Internet Standard, и полезно понять, что каждый пакет несёт помимо самого видео, – ведь именно эти несколько лишних байт позволяют живому видео пережить неидеальную сеть.

Каждый RTP-пакет начинается с фиксированного 12-байтного заголовка (RFC 3550, §5.1). Бо́льшая часть его – учётные поля, но три делают основную работу, и каждое прямо отображается на реальную задачу наблюдения.

Sequence number (порядковый номер) – это 16-битный счётчик, который «увеличивается на единицу с каждым отправленным RTP-пакетом и может использоваться получателем для обнаружения потери пакетов и восстановления их порядка» (RFC 3550, §5.1). Так VMS узнаёт, что пакет пропал (разрыв в счёте), и так она пересобирает пакеты, пришедшие не по порядку, – оба события рутинны в нагруженной сети.

Timestamp (временная метка) – 32-битное поле, которое «отражает момент дискретизации первого октета в RTP-пакете» (RFC 3550, §5.1). Это часы, которые держат движение плавным, а звук – выровненным с видео. Без неё кадры играли бы со скоростью прихода, а не со скоростью съёмки.

SSRC (synchronization source) – 32-битный случайный идентификатор источника потока. У камеры, шлющей видео и звук, у каждого свой SSRC, так что VMS различает их даже на одном соединении.

Четвёртое поле, payload type, называет формат внутри – например, какой кодек представляют байты, – чтобы получатель знал, держит он H.265 или H.264.

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

Как один кадр становится десятками пакетов

Вот часть, которую вендорские объяснялки пропускают, и она объясняет целый класс реальных багов. Один кадр видео – особенно ключевой кадр, полную картинку, которую кодек шлёт периодически, – слишком велик для одного сетевого пакета. Обычная сеть Ethernet переносит пакеты примерно по 1 500 байт за раз (Maximum Transmission Unit, MTU); после заголовков IP и UDP на полезную нагрузку остаётся около 1 400 байт. Сжатый ключевой кадр с 4-мегапиксельной камеры может весить десятки килобайт. Видео приходится резать.

Правила нарезки живут в формате RTP-полезной нагрузки для каждого кодека: RFC 7798 для H.265/HEVC (март 2016) и RFC 6184 для H.264 (май 2011). Оба определяют одни и те же три структуры под разными именами. Single NAL unit packet везёт один небольшой самодостаточный кусок видео отдельно. Aggregation Packet (AP) упаковывает несколько мелких кусков в один пакет, чтобы сеть не тратилась на крошечные нагрузки. Fragmentation Unit (FU) делает обратное: разбивает один большой кусок на много пакетов – так едет большой ключевой кадр.

Сделаем конкретно. Пусть ключевой кадр сжался примерно до 80 КБ. При ~1 400 байт полезной нагрузки на пакет один этот кадр превращается примерно в 80 000 ÷ 1 400 ≈ 58 RTP-пакетов, каждый помечен следующим порядковым номером, и все несут одну временную метку, потому что принадлежат одному кадру. VMS собирает все 58, проверяет порядковые номера на разрывы, пересобирает их в целый ключевой кадр – и только тогда его можно декодировать. Если хотя бы один из этих 58 пакетов потерян на UDP-транспорте, весь ключевой кадр может стать непригодным – это и есть техническая причина, почему короткая заминка в сети выглядит как несколько секунд «размазанного» или замороженного видео, а не как один потерянный пиксель.

RTCP: обратный канал качества, о котором все забывают

Рядом с RTP-видео тихо едет его управляющий спутник – RTCP, тоже определённый в RFC 3550. Он не везёт видео. Его задача – обратная связь: периодически отправитель и получатель обмениваются короткими отчётами. Камера шлёт Sender Report (RTCP-пакет типа 200) – что она передала, плюс временную метку, по которой VMS выравнивает звук с видео; VMS отвечает Receiver Report (тип 201) – что она приняла: долю потерянных пакетов, накопленные потери и джиттер (разброс времени прихода пакетов). RFC 3550 определяет всего пять типов отчётов (Sender Report, Receiver Report, Source Description, BYE и APP).

Этот обратный канал – то, как система наблюдения узнаёт, что поток деградирует, раньше, чем оператор заметит замороженную плитку. Числа потерь и джиттера из RTCP – сырьё для дашбордов здоровья, которые показывает серьёзная VMS: «камера 47 теряет 4% пакетов» – это факт из RTCP.

RTCP намеренно экономен, чтобы его отчёты никогда не теснили видео. Стандарт прямо говорит: «РЕКОМЕНДУЕТСЯ, чтобы доля полосы сессии, добавляемая под RTCP, была зафиксирована на 5%» (RFC 3550, §6.2), причём так, что отправители используют около четверти этого, а получатели – три четверти. Чтобы избежать шторма отчётов в большой системе, стандарт задаёт и пол по частоте отчётов: «РЕКОМЕНДУЕМОЕ значение фиксированного минимального интервала – 5 секунд» (RFC 3550, §6.2). Для парка наблюдения это важно: накладные RTCP остаются около 5% полосы медиа, сколько бы камер вы ни добавили, – так что в планировании ёмкости это погрешность округления, но та самая, что говорит вам, что система здорова.

Решение, определяющее поток: UDP, TCP или HTTP

Всё выше зафиксировано стандартами. Единственный настоящий выбор вы делаете на SETUP: как поедет RTP. Это самое весомое сетевое решение в проекте наблюдения, потому что оно определяет, пересечёт ли поток сеть вообще.

Первый вариант – RTP по UDP, исторический умолчательный. UDP работает по принципу «выстрелил и забыл»: он никогда не ждёт подтверждений и не пересылает потерянный пакет, что даёт минимальную задержку. В чистой управляемой локальной сети это ровно то, что нужно. Но UDP-RTP использует пару динамически согласованных портов, а у firewall или любого Network Address Translation (NAT) – разделения адресов между частной сетью и интернетом – нет фиксированного правила, чтобы их пропустить. Через интернет UDP-RTP часто просто не доходит.

Второй вариант – RTP, вложенный (interleaved) в RTSP/TCP-соединение. Здесь видео упаковывается в то же TCP-соединение, что уже несёт команды RTSP на порту 554, так что firewall нужно пропустить лишь одно соединение, а TCP гарантирует доставку всех байт по порядку. RFC 2326 точно определяет обрамление: данные потока «инкапсулируются ASCII-знаком доллара (24 в шестнадцатеричном виде), за которым идёт однобайтовый идентификатор канала, а затем длина инкапсулированных двоичных данных в виде двухбайтового целого» (RFC 2326, §10.12). Цена надёжности – задержка: при потере пакета TCP останавливает всё, чтобы переслать его, – head-of-line blocking, – что может превратить короткую заминку в недолгую заморозку.

Третий вариант, частый в наблюдении и пропускаемый большинством объяснялок, – RTP/RTSP в туннеле поверх HTTP(S). Весь обмен RTSP/RTP заворачивается в обычный веб-трафик на порту 80 или 443. Спецификация стриминга самого ONVIF перечисляет это среди транспортов именно потому, что так проходят строгие корпоративные прокси и firewall, которые блокируют всё остальное, – ценой наибольших накладных. ONVIF, по сути, строит всё это на тех же протоколах IETF: его спека стриминга описывает «набор опций медиапотока… все на базе RTP», где «управление медиа осуществляется по RTSP», и перечисляет RTP/UDP, RTP/RTSP/TCP и RTP/RTSP/HTTP/TCP как транспорты (ONVIF Streaming Specification).

Таблица 2. Выбор транспорта на SETUP. Спускайтесь по таблице по мере того, как сеть враждебнее: UDP в чистой LAN, TCP interleaved через firewall, HTTP-туннель через строгий прокси. Многие VMS пробуют UDP первым и откатываются автоматически.

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

Сетевая глубина за этим выбором – почему UDP и TCP ведут себя так и как на самом деле работает обход NAT – это территория стримингового транспорта, разобранная в статьях TCP и UDP в стриминге и NAT, STUN, TURN и ICE. Здесь достаточно правила: чем чище сеть, тем выше по Таблице 2 можно остаться.

Что одна камера реально кладёт в сеть

Свяжем всё арифметикой для одной камеры – числа делают абстракции конкретными. Возьмём 4-мегапиксельную камеру, пишущую непрерывно в H.265 со средними 3 Мбит/с (примерно вдвое меньше, чем той же камере нужно в H.264). Счёт идёт в три коротких шага.

Сначала переведём битрейт в байты в секунду:

3 Мбит/с ÷ 8 = 0,375 мегабайта в секунду = 375 000 байт/с

Затем переведём байты в пакеты, по ~1 400 байт полезной нагрузки каждый:

375 000 ÷ 1 400 ≈ 268 RTP-пакетов в секунду

Наконец, добавим накладные RTCP, фиксированные около 5% от медиа:

3 Мбит/с × 5% ≈ 0,15 Мбит/с под RTCP – погрешность округления

Итак, одна обычная камера выдаёт порядка 268 видеопакетов каждую секунду, у каждого свой порядковый номер, плюс струйка RTCP-отчётов несколько раз в минуту. Умножьте на площадку из 40 камер – и VMS пересобирает порядка 10 000 пакетов в секунду в связные кадры, следя за каждым порядковым номером на предмет разрывов, – поэтому реальный тест платформы наблюдения – производительность приёма под нагрузкой, а не на столе. Сам битрейт – а с ним и счёт за хранение, ведь VMS пишет поток как есть, – задаётся кодеком на камере, тема статьи как работает хранение видеонаблюдения.

Частая ошибка, которой стоит избегать

Самый дорогой паттерн, который мы видим, – относиться к транспорту как к plug-and-play и обнаруживать дыры в продакшене, и у него четыре лица. Первое – оставить поток на UDP через firewall, NAT или интернет: на столе подключается, на объекте падает – переведите на TCP interleaved или HTTP-туннель для любого канала, пересекающего firewall. Второе – считать, что «ONVIF» заменяет RTSP: ONVIF лишь устанавливает вызов, а видео по-прежнему едет по RTSP/RTP, так что проблема ONVIF и проблема стриминга – разные проблемы с разными решениями. Третье – игнорировать RTCP: отчёты о потерях и джиттере – система раннего предупреждения, и VMS, которая их не показывает, летит вслепую. Четвёртое – считать, что потерянный пакет стоит один кадр: на UDP потеря одного фрагмента ключевого кадра может испортить секунды видео – поэтому враждебным сетям нужна надёжность TCP, несмотря на задержку. Ничего экзотического; все четыре предсказуемы, и все четыре дешевле заложить в проект, чем отлаживать после развёртывания.

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

Фора Софт строит софт для видео в реальном времени, стриминга и компьютерного зрения с 2005 года, на счету 250+ выпущенных проектов, и сеть – это место, где продукты наблюдения тихо побеждают или проваливаются под нагрузкой. Сложность – никогда не одна камера на чистом столе; это несколько сотен камер от разных производителей, часть образцово-совместимых, а часть путающих TEARDOWN или переставших слать RTCP, и все они должны стабильно стримить, переподключаться после провала сети и деградировать плавно, когда пакеты теряются. Мы строим этот слой – приём RTSP/RTP с автоматическим откатом UDP → TCP → HTTP, пересборку с учётом порядковых номеров и мониторинг здоровья на основе RTCP, который помечает деградирующую камеру раньше, чем оператор увидит замороженную плитку. Мы ведём с того, как конвейер ведёт себя в худший день сети – пакетный шторм, полуоткрытая сессия, – а потом уже список функций, потому что слой приёма, переживающий плохую сеть, лучше того, что красиво показывается в тихой LAN.

Главное

• ONVIF, RTSP, RTP и RTCP – разные задачи, идущие вместе, а не альтернативы.
• ONVIF находит камеру; RTSP управляет сессией; видео везёт только RTP.
• В заголовке RTP – sequence number (потери/порядок), timestamp (синхро), ID источника.
• Один ключевой кадр становится десятками RTP-пакетов; потеря одного портит секунды.
• RTCP шлёт потери и джиттер при ~5% накладных – система раннего предупреждения потока.
• Транспорт решает выживание: UDP в чистой LAN, TCP или HTTP через firewall.

Что почитать дальше

• Как поток камеры попадает в VMS: обнаружение, RTSP и кодеки
• ONVIF для инженеров
• TCP и UDP в стриминге