Содержание статьи +
Кратко (TL;DR)
Видео камеры попадает в записывающую программу за четыре шага, которые всегда идут в одном порядке: программа находит камеру (обнаружение), спрашивает, что у неё есть (описание), договаривается, как передавать (настройка), и даёт команду «старт» (play) – после чего камера отдаёт сжатое видео, которое программа пишет на диск. Стандарт, позволяющий программам и камерам разных производителей пройти эти шаги, – это ONVIF; протокол, который ведёт сам диалог, – RTSP, «пульт» поверх транспорта видео RTP; а по сети идут не картинки, а сжатый битстрим, почти всегда H.265 или H.264. Самый важный факт для бюджета: программа хранит поток камеры как есть, не пережимая его, поэтому ваш счёт за хранение задают кодек и битрейт на камере, а не сама программа. Эта статья проходит весь путь простым языком, показывает расчёт трафика и хранения для одной камеры и называет четыре ошибки, из-за которых возникает большинство заявок «камера не подключается».
Почему это важно
Если вы выбираете или проектируете систему видеонаблюдения, фраза «камера подключается к программе» звучит как деталь, которую можно оставить монтажнику, – пока треть камер не откажется появляться, поток, работавший на столе, не начнёт рассыпаться на сети объекта, а хранилище не заполнится на три недели раньше срока. Каждый из этих сбоев восходит к конкретному шагу пути: обнаружение, не проходящее за подсеть; выбор транспорта, который блокирует firewall; или настройка кодека, которую никто не проверил. Понимание четырёх шагов позволяет задать вендору правильные вопросы, читать даташит камеры без догадок и заранее оценивать трафик и хранение, которые проект реально потребит. Писать код не нужно – нужна модель в голове, и эта статья её даёт.
Весь путь на одной картинке
Перед четырьмя шагами – одно определение, на котором держится всё остальное. VMS (Video Management System) – программа, которая принимает, записывает и показывает множество потоков камер сразу, – это приёмная сторона всего описанного здесь. (Если VMS, NVR и DVR всё ещё сливаются, их различает наш разбор VMS, NVR и DVR, а анатомия системы видеонаблюдения показывает, где приём (ingest) стоит в общей машине.) Официальное определение ONVIF – удобный якорь: устройство Profile S, например IP-камера, «может передавать видеоданные по IP-сети», а клиент Profile S – и ONVIF прямо называет пример – это «video management software», которая может «настраивать, запрашивать и контролировать передачу видео» с устройства (ONVIF, Profile S). Эта фраза и есть путь приёма: настроить, запросить, контролировать, принять.
Вот путь от начала до конца. Каждый переход управляется именованным стандартом – именно это позволяет камере одного производителя работать с программой другого.
Четыре шага в одно дыхание: найти камеру, описать, что она предлагает, настроить, как она будет передаваться, и дать старт. Затем VMS тихо собирает и хранит результат. Разберём их по очереди.
Шаг 1 – Обнаружение: VMS находит камеру
Прежде чем что-то начнёт передаваться, программа должна узнать, что камера существует и где её искать. Это происходит двумя способами, и серьёзные внедрения используют оба.
Автоматический способ – протокол обнаружения, общий способ для устройств объявлять о себе и находить друг друга в локальной сети. ONVIF, отраслевой стандарт, позволяющий камерам и записывающим программам разных производителей понимать друг друга, использует для этого открытый протокол WS-Discovery (представьте, что камера кричит в комнату «я здесь, вот мой адрес», а VMS откликается «есть кто?»). Конкретно устройства общаются по одному известному каналу: UDP-порт 3702, на multicast-адрес 239.255.255.250 – одно сообщение, которое слышат сразу все устройства сегмента (OASIS, WS-Discovery 1.1). Камера, входящая в сеть, шлёт Hello; VMS, ищущая камеры, шлёт Probe; каждая подходящая камера отвечает ProbeMatch, который несёт главное, что нужно VMS дальше, – сервисный адрес (XAddrs), где пойдёт настоящий диалог (ONVIF; Hanwha Vision).
Эта граница и есть подвох – источник самой частой неожиданности крупных внедрений. Multicast-обнаружение локально для сегмента: оно доходит до устройств в том же сегменте сети, но не через маршрутизаторы или VLAN, если сеть специально не настроена это ретранслировать. Обнаружение, находящее все камеры на плоском тестовом стенде, может не найти ни одной, как только камеры окажутся в отдельном VLAN камер – а это обычная практика. Это не значит, что ONVIF сломан; это значит, что камеры надо добавлять вторым способом: вручную, по IP-адресу или сканированием диапазона IP. На это опирается любой парк камер крупнее десятка, плюс шаг с учётными данными – обнаружение находит устройство, но VMS всё равно нужны логин и пароль, а камера с заводским паролем по умолчанию – это задокументированная дыра в безопасности, а не удобство. Операционная реальность подключения сотен камер – отдельная тема, разобранная в статье обнаружение и подключение камер в масштабе.
Шаг 2 – Описание: камера сообщает, что у неё есть
Как только у VMS есть адрес камеры, начинается настоящий управляющий диалог, и ведётся он на RTSP – Real-Time Streaming Protocol, описанном стандартом интернета IETF RFC 2326 (и обновлённом как RTSP 2.0 в RFC 7826, хотя большинство камер всё ещё говорят на исходной версии). Описание из самого стандарта – лучшая аналогия: RTSP «действует как сетевой пульт для мультимедийных серверов» (IETF RFC 2326). Он не несёт само видео; он несёт кнопки – описать, настроить, старт, стоп – а видео едет отдельным транспортом. RTSP слушает на известной двери, TCP-порту 554.
Первая кнопка – DESCRIBE. VMS просит камеру описать, что та предлагает, и камера отвечает небольшим текстовым документом – блоком SDP (Session Description Protocol), – где перечислены доступные медиа: сколько потоков и, что важнее всего, какой кодек у каждого (например, видео H.265 плюс аудиодорожка). Это момент, когда VMS узнаёт, что сейчас получит битстрим H.265, а не сырые пиксели. Описание – первый ход рукопожатия: теперь VMS знает, что предлагается, и может решить, как это забрать.
Практическая деталь, которую стоит знать, потому что она меняет расчёт декодирования и трафика: большинство камер объявляют в этом описании более одного потока. Поток высокого разрешения, main stream, предназначен для записи; низкого разрешения, sub-stream, – для живого просмотра и аналитики. Тянуть полноразмерный main stream на стену из 30 камер, где каждая плитка размером с почтовую марку, – пустая трата декодирования и трафика на детали, которых никто не увидит; использовать для живого просмотра sub-stream – та схема, под которую камера и сделана.
Шаг 3 – Настройка: договариваемся, как поедет видео
Зная, что предлагает камера, VMS теперь согласует, как оно придёт, кнопкой SETUP – по разу на каждый нужный поток. Здесь одно решение важнее всех остальных в статье, потому что оно определяет, переживёт ли поток сеть объекта: UDP или TCP.
Видео несёт RTP (Real-Time Transport Protocol) – стандарт IETF RFC 3550 для передачи живого аудио и видео, помечающий каждый пакет порядковым номером и временной меткой, чтобы получатель мог переупорядочить и заново синхронизировать пришедшее. Рядом идёт RTCP – тонкий управляющий канал из того же стандарта, докладывающий о качестве доставки (потери, джиттер) в обе стороны. RTP может ехать двумя способами, и шаг SETUP выбирает один:
Первый – RTP поверх UDP, исторический вариант по умолчанию. UDP – доставка по принципу «отправил и забыл»: она быстрая и низколатентная, потому что никогда не ждёт подтверждений и не пересылает потерянный пакет. В хорошо управляемой локальной сети это именно то, что нужно. Но порты RTP и RTCP согласуются динамически, и у firewall или любой трансляции адресов (NAT) – подмены адресов между частной сетью и интернетом – нет статического правила, чтобы их пропустить. Через интернет UDP-RTP часто просто не доходит.
Второй – RTP внутри TCP-соединения RTSP (interleaved) – вариант, переживающий враждебные сети. Здесь камера упаковывает видео в то же TCP-соединение, что уже несёт управляющие сообщения RTSP, так что через firewall надо провести одно соединение, а TCP гарантирует, что каждый байт придёт по порядку. Стандарт задаёт кадрирование точно: каждый кусок потоковых данных «инкапсулируется символом доллара ASCII (24 в шестнадцатеричном виде), за которым следует однобайтовый идентификатор канала, а затем длина инкапсулированных бинарных данных в виде двухбайтового целого» (IETF RFC 2326, §10.12). Цена этой надёжности – задержка: TCP приостановит поток, чтобы переслать потерянный пакет, что добавит задержку или короткое замирание вместо краткого визуального артефакта, который показал бы UDP.
| Транспорт | Как едет | Задержка | Firewall / NAT | При потере | Когда применять |
|---|---|---|---|---|---|
| RTP поверх UDP | Отдельные динамические порты RTP + RTCP | Минимальная | Часто блокируется; динамические порты | Теряет пакеты – краткий артефакт | Управляемые локальные сети (LAN) |
| RTP внутри TCP (interleaved) | Внутри одного соединения RTSP (порт 554) | Чуть выше | Проходит – одно соединение | Дослыка – задержка или замирание | Интернет, firewall, каналы с NAT |
Таблица 1. Выбор транспорта на шаге SETUP. В чистой LAN UDP даёт минимальную задержку; через интернет или firewall безопасный выбор – TCP interleaved, потому что ему нужно лишь одно соединение, уже открытое для RTSP.
Шаг 4 – Старт, затем хранение
Согласовав транспорт, VMS нажимает последнюю кнопку, PLAY, и камера начинает отдавать видео. Словами стандарта, «запрос PLAY устанавливает обычное время воспроизведения в начало заданного диапазона и доставляет потоковые данные» (IETF RFC 2326). Пакеты RTP теперь непрерывно идут от камеры к VMS; отчёты RTCP едут рядом; а TEARDOWN в конце аккуратно закрывает сессию.
Теперь часть, которая определяет ваш бюджет хранения. Каждый приходящий пакет RTP несёт фрагмент сжатого видео, потому что один видеокадр обычно слишком велик для одного пакета. VMS выполняет сборку пакетов (depacketization) – собирает эти фрагменты обратно в целые сжатые кадры – и затем демультиплексирование, разделяя видеодорожку и аудио. Что она делает дальше – факт, который чаще всего понимают неправильно: грамотная VMS пишет эти сжатые кадры прямо на диск, ровно так, как прислала камера, оборачивая их в файл-контейнер (часто fragmented MP4) без перекодирования. Это называется remux, а не транскодирование. Камера уже сделала дорогую работу сжатия; повторять её – впустую тратить мощность сервера и терять качество ни за что.
Следствие конкретно и стоит сказать дважды: битрейт, на который настроена камера, – это битрейт, который вы храните. VMS его не уменьшает. Значит, выбор кодека на камере – решение по хранению, которое вы принимаете до записи первого кадра. Сжатые кадры превращаются обратно в видимые пиксели – декодируются – только когда оператор реально смотрит эту камеру или её проверяет аналитика, поэтому сервер записи спокойно держит сотни камер, которые он не показывает.
Что на самом деле в канале: кодек
«Видео», идущее по сети, – это битстрим кодека, сильно сжатое описание сцены, а не последовательность изображений. В видеонаблюдении доминируют два кодека, оба – формальные международные стандарты. H.264, он же AVC (ITU-T H.264), больше десяти лет был рабочей лошадкой. H.265, он же HEVC (ITU-T H.265), – его преемник и на 2026 год default практически на каждой новой камере и регистраторе. Причина важна для денег: H.265 даёт то же качество картинки примерно при 40–50% меньшем битрейте, чем H.264 (CCTV Camera World; A1 Security Cameras). Меньше битрейт по сети и – поскольку VMS хранит поток как есть – пропорционально меньше диска.
Пройдём арифметику для одной камеры, потому что она делает мысль неоспоримой. Возьмём камеру 4 МП при 30 кадрах в секунду, непрерывная запись. В H.264 она в среднем около 6 Mbps; в H.265 – около 3 Mbps для той же сцены (CCTV Camera World). Хранение в сутки – это битрейт на число секунд в сутках, и удобный приём даёт тот же ответ: гигабайты в сутки ≈ Mbps × 10,8:
H.264: 6 Mbps × 10,8 ≈ 64,8 ГБ на камеру в сутки H.265: 3 Mbps × 10,8 ≈ 32,4 ГБ на камеру в сутки
За 30 дней хранения это примерно 1,9 ТБ против 1,0 ТБ для одной камеры – одна настройка кодека почти вдвое срезает счёт, а VMS её не трогала. Умножьте на объект из 40 камер – и разница в десятки терабайт. Некоторые камеры добавляют «умный кодек» (H.264+ / H.265+), который ещё снижает битрейт на статичных сценах и поднимает при движении, срезая средний битрейт ещё на 30–50% в спокойных видах (CCTV Camera World) – полезно, но зависит от сцены, так что считайте это бонусом, а не гарантией. Полную модель хранения, где частота кадров, разрешение и режим записи – другие рычаги, см. в статье как работает хранение видеонаблюдения: математика ретенции.
Одно замечание по охвату, чтобы статья оставалась в своей полосе: как именно H.265 достигает такого сжатия – предсказание, преобразования и патентная история – относится к разделу о кодировании, к статьям H.265 / HEVC и как выбрать кодек в 2026. Здесь важно одно: кодек на камере задаёт битрейт, который хранит VMS.
Частая ошибка, которой стоит избегать
Самый дорогой паттерн, который мы видим, – относиться к приёму как к plug-and-play и обнаруживать пробелы уже в продакшене, и у него четыре лица, каждое соответствует шагу выше. Первое: считать, что обнаружение ONVIF найдёт каждую камеру – оно не пройдёт за VLAN камер, так что парку нужна продуманная заранее схема подключения по диапазону IP. Второе: оставлять поток на UDP через firewall или интернет – он подключается на стенде и падает на объекте; переключайте на TCP interleaved для любого канала через firewall или NAT. Третье: считать, что VMS сожмёт видео – она хранит то, что прислала камера, так что завышенный битрейт main stream превращается в завышенный счёт за хранение, который никто не выбирал. Четвёртое: писать main stream там, где место sub-stream, – подавать на стену из множества камер полноразмерные потоки и плавить бюджет декодирования ради деталей, которых никто не видит. Ни одно из этого не экзотика; все четыре предсказуемы, и все четыре дешевле спроектировать заранее, чем отлаживать потом.
Где здесь Фора Софт
Фора Софт строит ПО реального времени для видео, стриминга и компьютерного зрения с 2005 года, на счету 250+ сданных проектов, и слой приёма – это место, где продукты видеонаблюдения тихо удаются или проваливаются под нагрузкой. Сложность – никогда не в одной камере на стенде; она в нескольких сотнях камер от разных производителей, часть из которых идеально соответствует ONVIF, а часть требует обойти вендорскую особенность, и все они должны надёжно подниматься, переподключаться после провала сети и писать на том битрейте, что заложен в план хранения. Мы строим этот слой приёма – мультивендорное обнаружение и подключение, забор по RTSP/RTP с чистым переходом с UDP на TCP и запись «как прислано», которая никогда не пережимает молча, – и ведём разговор с того, как система ведёт себя в худший сетевой день, а уже потом про список функций. Конвейер приёма, переживающий шторм пакетов, лучше того, что красиво выглядит в демо на тихой LAN.
Главное
- Приём – четыре шага по порядку: найти, описать, настроить, дать старт, затем хранить.
- ONVIF (поверх WS-Discovery, UDP 3702) даёт VMS автоматически находить мультивендорные камеры.
- RTSP (порт 554) – это пульт; RTP/RTCP несут само видео.
- Через firewall и NAT выбирайте RTP по TCP (interleaved); UDP – только в чистой LAN.
- VMS хранит поток камеры как есть – кодек камеры задаёт ваше хранение.
- H.265 нужно на ~40–50% меньше битрейта, чем H.264, при том же качестве.