Режимы записи CCTV: постоянная, движение, событие

Автор: Николай СапуновОбновлено: август 202618 мин чтения
Содержание статьи +

Коротко

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

Зачем это нужно

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

Коэффициент записи: одно число из уравнения хранения

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

Объём (ГБ) = битрейт (Mbps) × 10,8 × камеры × дни хранения × коэф. записи

Каждый член этого уравнения мы разбираем в статье про ретенцию; здесь важен только последний. Коэффициент записи – это доля каждых суток, когда камера пишет видео. Камера, пишущая круглосуточно, имеет коэффициент 1,0. Камера, которая пишет лишь те четыре часа в сутки, когда что-то реально происходит, – коэффициент около 0,17, примерно шестую часть объёма. Разрешение, частота кадров и кодек задают, насколько велик каждый записанный час; коэффициент записи задаёт, сколько часов вы вообще пишете. Именно это выбирает стратегия записи, и поэтому одна и та же камера может требовать шесть терабайт в месяц или шестьсот гигабайт – в зависимости лишь от того, как ей велено писать.

Сделать этот выбор можно четырьмя способами. Остальная часть статьи – про каждый из них: чего он стоит, чем рискует и как их сочетать.

Рис. 1. Четыре режима записи за сутки – закрашенные участки пишутся на диск.

Режим 1 – постоянная запись: безопасное и дорогое умолчание

Постоянная запись – иногда её продают как запись 24/7 или CVR (Continuous Video Recording) – пишет каждый кадр, весь день, каждый день. Её коэффициент записи равен 1,0, и это единственный режим, гарантирующий, что у вас есть запись любого момента, сработал датчик или нет. Если позже спор упрётся в то, что было в 3:47 ночи в пустом коридоре, у постоянной записи это есть.

Эта гарантия – и её цена. Камера, смотрящая на разгрузочную рампу с активностью два часа в сутки, всё равно пишет двадцать два часа пустоты. Используя разобранный в статье про ретенцию пример – камера 4 мегапикселя в кодеке H.265 при типичных 2 Mbps – постоянная запись даёт:

2 Mbps × 10,8 = 21,6 ГБ на камеру в сутки

На сорока таких камерах за тридцать дней это около 26 терабайт сырого видео, большая часть которого не показывает ничего. Постоянная запись – правильный выбор там, где пропуск недопустим: входы, обращение с наличными, игровые столы, зоны содержания, где упущенная секунда – это ответственность; и неправильный – как сплошное умолчание для каждой камеры на объекте. Ошибка не в том, чтобы её использовать, а в том, чтобы использовать её везде.

Режим 2 – запись по движению: писать, когда сцена меняется

Запись по движению пишет только пока камера фиксирует изменение в своём поле зрения. Когда сцена неподвижна, она не пишет ничего; когда что-то движется – начинает. На камере, смотрящей на в основном статичную сцену, это резко снижает коэффициент записи – отраслевые цифры оценивают экономию в 50–80% против постоянной, а распространённое эмпирическое правило – что запись только по движению делит объём примерно на три.

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

Современное лекарство – детекция объектов на базе ИИ, умолчание серьёзных камер 2026 года. Вместо подсчёта изменившихся пикселей камера запускает лёгкую нейросеть, которая классифицирует, что сдвинулось – человек, транспорт, животное, – и пишет только для нужных вам классов. Поскольку деревья, тени, дождь и животные больше её не запускают, объектная запись режет ложные срабатывания на 90–95% против пиксельного движения, превращая сотню паразитных записей в пять-десять осмысленных. Мы не разбираем здесь заново, как устроена эта модель детекции; внутренности модели – в статье обнаружение и классификация объектов нашего раздела AI for Video Engineering. Для стратегии записи вывод прост: объектное движение и экономит больше места, и заваливает вас меньшим числом мусорных клипов, чем пиксельное, и на камере 2026 года его обычно стоит включить.

Режим 3 – запись по событию и аналитике: писать, когда сработало правило

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

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

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

Режим 4 – запись по расписанию: писать по часам

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

Расписание редко используют в одиночку – это обёртка вокруг трёх остальных. Торговый зал может писать постоянно с 8:00 до 21:00 и переходить на ИИ-запись по событию ночью; школа – писать постоянно по будням и только по движению по выходным. Сделанное правильно, расписание полностью захватывает предсказуемое активное окно и позволяет тихим часам схлопнуться до доли данных. Его риск очевиден: инцидент вне «интересного» окна, в режиме, который вы выставили на «выкл» или на жёсткий триггер, записывается скудно или не записывается вовсе – поэтому расписание надо рисовать вокруг реального риска, а не просто вокруг часов работы.

Вот четыре режима рядом. Коэффициент объёма иллюстративен – реальная цифра зависит от того, насколько оживлена сцена и как настроены триггеры.

Режим записиЧто запускаетОбъём к постояннойЧто можно упуститьГде применять
Постоянная (24/7)Ничего – всегда вкл.100% (базис)НичегоВходы, кассы, содержание, гейминг
По движениюИзменение сцены (пиксели/AI)~20–50%Медленное; перезапись на погодеКамеры общих зон
По событию / аналитикаКонкретное правило или сигнал~5–25%Всё, что правило не покрылоПериметры, режимные зоны
По расписаниюЧасы / календарьЗависит от часовИнциденты вне окнаПредсказуемые рабочие часы
Рис. 2. Четыре режима в сравнении – триггер, стоимость хранения, слепое пятно и где применять.

Пре-буфер: как запись по триггеру перестаёт упускать подход

У всех режимов, кроме постоянного, есть один общий изъян, и это самое важное, что нужно понять про запись по триггеру: триггер срабатывает уже после того, как интересное началось. Движение фиксируется через мгновение после начала движения; событие аналитики поднимается после того, как человек вошёл в зону. Если запись стартует только в момент срабатывания триггера, вы фиксируете инцидент, но теряете подход к нему – приближение, лицо до того, как оно отвернулось, машину до того, как она остановилась. В расследовании подход часто и есть та часть, что важна.

Лекарство – пре-буфер (пре-запись, pre-roll). Камера непрерывно держит последние несколько секунд видео в скользящем буфере памяти, даже когда не пишет на диск. При срабатывании триггера она записывает этот буферизованный подход плюс живое видео, так что сохранённый клип начинается за секунды до триггера. Парный пост-буфер (post-roll) продолжает запись заданное время после снятия условия, чтобы не потерять последствия. Типичные настройки – несколько секунд и примерно до 30 секунд с каждой стороны; когда пре-буфер держится в RAM, он часто ограничен примерно 15 секундами, а более длинные пре-буферы пишутся на носитель. Milestone XProtect, широко используемая VMS, документирует именно это поведение пре-буферизации в памяти.

[ пре-буфер: 5–15 с ] → ТРИГГЕР → [ запись события ] → [ пост-буфер: 10–30 с ]
     держится в памяти              живьём на диск          сохраняет последствия

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

Рис. 3. Пре-буфер сохраняет подход; пост-буфер – последствия.
«Частая ошибка: верить, что запись по движению одновременно дешёвая и полная. Команды часто переводят все камеры на запись по движению, видят падение оценки хранения и считают, что дело сделано. Дальше идут не так две вещи. Во-первых, на уличных или оживлённых сценах пиксельное движение перезапускается на дожде, фарах и листве, так что реальный объём оказывается куда выше оценки, и диски заполняются рано. Во-вторых, без пре-буфера и при чуть медленном триггере сохранённые клипы упорно стартуют поздно и упускают подход. Камеры выглядят так, будто экономят деньги и ловят события, а тихо не делают ни того, ни другого хорошо. Лекарство – объектные триггеры, чтобы убрать ложные старты, пре-буфер, чтобы поймать подход, и реальный тест: пройдите по объекту, спровоцируйте каждую камеру и посмотрите клипы – прежде чем доверять стратегии.»

Сочетание режимов: стратегия, которая реально уезжает в прод

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

  • Постоянная на горстке камер, где упущенная секунда недопустима, – главные входы, кассы, кассовые комнаты, зоны содержания или гейминга.
  • ИИ-событие или движение с пре-буфером на камерах общих зон и периметра, где важен редкий реальный инцидент, а пустые часы – нет.
  • Расписание как обёртка – полная запись в предсказуемом активном окне, более жёсткие триггеры, когда объект закрыт.

Пройдём по числам на примере с сорока камерами. Все постоянно – это около 26 ТБ за тридцать дней. Теперь предположим, что восемь камер остаются постоянными, а остальные тридцать две переходят на ИИ-запись по событию при среднем коэффициенте записи около 0,25 (четверть суток, щедро для периметра):

 8 камер постоянно:  8 × 21,6 ГБ × 30 дней  ≈  5,2 ТБ
32 камеры при 0,25: 32 × 21,6 × 0,25 × 30   ≈  5,2 ТБ
                                    итого    ≈ 10,4 ТБ

Это около 10 ТБ вместо 26 ТБ – срез примерно на 60% на уровне объекта, при том что восемь важнейших камер всё ещё пишут каждый кадр. Толкните дальше на одной тихой камере – и экономия ещё больше: камера периметра на жёстком ИИ-триггере может писать заметно меньше десятой части суток, уводя суточный объём с 21,6 ГБ к 2 ГБ – это близко к снижению на порядок на одной камере. Смешанная экономия на уровне объекта скромнее, чем лучший случай одной камеры, потому что постоянные камеры доминируют в сумме – и именно поэтому стратегия в том, чтобы держать этот постоянный набор маленьким и осознанным.

Рис. 4. Суточный объём на камеру по режиму – режим и есть рычаг, а жёсткая запись по событию ≈ десятая часть постоянной на тихой сцене.

Где тут стандарты: ONVIF Profile G и Profile M

Режимы записи в основном настраиваются в VMS, но два профиля ONVIF решают, переживёт ли эта настройка смену вендора. ONVIF – это общий язык, на котором камеры и записывающее ПО разных производителей понимают друг друга; его профили делят этот язык по задачам.

ONVIF Profile G – открытый стандарт записи и извлечения. Его спецификация – актуальная версия 1.1, опубликована в октябре 2025 года – определяет, как ONVIF-клиент (ваша VMS) управляет записью на ONVIF-устройстве (камере, энкодере или сетевом регистраторе) и как он ищет и воспроизводит сохранённое. Конкретно Profile G стандартизирует задания записи (recording jobs): совместимый клиент может создавать и удалять задания записи (CreateRecordingJob, DeleteRecordingJob), читать их состояние и, что важно, менять режим задания операцией SetRecordingJobMode – стандартный крючок, позволяющий VMS переключать задание записи между активным и простаивающим. Он также стандартизирует поиск событий (FindEvents), так что клипы, запустившие запись, можно снова найти у разных вендоров.

Вот граница, которая бережёт покупателя от неприятностей. Profile G стандартизирует интерфейс управления и извлечения – старт, стоп, управление заданием, поиск результата. Он не стандартизирует логику триггеров: что считать движением, как задаётся расписание, какой длины пре- и пост-буфер и насколько чувствительна зона – настраивается на устройстве или в VMS, а более богатые варианты часто требуют ПО вендора. Помните правило видеонаблюдения из нашего разбора ONVIF: ONVIF гарантирует базовый уровень, на котором сходятся оба устройства, а не полный паритет функций. Коммерческий обзор того, как профили ложатся на реальные продукты, – в гайде Фора Софт про профили ONVIF в системах безопасности.

Аналитика, запускающая запись по событию, всплывает через ONVIF Profile M, профиль метаданных и аналитики. Когда аналитика камеры поднимает событие – объект классифицирован, линия пересечена – Profile M это то, как событие в стандартизированной форме доходит до VMS, которая может запустить задание записи Profile G. Эту передачу мы подробно разбираем в статье события, метаданные и интерфейс аналитики ONVIF. Два профиля вместе – M, чтобы донести событие, G, чтобы записать по нему – это стандартный хребет под записью по аналитике.

Рис. 5. ONVIF Profile G стандартизирует управление записью и извлечение; Profile M несёт событие аналитики – но логика триггеров, расписание и буферы остаются на стороне устройства и VMS.

Режим записи – ещё и рычаг приватности

Выбор режима записи обычно подают как решение о хранении, но в регионах с регулированием приватности это ещё и вопрос соответствия – и оба тянут в одну сторону. По Общему регламенту ЕС о защите данных (GDPR, Регламент (ЕС) 2016/679) узнаваемое видео людей – это персональные данные, а статья 5(1)(c), принцип минимизации данных, требует, чтобы собираемые данные были «адекватными, относящимися к делу и ограниченными необходимым». Запись только тогда и там, где может произойти что-то релевантное, – это минимизация данных в действии. (Это инженерное руководство, а не юридический совет – уточняйте специфику вашей юрисдикции у квалифицированного юриста.)

Guidelines 3/2019 Европейского совета по защите данных (EDPB) об обработке персональных данных через видеоустройства делают связь явной. Они указывают, что запись «не должна также вестись во время суток или в зонах, которые не нужны или нерелевантны для цели», и приводят пример, что оператору стоит рассмотреть, не достигнет ли цели «работа камер только ночью». Это регулятор описывает запись по расписанию и по зонам как приватность-сберегающий дизайн, а не просто тактику хранения. Камера, настроенная писать только периметр, только после закрытия, по объектным триггерам, собирает меньше персональных данных, чем та, что перемалывает 24 часа занятого офиса, – и её проще обосновать. Сторона ретенции этого же принципа – как долго хранить то, что вы записали, – разобрана в нашей статье про политику хранения и управляется правилом ограничения хранения в статье 5(1)(e) GDPR. Вывод: стратегия записи, которая дешевле, часто и есть та, что собирает меньше всего, и закон о приватности вознаграждает обе.

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

Стратегия записи – из тех проектных решений, что выглядят пустяком в меню настроек, а через месяцы решают, удержит ли система важную запись, не утонув в неважной. Фора Софт строит видеостриминг, real-time-видео и системы компьютерного зрения с 2005 года – более 250 выпущенных проектов – а видеонаблюдение лежит на пересечении всех трёх. Когда мы строим или дорабатываем VMS, мы зашиваем режим записи для каждой камеры, а не для всего объекта: ИИ-объектную запись по событию там, где пиксельное движение перезапускалось бы, пре- и пост-буферы под задачу камеры, расписания вокруг реального риска – и всё это привязано к политике хранения, чтобы объём и соответствие двигались вместе. Привычка «точность против нагрузки» применима и здесь: мы проверяем стратегию, провоцируя каждую камеру и просматривая клипы, потому что режим записи, который выглядит правильно в настройках и упускает подход в день инцидента, – это не стратегия, а ответственность.

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

  • Режим записи задаёт коэффициент записи – самый большой рычаг хранения на любой камере.
  • Постоянная не упускает, но дороже всего; движение, событие и расписание режут объём на 50–90%.
  • Пиксельное движение перезапускается на погоде; ИИ-объектные триггеры режут ложные старты на ~90–95%.
  • Пре-буфер сохраняет подход, который триггер иначе упустил бы, – не пропускайте его.
  • Реальные системы смешивают режимы покамерно; смешанный объект на 40 камер режет объём ~60%.
  • ONVIF Profile G стандартизирует управление записью и извлечение; логика триггеров остаётся у вендора.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.