Как сократить объём видеоархива без потери важных данных

Объём архива занижают, когда берут из даташита строку «средний битрейт» и умножают её на число камер и суток. Даташит показывает среднее по спокойной дневной сцене, а расчёт хранения должен опираться на верхнюю границу потока — тот битрейт, который камера выдаёт ночью, в дождь и при движении в кадре.

Посмотрим на разницу в цифрах. Камера со «средним битрейтом 2000 кбит/с» даёт 21,6 ГБ в сутки и 0,65 ТБ за 30 суток; на 40 камер — 25,92 ТБ. Та же камера, настроенная по техническому минимуму Приложения 2 к Правилам функционирования НСВМ (не менее 5000 кбит/с), занимает 54 ГБ в сутки и 1,62 ТБ за 30 суток; на 40 камер — 64,8 ТБ. Разрыв — 2,5 раза, и он целиком уходит в срок хранения.

Вторая часть ошибки — переменный битрейт. При режиме VBR камера повышает поток, когда в кадре появляется движение или шум матрицы на низкой освещённости. Axis в whitepaper «Bitrate control for IP video» описывает это прямо: без ограничения максимального битрейта поток на сложных сценах уходит вверх, и предсказать занимаемое место по среднему значению нельзя. Поэтому в расчёте мы берём либо норматив, либо заданный на камере потолок MBR — и никогда «среднюю цифру из паспорта».

По нашему опыту на объектах в Казахстане это самая частая причина, по которой архив «не доживает» до нужной глубины: массив куплен под 25,92 ТБ, а система пишет 64,8 ТБ. Ровно там же начинается и перерасход бюджета — почему архив и хранение резко увеличивают цену CCTV, мы разбирали отдельно.

Объём считается в одно действие: битрейт в кбит/с делим на 8 (получаем кБ/с), умножаем на 86 400 секунд в сутках и переводим в гигабайты. Для 5000 кбит/с: 5000 ÷ 8 = 625 кБ/с = 0,625 МБ/с; 0,625 × 86 400 = 54 000 МБ = 54 ГБ в сутки. За 30 суток — 1620 ГБ, то есть 1,62 ТБ на одну камеру.

Дальше умножаем на число камер и на срок хранения. Для 40 камер в едином режиме: 40 × 54 ГБ = 2160 ГБ в сутки = 2,16 ТБ; за 30 суток — 64,8 ТБ. Для удобства держите под рукой перевод «кбит/с → ГБ в сутки»: коэффициент 0,0108.

Разрешение и число мегапикселей в эту формулу не входят напрямую — они влияют на объём только через битрейт. Именно поэтому «поставим 8 Мп вместо 4 Мп» не означает автоматического удвоения архива, а снижение потока на камере 8 Мп не всегда безопасно для распознавания. Что реально определяет качество картинки, мы разбирали в материале про то, что важнее: мегапиксели, объектив, свет, WDR или аналитика.

Второй источник недобора — подмена рабочей ёмкости паспортной. Из сырого объёма дисков нужно вычесть избыточность RAID, служебные структуры файловой системы и эксплуатационный резерв. В расчётах мы применяем коэффициент 0,9 — это запас около 10 % на служебные нужды и на то, чтобы массив не работал на пределе заполнения.

Разберём типовой случай. Массив из четырёх дисков по 8 ТБ в RAID5 даёт не 32 ТБ, а 24 ТБ полезной ёмкости — один диск уходит под контроль чётности. С коэффициентом 0,9 рабочих остаётся 21,6 ТБ. При суточной записи 2,16 ТБ (40 камер по 54 ГБ) архив закольцуется через 10 суток, а не через 30. Формально диски «на 32 ТБ» — фактически десять суток глубины.

Чтобы удержать 30 суток при 64,8 ТБ записи, нужно 72 ТБ полезной ёмкости (64,8 ÷ 0,9). Это RAID5 из шести накопителей по 16 ТБ: 80 ТБ полезных и 72 ТБ рабочих. Разница с исходным массивом — не проценты, а другой класс хранилища. Отсюда и практический вывод: сначала считаем объём, потом выбираем полки и диски, а не наоборот.

Экономия не распространяется на камеры, попадающие под требования Национальной системы видеомониторинга. Технические минимумы для них задаёт Приложение 2 к Правилам функционирования НСВМ — приказ Председателя КНБ РК от 27.10.2020 № 69-қе (adilet.zan.kz, V2000021693). Снижать эти параметры «ради места» нельзя: это прямое отступление от норматива.

В минимум входят разрешение не ниже 1920×1080, частота 25 кадров в секунду, битрейт не менее 5000 кбит/с, светочувствительность 0,01 лк, исполнение IP66, глубина архива не менее 30 суток и автономность питания не менее 60 минут. Там же заданы три значения плотности пикселей по типам зон — 50, 150 и 250 пикс/м; других значений норматив не содержит.

Обязанность оснастить объект системой охранного телевидения и хранить записи не менее 30 суток установлена постановлением Правительства РК от 06.05.2021 № 305 (adilet.zan.kz, P2100000305). Попадает ли конкретный объект в перечень и нужно ли передавать поток в НСВМ — вопрос отдельный, мы разбирали его в материале про подключение к национальной системе видеомониторинга.

Практический смысл раздела простой: сначала разделите камеры на две группы — «попадают под требования НСВМ» и «внутренние технологические». Первая группа в оптимизацию не входит вообще. Вся экономия берётся на второй, и там она достигает трети общего объёма.

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

1. Разделить камеры по классам зон. Периметр, входы и кассовые узлы — режим по нормативу без изменений. Проходы и торговый зал — узнавание, достаточно умеренного потока. Технологические помещения, где нужен только факт события, — минимальный режим.
2. Задать частоту кадров по задаче. 25 кадров в секунду нужны там, где норматив это требует и где фиксируется быстрое движение. Для склада, коридора или помещения оборудования 8–12 кадров в секунду дают полноценную хронологию события.
3. Ограничить пиковый битрейт (MBR), а не «средний». Потолок потока делает расчёт предсказуемым: вы точно знаете верхнюю границу занимаемого места. Без потолка VBR ночью уводит объём вверх и съедает глубину архива.
4. Включить запись по событию с преролом — только на технологических зонах. Пререкорд 5–10 секунд сохраняет момент до срабатывания детектора. На ключевых зонах мы оставляем непрерывную запись: разбор инцидента по фрагментам с пропусками почти всегда упирается в то, чего в архиве не оказалось.
5. Не удлинять глубину для всех каналов, а выгружать инциденты. 30 суток — обязательный минимум для объектов перечня. Если по внутренним правилам нужны материалы «на полгода», дешевле экспортировать конкретные записи в отдельное хранилище, чем поднимать глубину всего массива. Сколько именно суток нужно вашему объекту, мы разбирали в материале про срок хранения видеоархива.

Отдельно про запись только по движению как «универсальную экономию». В зонах с постоянным трафиком детектор срабатывает почти непрерывно, и экономии не будет, а на въезде с деревьями и меняющимся освещением он даёт ложные включения. Приём рабочий, но точечный.

H.265 действительно снижает объём, но не на всех сценах одинаково, и закладывать в расчёт «минус 50 % на весь объект» нельзя. Ориентир примерно вдвое меньшего потока при равном качестве заявлен для стандарта HEVC (ITU-T H.265 / ISO/IEC 23008-2) относительно H.264. Axis для собственной технологии Zipstream в whitepaper «Axis Zipstream technology — Cut the storage, not the quality» указывает снижение в среднем на 50 % и более относительно стандартного сжатия.

Ключевое слово здесь — «в среднем». Экономия кодека берётся из статичного фона: там, где сцена не меняется, кодер передаёт мало данных. Как только фон перестаёт быть статичным, выигрыш падает.

Где обещанная экономия проседает на практике:

• Ночная сцена с шумом матрицы. Шум для кодера — это изменение картинки, и он его кодирует. По нашим замерам на объектах ночной поток на слабоосвещённой территории может приближаться к дневному пику вместо ожидаемого снижения.
• Дождь, снег, качающиеся ветки, флаги. Постоянное движение по всему кадру — худший сценарий для любого «умного» кодека.
• Мерцающая подсветка и засветка фарами. Резкие перепады яркости заставляют кодер обновлять кадр целиком.
• Совместимость с регистратором и аналитикой. Часть систем принимает H.265 не по всем каналам либо переключается на H.264 при работе аналитики на стороне сервера.

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

На нашем примерном складском объекте с торговым блоком 40 камер: 12 попадают под требования НСВМ (периметр, въездная группа, входы), 28 — внутренние технологические. Единый режим 5000 кбит/с на всех камерах даёт 2,16 ТБ в сутки и 64,8 ТБ за 30 суток. После разделения по зонам — 1,39 ТБ в сутки и 41,80 ТБ за тот же срок.

Проверим арифметику: 12 × 54 = 648 ГБ, 18 × 32,4 = 583,2 ГБ, 10 × 16,2 = 162 ГБ — вместе 1393,2 ГБ в сутки, за 30 суток 41 796 ГБ, то есть 41,80 ТБ. Против 64,8 ТБ это минус 23,0 ТБ, или 35 % объёма.

Разница в железе считается через тот же коэффициент 0,9. До оптимизации нужно 72 ТБ полезной ёмкости — RAID5 из шести накопителей по 16 ТБ (80 ТБ полезных, 72 ТБ рабочих). После — 46,44 ТБ полезной ёмкости, то есть RAID5 из четырёх накопителей по 16 ТБ (48 ТБ полезных, 43,2 ТБ рабочих при потребности 41,80 ТБ). Два накопителя разницы — и это без единой камеры, снятой с записи, и без изменения режима на зонах, где его менять нельзя.

Что при этом не потеряно: все 12 камер зон под требования НСВМ пишут в полном режиме и глубиной 30 суток; в торговом зале сохраняется плотность, достаточная для узнавания человека; в технологических помещениях остаётся хронология событий. Сокращён объём, а не зона наблюдения и не глубина архива.

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

1. В расчёте указан битрейт, по которому считали, — и это потолок MBR или норматив, а не «средний» из даташита.
2. Суточный объём одной камеры сходится: битрейт ÷ 8 × 86 400. При 5000 кбит/с должно получиться 54 ГБ.
3. Умножение на число камер и суток выполнено явно, а не заменено «примерно с запасом».
4. Из ёмкости массива вычтена избыточность RAID (в RAID5 — один диск, в RAID6 — два).
5. Применён эксплуатационный резерв — рабочая ёмкость меньше полезной примерно на 10 %.
6. Камеры разделены на попадающие под требования НСВМ и остальные; для первых режим соответствует Приложению 2 к Правилам НСВМ.
7. Заявленная глубина проверена на живой системе: откройте архив на дату «минус 30 суток» и убедитесь, что запись есть по каждому каналу, а не только по части.

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