Перейти к содержанию

Главная / Статьи

реальная рабочая схема · evidence verified

Почему я храню события камер отдельно от NVR

NVR у меня и так пишет камеры круглосуточно. Поэтому от Frigate мне нужен не второй огромный архив, а быстрый доступ к важным моментам: человеку у калитки, машине или открытию ворот. Ниже — как я разделил эти две задачи.

76+реальных MP4 на проверке
30 cperson / car
60 cоткрытие ворот
224+ GiBсвободно на архивном FS при проверке

Две системы вместо одной

Камеры
├── Hikvision NVR → непрерывная запись
└── Frigate → понять событие
                ↓
          smart archive
          ├── persons / 30 s
          ├── cars / 30 s
          └── gates / 60 s

NVR отвечает на вопрос «что происходило вообще». Событийный архив — «покажи мне нужный момент». Если аналитика ошиблась, исходный полный контекст всё равно остаётся.

Что реально накопилось

ТипФайловОбщий объёмСредний файл
Человек45≈321 MiB≈7.14 MiB
Автомобиль22≈207 MiB≈9.40 MiB
Ворота9≈197 MiB≈21.87 MiB
Всего76≈725 MiB—

Человек у калитки

camera = cam_fe768590
label = person
→ persons / 30 s

Событие дедуплицируется по Frigate event_id. Если запись уже идёт, повторное пересекающееся событие не запускает второй параллельный ролик.

Автомобиль: одной метки car оказалось мало

camera = nvr_d7
label = car
zone = proezd
→ cars / 30 s

Зона обязательна: стоящая машина на парковке раньше могла создавать ненужные повторные события.

Ворота: реальный 60‑секундный тест

Проверено живым событием.

14:33:37 Recording gates for 60s
14:34:37 Saved ...14-33-37.mp4

А что с PPS id out of range: 0?

Warning есть — прятать его не буду.

Архиватор использует -c:v copy: видео remux'ится без повторного кодирования.

Проверенный gate‑файл был полностью прогнан через FFmpeg с -xerror. Результат: decode_rc=0. Для этого MP4 warning не привёл к фатальной ошибке декодирования.

Для оценки места по своему потоку используйте калькулятор видеоархива. В событийном режиме задайте среднее уникальное время сохранённой записи в сутки; число файлов в этом кейсе не означает ежедневную частоту событий.

Ловушка с цифрой заполнения диска

Host-side storage в Proxmox выглядел сильно занятым, но это не было заполнением файловой системы архива.

внутри Frigate VM:
total ≈ 225.3 GiB
used  ≈ 0.71 GiB
free  ≈ 224.6 GiB

Проще говоря: одна цифра «занято на 79%» ещё ничего не говорит, пока не понятно, какой именно диск и какую файловую систему она описывает.

Retention по свободному месту

MIN_FREE    = 10 GiB
TARGET_FREE = 15 GiB

Если свободного места становится меньше 10 GiB, архив удаляет самые старые MP4 до тех пор, пока не освободится 15 GiB. Пустые каталоги затем удаляются.

Алгоритм проверен чтением рабочего кода. Специально заполнять рабочий диск для destructive-теста я не стал.

Почему NVR остаётся

NVR → полный контекст
Frigate → понять событие
Smart archive → быстро найти важное

Событийная аналитика — вероятностный слой. Для системы безопасности мне важнее сохранить независимый полный архив, чем превратить один AI‑сервис в единственную точку истины.

Что связано с этим кейсом

Оборудование этой схемы

Здесь намеренно нет случайных кнопок «Купить». Для неизвестной точной модели товарная CTA не показывается, а партнёрская ссылка включается только после отдельной проверки конечной карточки и атрибуции.

Посмотреть реальный стенд →

Исходная проверка событийного архива. Материал будет обновляться по мере накопления статистики событий и retention.