Как устроена система видеонаблюдения

Кратко

Современная система видеонаблюдения – это конвейер из семи стадий: камера снимает и сжимает изображение, сеть его несёт, видеоплатформа (VMS) принимает, хранилище удерживает, аналитика истолковывает, операторы смотрят, а слой интеграции превращает события в действия – и всё это обёрнуто слоем приватности и хранения. У каждой стадии есть типовая технология и типовой способ отказа, и большинство дорогих ошибок в видеонаблюдении – это одна неверно подобранная или недосчитанная стадия при исправной остальной системе. Самая недооценённая по бюджету стадия – хранилище, а это чистая арифметика: битрейт × камеры × часы × дни хранения; самая недопонятая – аналитика, где «край» (edge) и «облако» несут совершенно разные счета за задержку, трафик и приватность. Эта статья – карта, к которой возвращается весь курс: прочитайте её один раз, и вы сможете поставить любую тему видеонаблюдения на нужный шаг и задать о нём правильный вопрос.

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

Если вы планируете, покупаете или строите систему видеонаблюдения, вы на самом деле принимаете семь решений сразу, и они связаны: выбранная камера задаёт трафик, трафик задаёт сеть, сеть и срок хранения задают счёт за хранилище, а место аналитики меняет всё три. Считайте систему одной коробкой с надписью «камеры и софт» – и недостающую стадию вы найдёте дорогим путём: коммутатор, проседающий под нагрузкой, массив дисков, заполняющийся за три недели, аналитика, заваливающая операторов ложными тревогами, или распознавание лиц, выпущенное без нужной юридической проверки. Эта статья даёт точную модель всего конвейера простым языком, чтобы вы говорили с инженерами и поставщиками шаг за шагом, знали, какой вопрос относится к какому узлу, и замечали недоразмеренное звено до того, как оно откажет. Это фундамент, на котором стоит остальной курс, и каждая следующая статья приближает одну из этих стадий.

Вся система на одной странице

Вот весь конвейер, прежде чем мы пройдём его медленно. Видео начинается как свет, падающий на сенсор камеры, и заканчивается действием, которое предпринимает человек или другая система: оператор отправляет охрану, дверь остаётся запертой, тревога прилетает на телефон. Между этими двумя точками оно проходит семь стадий, а слой приватности и хранения управляет всеми сразу.

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

Чтобы читать карту, заметьте: видео становится меньше и осмысленнее, двигаясь вправо. У камеры это тяжёлый сырой поток; к стадии аналитики оно превращается в лёгкий кусок структурированной информации («человек пересёк эту линию в 14:02»); к стадии интеграции – в действие. Трафик и хранилище стоят дороже всего слева; интеллект и решения живут справа. Держите этот градиент в голове – и вся система обретает смысл.

Возьмём стадии по порядку: камера, сеть, приём, хранилище, аналитика, клиент, интеграция, а затем слой приватности, который их обёртывает.

Стадия 1 – Камера: съёмка и сжатие

Типовая технология: IP-камера с сенсором, объективом и бортовым кодером H.264 или H.265.

Всё начинается с камеры, и современная камера видеонаблюдения – это маленький сетевой компьютер, а не просто глаз. Она ловит свет на сенсор, а затем сразу кодирует изображение – сжимает сырые пиксели в управляемый цифровой поток видеокодеком, чаще всего H.264 или более эффективным H.265 (он же HEVC). Это сжатие – самое важное, что камера делает для остальной системы, потому что оно задаёт размер всего, что идёт дальше.

Насколько велико «сырое»? Несжатое видео высокой чёткости огромно – гигабиты в секунду, – поэтому никакая система видеонаблюдения не возит сырое видео. Кодек ужимает его в 100 раз и сильнее. Полезное правило 2026 года: камера 4 мегапикселя при 30 кадрах в секунду даёт примерно 6 мегабит в секунду (Mbps) в H.264 и около 3 Mbps в H.265 – вдвое меньше при той же картинке (CCTV Camera World; PVR). Этот единственный выбор кодека, сделанный на камере, докатывается до счёта за хранилище на Стадии 4.

Камеры так сильно различаются в цене, потому что различается задача. В отрасли говорят о DORI – Detection, Observation, Recognition, Identification (обнаружение, наблюдение, распознавание, идентификация) – четыре уровня того, сколько деталей нужно на заданной дистанции. Чтобы понять, что «человек там есть», нужно куда меньше пикселей на цель, чем чтобы прочитать лицо или номер. Выбор камеры под задачу на каждой точке, а не одна модель повсюду, – это разница между рабочей системой и записью бесполезного пятна. Слой камер мы разбираем в статье IP-камеры против аналоговых, а механику кодеков – в разделе Кодирование видео.

Типовой режим отказа: неверная камера под задачу – широкоугольную просят опознать лица за 30 метров – или камера с без нужды высоким битрейтом, тихо утраивающая стоимость хранения всей системы ещё до того, как записан первый кадр.

Стадия 2 – Сеть: как снять поток с камеры

Типовая технология: коммутатор с PoE (Power over Ethernet), структурированная кабельная сеть и обычно выделенный VLAN.

Сжатый поток камеры теперь должен ехать, и в современной IP-системе он едет по той же Ethernet-сети, что и в офисе. Изящная часть – PoE (Power over Ethernet): один кабель Cat5e или Cat6 несёт и данные видео, и электричество для камеры, так что отдельной розетки у каждой точки не нужно. Коммутатор, который это делает, – тихий хребет всей системы.

PoE стандартизован IEEE, и стандарт важен, потому что камеры потребляют по-разному. IEEE 802.3af (2003) выдаёт до 15,4 Вт с порта коммутатора (около 12,95 Вт доходит до камеры) – хватает простой фиксированной камере. IEEE 802.3at, или PoE+ (2009), поднимает планку до 30 Вт на порту, что покрывает камеры с подогревом, ИК-подсветкой или моторами PTZ (поворот-наклон-зум). IEEE 802.3bt, или PoE++ (2018), идёт дальше: Type 3 даёт около 51 Вт, а Type 4 около 71,3 Вт на устройство – для самых требовательных PTZ и мультисенсорных моделей (стандарты IEEE 802.3; FS.com). Урок: у коммутатора должен быть достаточный бюджет мощности на сумму всех камер, а не просто хватать портов.

Вторая работа сети – изоляция. Камеры видеонаблюдения – известно слабое место сети, поэтому их принято выносить в отдельный виртуальный сегмент (VLAN), чтобы скомпрометированная камера не дотянулась до остального бизнеса и чтобы постоянный поток видео не сталкивался с офисными данными. Бюджет здесь – это полоса пропускания, в Mbps на камеру и в сумме по системе.

Типовой режим отказа: недоразмеренный коммутатор – портов хватает, а суммарной мощности PoE нет, и камеры перезагружаются под нагрузкой – или слишком тонкий аплинк, не несущий все потоки разом, так что видео рвётся ровно тогда, когда инцидент заливает сеть.

Стадия 3 – Приём: как VMS находит и забирает поток

Типовая технология: ONVIF для обнаружения и настройки, RTSP и RTP для рукопожатия и транспорта потока.

Теперь входит софт. Видеоплатформе (VMS) – программе, которая записывает и управляет многими камерами сразу, – нужно сделать две вещи, прежде чем что-то записывать: найти камеру в сети и забрать её поток. Это работает между камерами разных производителей благодаря двум стандартам.

Первый – ONVIF (Open Network Video Interface Forum), отраслевой стандарт, созданный в 2008 году, чтобы камеры и софт разных вендоров понимали друг друга (onvif.org). Думайте об ONVIF как об общем языке на разгрузочной платформе: он позволяет VMS обнаружить новую камеру в сети, спросить, что она умеет, и настроить её без написанного вручную драйвера под эту модель. ONVIF организован в профили, каждый под свою функцию: Profile S – базовое видеопотоковое вещание, Profile T – расширенное вещание, включая H.265 и события вскрытия, Profile G – запись и извлечение на устройстве, Profile M – метаданные аналитики, что важно на Стадии 5 (onvif.org/profiles). Одно устройство может соответствовать сразу нескольким профилям.

Деталь, спасающая проекты: «соответствует ONVIF» гарантирует базу, а не каждую функцию. Камера и VMS, у которых общий Profile S, надёжно дадут поток; особая аналитика вендора или проприетарное управление часто всё равно требуют его собственного SDK. Считайте ONVIF полом, на котором стоят оба устройства, а не полным потолком возможностей камеры. Инженерные детали – в статье ONVIF для инженеров и в коммерческом обзоре профилей ONVIF в системах безопасности.

Когда камера найдена, само видео движут ещё два стандарта. RTSP (Real-Time Streaming Protocol, IETF RFC 7826) – это пульт: он несёт команды «play», «pause», «teardown», но не само видео. RTP (Real-Time Transport Protocol, IETF RFC 3550) – курьер, несущий собственно сжатые пакеты видео, обычно поверх UDP ради скорости (rfc-editor.org). Путь приёма простыми словами – обнаружение, рукопожатие RTSP, кодек на проводе – разобран в статье как поток камеры попадает в VMS, а глубина транспорта – в разделе Видеостриминг.

Типовой режим отказа: допущение «ONVIF просто работает» – команда покупает смешанный парк камер в расчёте, что все функции появятся в VMS, а потом находит лишь базовые потоки, тогда как премиальная аналитика, за которую заплачено, заперта за SDK вендора.

Стадия 4 – Хранилище: стадия, которую все недооценивают

Типовая технология: сервер записи, пишущий на диски для видеонаблюдения, часто в массиве RAID, с режимом записи, выбранным под каждую камеру.

Поток теперь приходит, и его надо куда-то писать – на дни, недели или месяцы. Хранилище – стадия, которая тихо доминирует в стоимости системы, и хорошая новость в том, что это чистая арифметика, так что вы можете рассчитать его ещё до покупки.

Формула: битрейт × число камер × часы записи × дни хранения. Пройдём сначала одну камеру. Камера, непрерывно вещающая на 4 Mbps, за один час даёт:

4 Мбит/с × 3 600 с = 14 400 мегабит = 1 800 мегабайт ≈ 1,8 ГБ в час.

За полные сутки это около 43 ГБ на камеру. Удобное сокращение, дающее тот же ответ: объём за сутки в ГБ ≈ битрейт в Mbps × 10,8 (то есть 4 × 10,8 = 43,2 ГБ/сутки). Теперь масштабируем до объекта на 40 камер, хранимого 30 дней с непрерывной записью:

43 ГБ × 40 камер × 30 дней ≈ 51 600 ГБ ≈ 51,6 ТБ.

Вот это число и удивляет заказчиков. И оно полно рычагов, каждым из которых вы управляете. Переведите камеры с H.264 на H.265 – и битрейт примерно вдвое падает, утягивая 51,6 ТБ к 26 ТБ. Пишите по движению вместо непрерывной – и обычно тихая сцена падает дальше; пишите только по событию (триггеру аналитики) – падает ещё. Режим записи настолько решает, что называть число хранилища без него бессмысленно: непрерывная, по движению, по событию и по расписанию дают совсем разные следы для тех же камер.

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

Две заметки про железо. Запись видеонаблюдения непрерывна и круглосуточна, поэтому диски – специальные для видеонаблюдения (Seagate SkyHawk, WD Purple), рассчитанные на постоянную запись, а не настольные. А поскольку мёртвый диск в массиве на 50 ТБ означает потерянные улики, диски обычно собирают в RAID, чтобы система пережила отказ диска без потери записей. Полная модель – уровни, RAID, политика хранения – тема статьи как работает хранилище видеонаблюдения: расчёт ретенции.

Типовой режим отказа: хранилище под демо, а не под политику хранения – система, заявленная «на 30 дней» на бумаге, реально держит девять, потому что в таблицу подставили битрейт H.265, а камеры приехали в H.264, или заложили непрерывную запись как будто по движению.

Стадия 5 – Аналитика: превращение видео в информацию

Типовая технология: модели компьютерного зрения, работающие на камере (край), на локальном сервере (edge-сервер) или в облаке – отдаются в VMS как метаданные, часто через ONVIF Profile M.

Это стадия, превращающая часы записей, которые никто не смотрит, в события, на которые стоит реагировать. Видеоаналитика – это софт, который смотрит на видео и докладывает, что видит: человек, машина, пересечённая линия, забытая сумка, автомобильный номер. Само распознавание – модель компьютерного зрения; систему видеонаблюдения волнует, где эта модель работает, потому что выбор перекраивает задержку, трафик, стоимость и приватность.

Запускать её можно в трёх местах, и они правда разные:

• На камере (edge AI): чип внутри камеры гоняет модель. Результаты приходят за десятки миллисекунд – современный edge-инференс обычно укладывается в 10–100 мс, – и почти никакое видео не покидает камеру, что экономит трафик и держит сырые кадры локально ради приватности (Фора Софт; отраслевые замеры).
• На локальном сервере (edge-сервер): более мощная машина на объекте гоняет тяжёлые модели по многим камерам, балансируя возможности против стоимости выделенного железа.
• В облаке: видео или клипы едут вверх в дата-центр на анализ. Облако выигрывает на тяжёлых, межкамерных рассуждениях и моделях, которые улучшаются со временем, но добавляет сетевой круг – обычно 200–2 000 мс и более – и постоянный счёт за трафик и вычисления, растущий с каждой камерой.

Практичный приём 2026 года – гибрид: край поднимает быструю тревогу, облако делает медленный глубокий анализ. Одно правило стоит запомнить: выше примерно 20 постоянно активных камер счёт за трафик и облачные GPU обычно перегоняет стоимость edge-железа в пределах года. Решение о развёртывании разобрано в статье аналитика на крае против облака; внутренности модели – как именно инженерится распознавание – относятся к разделу ИИ для видеоинженерии, на который этот курс ссылается, а не повторяет.

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

Одно честное слово о точности, потому что отрасль её перепродаёт. Ни одна аналитика не точна на 100%. Хорошо настроенный детектор людей или машин при хорошем свете может быть отличным, но точность – это диапазон полноты и точности (precision/recall), падающий в темноте, дождь, под странным углом, в толпе и при перекрытии. Правильный вопрос вендору – не «точно ли это?», а «какая точность и полнота, при каких условиях и как мы снижаем ложные тревоги?». Ведите от того, как аналитика ведёт себя под реальной нагрузкой, а не от числа из демо.

Типовой режим отказа: смешать три уровня в одно слово «ИИ», а потом либо утопить операторов в ложных тревогах от ненастроенной модели, либо подписаться на облачный счёт за трафик, который никто не посчитал на полном числе камер.

Стадия 6 – Клиент: где люди действительно смотрят

Типовая технология: клиент VMS – настольная видеостена, браузер или мобильное приложение – с ролевым контролем доступа.

Видео, на которое никто не может среагировать, потрачено зря, поэтому шестая стадия – человеческая: клиент, приложение, где операторы смотрят живые потоки, перематывают записи и реагируют на тревоги. Это может быть стена мониторов в ситуационном центре, браузер для редкого зрителя или телефон у руководителя в движении. VMS кормит их всех из одних и тех же записей.

Тихая, но критичная технология здесь – ролевой контроль доступа (RBAC): каждый пользователь видит только те камеры и функции, которые нужны его роли. Охранник на входе, региональный менеджер и подрядчик-техник не должны иметь один и тот же вид – и ради безопасности, и, всё чаще, ради закона о приватности. Есть и человеческий предел, который не чинит никакой софт: оператор осмысленно следит лишь за горсткой живых потоков сразу – именно поэтому и существует аналитика Стадии 5: направить внимание человека на те немногие потоки, что важны прямо сейчас.

Типовой режим отказа: слишком много камер на оператора без аналитики, чтобы их отсортировать, и инциденты теряются в стене движения; или плоский доступ, где все видят всё, который проваливает первый же аудит приватности.

Стадия 7 – Интеграция и тревоги: от события к действию

Типовая технология: движок событий VMS, связанный с контролем доступа, сигнализациями и другими системами через API и SDK; тревоги доставляются людям и системам.

Последняя стадия – там, где видеонаблюдение перестаёт быть записью и становится частью того, как здание или город реально реагируют. VMS сидит в центре паутины других систем: контроль доступа (замки дверей и считыватели карт), тревожные сигнализации, управление зданием и каналы оповещений. Когда аналитика на Стадии 5 срабатывает, слой интеграции решает, что произойдёт: запереть дверь, поднять тревогу, отправить уведомление, эскалировать охране или просто записать в журнал для последующего поиска.

Эти связи делаются через API (документированный интерфейс запрос-ответ, который система выставляет) и вендорские SDK (наборы для разработки). Часть несёт ONVIF – Profile M двигает метаданные аналитики и события в стандартном виде, – но более глубокие, продуктовые интеграции обычно едут на вендорском SDK или REST API. Здесь же видеонаблюдение встречается с остальным стеком безопасности, и здесь кастомная VMS отрабатывает вложения, потому что коробочные платформы интегрируют лишь то, что выбрал их вендор, и ничего больше.

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

Типовой режим отказа: усталость от тревог – каждое событие считают срочным, пока операторы не отключат систему – или изолированное развёртывание, где камеры пишут, но ничто не связано с действием, так что записи смотрят только после инцидента, а не во время.

Слой, который обёртывает всё: приватность и хранение

Это инженерное руководство, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Семь стадий сидят внутри слоя приватности и хранения, потому что видео наблюдения – это персональные данные с момента, как на нём появляется узнаваемый человек, и закон относится к нему именно так. Это не стадия, которую прикручивают в конце; она касается каждого шага – от камеры, которой не стоит снимать соседский сад, до хранилища, которое обязано удалять записи по графику.

Двумя принципами держится большая часть. Первый – цель и минимизация: вы должны записывать ради конкретной заявленной причины и снимать не больше, чем эта причина требует. Руководство Европейского совета по защите данных прямо говорит, что размытая цель вроде «безопасность» недостаточно конкретна и что если аудио или распознавание лиц не нужны, эти функции стоит выключить (EDPB Guidelines 3/2019). Второй – ограничение хранения: записи держат лишь столько, сколько требует цель, часто всего несколько дней для рутинных случаев – а значит, закон о приватности задаёт максимальный срок хранения поверх любого операционного минимума. Это разные числа, и их постоянно путают.

И есть биометрический барьер, более резкий, чем ждёт большинство команд. В момент, когда аналитика распознаёт конкретное лицо или читает номер, привязанный к человеку, она обрабатывает биометрические или персональные данные по усиленным правилам – особая категория данных по GDPR ЕС (Reg. (EU) 2016/679, ст. 9), а в Иллинойсе – по закону Biometric Information Privacy Act (BIPA, 740 ILCS 14), который несёт частное право иска и установленные законом убытки. Инженерное следствие конкретно: распознавание лиц и номеров – юридическое решение раньше, чем техническое, и выпуск их без этой проверки – самый опасный режим отказа во всей статье. Мониторинг больших публичных пространств может также требовать формальной оценки воздействия на защиту данных (DPIA) по ст. 35 GDPR. Мы инженеры, а не юристы, и блок приватности этого курса – начиная со статьи GDPR для видеонаблюдения – существует, чтобы сделать этот слой конкретным.

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

Весь конвейер в виде таблицы

Вот каждая стадия с её технологией и характерным режимом отказа – версия, которую держат рядом при проработке проекта.

Таблица 1. Система по строке на стадию. Большинство отказов – одна недоразмеренная или неверно выбранная стадия, а не сломанная система; вот почему называть стадии и есть весь смысл.

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

Самый дорогой шаблон, который мы видим, – оптимизировать одну стадию в отрыве. Команда берёт красивые 4K-камеры (Стадия 1), не пересчитав хранилище (Стадия 4), и массив заполняется за две недели. Или покупает мощную облачную аналитику (Стадия 5), не смоделировав аплинк (Стадия 2), и сеть захлёбывается, едва все камеры пойдут вверх разом. Стадии – это цепь, и цепь крепка и доступна по цене лишь настолько, насколько крепко звено, которое кто-то забыл пересчитать. Лекарство – та самая дисциплина, вокруг которой построена статья: меняя любую стадию, пройдите карту влево и вправо и спросите, что изменилось двумя шагами дальше.

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

Фора Софт строит софт реального времени для видео, стриминга и компьютерного зрения с 2005 года – это 250+ выпущенных проектов, – и видеонаблюдение лежит ровно на пересечении этих трёх областей. Команды приходят к нам, когда коробочная платформа упирается в потолок на одной из этих стадий: приём, который должен впитать смешанный, многовендорный парк камер; аналитика, которая обязана давать реальные точность и полноту на полном числе камер, а не в демо; хранилище и ретенция, посчитанные реалистично против политики приватности; или слой интеграции, который должен говорить с системами, которых вендор VMS не предвидел. Мы строим этот кастомный слой VMS от начала до конца, и ведём всегда от того, как система ведёт себя под реальной нагрузкой, а не от возможностей. Реальный диапазон точности бьёт впечатляющее число из демо каждый раз.

Ключевые выводы

• Система видеонаблюдения – цепь из семи стадий: камера, сеть, приём, хранилище, аналитика, клиент, интеграция.
• Слой приватности и хранения обёртывает каждую стадию; биометрия – юридический барьер, а не просто функция.
• Видео становится меньше и осмысленнее слева направо; трафик и хранилище стоят дороже всего слева.
• Хранилище – это арифметика (битрейт × камеры × часы × дни) и самая недооценённая по бюджету стадия.
• Край, edge-сервер и облако несут разные счета за задержку, трафик и приватность – не смешивайте их.
• Большинство отказов – одна недоразмеренная стадия, поэтому, меняя одну, перепроверяйте соседние.

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

• Что такое VMS, NVR и DVR
• On-prem, облако и гибрид – три модели развёртывания VMS
• Как работает хранилище видеонаблюдения: расчёт ретенции