Сегодня камеры стоят почти везде. В торговом центре они считают посетителей, на заводе следят за безопасностью, в логистике помогают оптимизировать процессы, а в офисе фиксируют, кто зашёл и кто вышел. Камера сама по себе — это просто глаз. Настоящая магия начинается тогда, когда поверх видео накладывается аналитика: нейросети, которые в реальном времени ищут людей, считают объекты, оценивают движение.
Но у этой магии есть обратная сторона — она очень прожорливая. Видеопотоки нужно прогонять через нейросети, и на больших данных даже мощные сервера начинают задыхаться. Особенно если система собрана «из коробки» и не оптимизирована.
Проблема клиента
С такой ситуацией к нам и пришёл клиент. У него уже стояла система видеоаналитики: несколько десятков камер, подключённых к серверу с GPU. Всё вроде бы работало, но слишком медленно. За тридцать секунд система успевала обработать всего четыре видеопотока.
Для живого бизнеса это означало одно: бизнес не получит информацию в моменте. Ведь, к моменту когда видео будет обработано, оно станет уже неактуальным. А теперь представьте, что речь идёт не об офисе, а о заводе или складе, где важна каждая секунда и где от скорости зависит безопасность людей.
Первое решение, которое обсуждали у клиента, было максимально простое: «давайте купим ещё одну видеокарту». Казалось бы, логично: больше железа — больше мощности. Но стоимость оборудования в такой конфигурации была бы сравнима с ценой небольшой машины, и это только начало расходов. К железу пришлось бы докупать софт, поддерживать инфраструктуру, а эффект при этом не гарантирован.
Мы предложили другой путь: оптимизировать систему так, чтобы она работала быстрее на том, что уже есть.
С чего начали
Мы всегда начинаем с диагностики. Сели и посмотрели, как именно устроен процесс. Выяснилось, что система работала «по накатанной»:
каждый видеопоток подавался в нейросеть отдельно,
обработка шла строго по очереди,
процессор и видеокарта работали не синхронно и большую часть времени простаивали.
Отдельная история была с разрешением входных кадров. В сеть загонялись изображения 640×480. Для бытовой камеры это кажется скромным размером, но для нейросети это лишние пиксели. Сеть честно пыталась их проглотить, только толку от этого не было. Людей в кадре это не делало «более узнаваемыми», зато ресурсы уходили в никуда.
Почему уменьшение разрешения — не страшно
Один из мифов видеоаналитики: «чем выше качество изображения, тем лучше результат». На самом деле это не всегда так. В задачах распознавания людей важны крупные контуры, движения, ключевые признаки. Увеличение разрешения до абсурда лишь добавляет лишние детали — плитка на полу, трещины на стенах, мелкие артефакты, которые для задачи не имеют никакого значения.
Мы начали постепенно уменьшать размер входных кадров. Эксперименты показали, что оптимальная точка — примерно 416×256. Это почти в полтора раза меньше исходного, но качество распознавания людей сохранилось. Зато скорость обработки резко выросла.
Параллельная обработка и балансировка
Следующим шагом было изменение самой логики работы. Если раньше система напоминала кассу в магазине, где очередь из десяти человек обслуживает один кассир, то мы сделали так, чтобы работало сразу несколько касс. Видео стали обрабатываться параллельно, и сразу загрузка ресурсов выросла в разы.
Здесь важно было грамотно распределить задачи между CPU и GPU. До оптимизации они работали несогласованно: GPU простаивал, пока процессор готовил данные, а процессор ждал, пока GPU «пережёвывает» ролик. Мы сделали так, чтобы GPU занимался инференсом, пока новые фреймы готовятся на CPU. Теперь оба ресурса загружены равномерно.
Результат
Когда мы закончили оптимизацию и запустили систему в работу, цифры приятно удивили даже нас. Вместо четырёх видеопотоков за 30 секунд система теперь обрабатывала 22. Почти шестикратное ускорение — без покупки нового оборудования.
Для клиента это означало экономию бюджета, отказ от дорогостоящего расширения инфраструктуры и при этом полноценное выполнение задач. Люди в кадре распознавались так же корректно, система перестала «задыхаться», и бизнес наконец получил инструмент, на который можно было опереться.
Что это показало
Опыт с этим проектом стал для нас хорошей иллюстрацией нескольких важных принципов.
Во-первых, в работе с нейросетями не всегда выигрывает максимальное разрешение. Иногда лишние пиксели только мешают.
Во-вторых, оптимизация алгоритмов и архитектуры часто даёт больший эффект, чем покупка нового «железа».
И в-третьих, тюнинг моделей — это отдельная инженерная задача, которая требует экспериментов, тестов и внимательного анализа. Но результат того стоит.
Итог
Сегодня эта система работает у клиента без перебоев и обрабатывает почти в шесть раз больше видеопотоков, чем раньше. Это не просто цифры в отчёте — это реальная разница между системой, которая еле справляется, и системой, которая помогает бизнесу работать эффективнее и безопаснее.
Для нас этот проект стал напоминанием о том, что оптимизация — это тоже искусство. Где-то оно заключается в архитектуре, где-то в правильной балансировке ресурсов, где-то в настройке самой модели. Но результат всегда один: система работает быстрее, а клиент получает больше пользы.
📹 Она распознаёт действия: пьёт, ест, ходит в лоток, просто гуляет. 💬 Отправляет уведомления владельцу с фото и комментарием. ✅ Различает нескольких питомцев и ведёт статистику по каждому.
📌Функции: - Двусторонняя аудиосвязь. - Управление через приложение (вращение камеры, отслеживание). - Звук “чириканья” для привлечения внимания животного.
🔹Цена вопроса: Сама камера - $100. ИИ-функции (подписка): $12/мес(для одного питомца) или $17/мес (для двух).
В качестве примера возможного использования интеллектуального наблюдения создал тестового бота в телеге, который наблюдает за белками. (зайти, написать /start ждать когда белочка придет :))
Далее, если белка на видео определилась, сервак засылает видео на опрос в Google Gemini.
Там идет описание видео и дополнительная проверка, например я прошу убедиться что в кадр не попал человек.
На данный момент промпт такой:
Условие: На видео нет людей, совсем. На видео есть птицы или белки. Описание: При описании не упоминай что людей нет. Опиши животных и птиц. Описывай видео как будто ты очень известный спортивный коментатор, соблюдай интригу, добавляй побольше эмоций. В качестве seed используй текущее время. Текущая дата в формате yyyy.MM.dd HH:mm:ss = %DATE%. Не пиши дату в описании.
Результат примерно такой:
Таким же образом можно вести наблюдение за чем угодно, за курящими, за подозрительными людьми. За квадроберами :)
Бонусом :
Походу пора бросать пить, поскольку помимо белок стали приходить другие дивные животные.
Недавно прибились дикие утки, обнаглели и приходили каждый день жрать просить. Поставил им тазик с водой, и корма насыпал. Жаришь шашлыки, а они в глаза глядят :)
Сейчас селезень свалил, утка походу высиживает птенцов, прилетает раз в день, быстро поест и обратно.
А сегодня пришло это чудо, ломилось в дверь. Видимо утки с белками рассказали:
Ссылка на тг с софтиной https://t.me/cam100gramm Основную разработку приостановил. Необходимый мне функционал готов. Если есть интересные идеи или проекты с использованием ИИ в видеонаблюдении, пишите. Обсудим :)
Немного апдейтов моего ИИ видеорегистратора Cam100Gramm.
Добавил интеграцию Home Assistant через MQTT, теперь можно включать свет когда соседский код пробегает по участку. Или когда соседка напялила красные лабутены можно это озвучить через яндекс колонку :)
Добавил функцию запроса через телегу скриншота или куска видео с конкретной камеры. Можно либо командой "/live camname frame", "/live camname video" или просто сделать запрос натуральным языком: "покажи мне кадр с камеры такой то".
Второе изменение это временные GPT уведомления. Допустим вы ждете такси или ОЗОН какой-нибудь. Теперь не надо всё жестко забивать в конфиг. Просто пишете в телеге что хотите увидеть и на какой камере. И так же говорите куда вас уведомить. Зависит от того какие каналы уведомлений вы добавили в настройках. Я для себя важные уведомления отправляю на почту. Можете создать два тг канала, один не важный и замьютить его, второй для важных уведомлений.
Примеры:
"Сообщи мне в телегу когда в камере Вид На дорогу появится фургон с надписью ОЗОН"
"Сообщи мне если кто-то подошел к камере в двери и тычет в камеру корочкой"
Скачать сервак в моем тг канале https://t.me/cam100gramm , канал не коммерческий, прога не коммерческая, я не коммерческий (с). Но если вы вдруг крутой бизнесмен и связаны с видеонаблюдением и у вас есть куча идей и желание развить на этой базе коммерческий проект, пишите, обсудим обмозгуем.. :)
PS: Апдейт как водится обмыл парой баночек пивка :)
Нейросети, умный дом, видеонаблюдение. Выглядит как набор слов, не так ли?
Оказывается, 4 года назад я начинал рассказывать о первых шагах к умному дому. Произошел небольшой перерыв (да, я ленивая жопа!) и я решил - почему бы не продолжить?
А сегодня я расскажу о том, как имея в распоряжении ПК под домашний сервер и несколько wifi камер сделать действительно "умное" видеонаблюдение.
1. Зачем всё это?
Хотел не просто «запись по движению», а умный видеорегистратор: чтобы определял человека в кадре, отличал кота от коробки, а в идеале ещё и писал текстом, что происходит.
Frigate 0.15 умеет именно это:
определяет объекты нейросетью YOLOv7 → быстро, open-source;
семантический поиск (CLIP) — можно найти «красную машину» за секунду;
через GenAI кидает кадры в LLaVA и получает короткое описание сцены.
Всё крутится локально: никакой утечки видео на чужие сервера и ноль абонплаты.
Главная страница Frigate
А вот и "красная машина" =)
Но не без приколов - по мнению детектора, на видео на 83% кот =)
Камеры: любые с RTSP-потоком (у меня 6 штут Tapo C500)
3. Зачем нужен GPU passthrough?
Отдельно остановлюсь: почему я заморочился с пробросом GPU в VM, а не запустил всё на CPU или, скажем, на TPU (Coral)? Дело в том, что моя задача – тянуть обнаружение объектов в реальном времени на нескольких камерахи параллельно гонять тяжелую модель для описания. Даже один поток 1080p с современным детектором (YOLOv7) может загрузить CPU на 100%, не говоря уж про генеративную модель с 13 миллиардами параметров (LLaVA 13B) – её на CPU вообще считать не будешь (за минуту никакого описания не дождешься). GPU же позволяет распараллелить эти задачи и выполняет их на порядки быстрее.
Таким образом, GPU passthrough — обязательный шаг, чтобы внутри VM иметь аппаратное ускорение. Он нужен, чтобы Frigate мог использовать CUDA/TensorRT для инференса нейросети, а ffmpeg – аппаратное декодирование/кодирование видео (NVDEC/NVENC). Без GPU моя затея с локальным AI-прислугой просто не взлетела бы.
Настройка прошла относительно спокойно: включил IOMMU в BIOS, в Proxmox добавил устройство hostpci0 (с указанием ID видеокарты), отключил эмулируемую VGA. Ubuntu внутри пришлось снабдить драйверами NVIDIA – после этого карта стала доступна, как если бы она была в обычном PC.
Примечание: в более простых сценариях можно было бы использовать USB-акселератор типа Google Coral TPU – Frigate тоже умеет, но у меня его нет, а вот 3050 просилась в бой. К тому же Coral даёт только обнаружение, а для LLaVA всё равно нужен бы был GPU или очень мощный CPU. Так что выбор очевиден.
Страница событий
4. Docker Compose: поднимаем Frigate и Ollama
Система в VM готова, теперь разворачиваем два основных сервиса в контейнерах: Frigate NVR и Ollama. Оба будут запускаться через Docker Compose — это удобно, чтобы они стартовали вместе и были связаны в одну сеть.
Я установил Docker Engine и docker-compose в Ubuntu (для опытных пользователей это тривиально: несколько команд, либо скрипт установки Docker от официального репозитория). Предполагаю, что читатель уже умеет ставить Docker и Compose, поэтому опущу подробности apt-установки.
Перейдем сразу к Compose-файлу. Вот финальная версия моего docker-compose.yml (@SupportTech, когда будут уже нормальные код-сниппеты?!):
version: "3.9"
services:
frigate:
container_name: frigate
privileged: true # ← проще дать контейнеру весь /dev, чем перечислять /dev/nvidia*
restart: unless-stopped
image: blakeblackshear/frigate:0.15.0-tensorrt # ← нужная сборка с TensorRT под NVIDIA
я использую тег stable-tensorrt. Это сборка под amd64 с поддержкой NVIDIA GPU. В ней уже включены нужные библиотеки CUDA и TensorRT для аппаратного ускорения инференса. Обычный stable образ не умеет работать с TensorRT, имейте в виду.
Привилегированный режим:
privileged: true: я включил для простоты, чтобы контейнер без препонов получил доступ к устройствам хоста.
shm_size: 2048mb:
увеличиваем раздел общей памяти. Frigate хранит там кадры для обнаружения и прочие буферы. По умолчанию Docker даёт 64Мб, но с несколькими камерами в высоком разрешении этого мало. В 0.15 Frigate сам ругается, если /dev/shm маловат. Я поставил 2048 MB – у меня 6 камер, этого достаточно, при необходимости можно больше. Главное, чтобы не было переполнения, иначе Frigate может упасть или терять кадры.
Tmpfs на /tmp/cache:
важный трюк. Frigate использует /tmp/cache для разных временных файлов (например, для отслеживания объектов, кадры для распознавания и т.п.). Монтируя туда tmpfs, мы удерживаем эти операции в RAM, что ускоряет работу и снижает износ диска. Рекомендация из документации, и действительно, нагрузка на диск резко упала после этого (SSD сказал спасибо). Я выделил 1 ГБ; в зависимости от числа камер и их разрешения можно увеличить или уменьшить.
Порты:
8971 – новый веб UI Frigate. Начиная с 0.15, интерфейс доступен только на защищенном (с авторизацией) порту.
8554 – RTSP restream (от встроенного сервиса go2rtc). Через него я могу при желании подключаться VLC/телефоном к камерам через Frigate, не нагружая сами камеры множеством прямых коннектов. Удобно, хотя я пользуюсь в основном веб-интерфейсом.
8555 (tcp и udp) – это порты для WebRTC. Frigate через go2rtc умеет раздавать видеопоток прямо в браузер по WebRTC, минуя RTSP. Это быстрее и экономит трафик, и обходится без плагинов.
Переменные среды:
FRIGATE_RTSP_PASSWORD – я назначил пароль для RTSP, и в конфиге камер могу использовать шаблон ${FRIGATE_RTSP_PASSWORD}. Чтобы случайно не засветить пароли, удобнее вынести их в env. (Frigate поддерживает подстановку env-переменных в config.yml).
YOLO_MODELS: "yolov7-640" – переменная окружения для контейнеров Frigate, предназначенная исключительно для автоматической загрузки (и/или перекомпиляции) моделей YOLO при первом старте.
Ollama:
Использую официальный образ ollama/ollama.
Порт 11434: это дефолтный порт REST API Ollama. Я его открыл наружу, хотя можно было не делать этого, если обращаться к модели только из Frigate. Frigate, работая в той же докер-сети, может достучаться до ollama:11434 без проброса на хост. Но мне для отладки хотелось иногда самому попробовать запросы к Ollama, поэтому порт пробросил.
Volume ollama-data на /root/.ollama: здесь хранятся модели, которые скачивает Ollama. Обязательно делаем volume, иначе при пересоздании контейнера вам придётся опять тянуть десятки гигабайт моделей 😅. С volume скачанные модели останутся. (Модели, кстати, он скачивает из интернета при первом запросе, имейте в виду).
Запустив docker-compose up -d, я проверил:
Frigate успешно стартовал, в логах увидел, что он нашёл GPU (строка [INFO] Nvidia decoder initialized и что-то про TensorRT). Если бы он не увидел GPU, он либо упал бы с ошибкой, либо работал на CPU, что нам не подходит.
Ollama запустился и слушает на 11434 – это можно проверить docker logs ollama или открыв http://<IP_ВМ>:11434 (он должен вернуть приветственное сообщение типа Ollama vX.X API).
Оба сервиса работают, но пока Frigate “пустой” – без конфигурации, а Ollama не знает, какую модель мы от него хотим. Пора заполнить конфиг Frigate и подготовить нейросети.
Пример описания события нейросетью
5. Настройка Frigate (config.yml)
Конфигурационный файл config.yml задаёт параметры Frigate: какие камеры подключать, как выполнять детекцию и пр. Рассмотрим минимальный рабочий конфиг под нашу задачу – одна камера с детекцией на GPU (YOLOv7-640):
detectors – указываем, что используем детектор типа tensorrt (Nvidia TensorRT) под именем nvidia. Параметр device: 0 означает использовать первый GPU (если у вас несколько видеокарт, можно указать соответствующий индекс). Frigate автоматически подхватит CUDA/TensorRT, если контейнер запущен правильно.
model – путь и параметры модели. Мы нацелились на YOLOv7-640, поэтому путь указывает на файл yolov7-640.trt (который сгенерируется в директории /config/model_cache/tensorrt внутри контейнера). Параметры width/height должны совпадать с размером сети (640x640). Остальные настройки (input_tensor, pixel_format) стандартны для YOLO моделей (формат входного тензора nchw и rgb). Если вы решите использовать другую модель (например, yolov7-tiny-416), не забудьте здесь поменять пути и размеры.
cameras – секция с описанием камер. В примере добавлена одна камера cam1.
ffmpeg.inputs – список потоков для этой камеры. Указан RTSP URL основного потока (stream1). У большинства IP-камер RTSP-поток формата rtsp://<user>:<password>@<ip>:554/<название_потока>. В некоторых камерах основной поток – H.264, в других – H.265. В нашем примере указан пресет preset-nvidia-h264 для аппаратного декодирования H.264 на GPU Nvidia. Если ваша камера выдает H.265, замените на preset-nvidia-h265 (RTX 3050 аппаратно поддерживает и тот, и другой кодек). Роли detect и record означают, что мы используем один и тот же поток и для детекции объектов, и для записи. (При наличии у камеры второго, субпотока низкого разрешения, можно отправлять его на детектор, а основной – только на запись. Для простоты здесь оба роли на одном потоке.)
detect – параметры детекции для этой камеры. Важно указать реальное разрешение видеопотока (width и height), чтобы Frigate знал, какого размера кадры ожидать. Параметр fps ограничивает скорость анализа – 5 кадров/с обычно достаточно для уверенного определения движения и объектов, не тратя лишние ресурсы. Если поставить слишком высокий fps, будете зря грузить и GPU, и CPU (обработка видео).
record – включает запись видео. В данном случае настроена непрерывная запись только при движении (так работает Frigate по умолчанию при включенном режиме recordings с events): при обнаружении события он сохранит сегмент видео, начиная за pre_capture секунд до события и заканчивая через post_capture секунд после. Мы сохраняем записи 7 дней (параметр retain.days). Длительность и поведение записей можно гибко менять, но выходят за рамки данной статьи.
snapshots – включает сохранение снимков с обнаруженными объектами. Frigate сделает и сохранит кадр с пометкой (рамкой) каждого события. Также храним 7 дней для примера.
После прописывания конфигурации, сохраняем config.yml и перезапускаем контейнер Frigate (docker compose restart frigate). Зайдите в веб-интерфейс (порт 5000) – там должна появиться ваша камера. Если всё сделано правильно, поток видео будет идти плавно, а при появлении в кадре людей, машин или других объектов – они выделятся рамками с подписью класса и процентом уверенности. Также в разделе Events начнут появляться записи с событиями движения.
💡 Примечание: По умолчанию Frigate отслеживает только объект person (человек). Чтобы детектировать другие типы (авто, питомцев и пр.), нужно явно добавить их в настройках. В нашем примере мы сразу использовали модель, обученную на 80 объектах COCO, поэтому рекомендуется дополнительно указать в конфиге список объектов, которые вам интересны, например:
objects:
track:
- person
- car
- cat - dog
Иначе Frigate может игнорировать всё, кроме людей.
6. Первые грабли: ошибки и уроки
Как ни старайся, а без косяков настройка не обходится. Расскажу о своих “граблях” – возможно, сберегу чьи-то нервы:
Грабли №1: Забытый драйвер NVIDIA. Я так увлёкся пробросом GPU, что при первом запуске контейнеров увидел в логах Frigate: "no CUDA capable device found". Оказалось, внутри Ubuntu я не доустановил драйвер (думал, в образе Frigate уже всё есть – но образ-то видит только /dev/nvidia*, а драйвер – это модуль ядра!). Пришлось экстренно ставить apt install nvidia-headless-525 и перезапускать VM. После этого nvidia-smi появился, и Frigate успешно подхватил GPU. Вывод: не забываем про драйвер в гостевой ОС.
Грабли №2: Неправильный образ Frigate. Сначала по привычке потянул blakeblackshear/frigate:stable (обычный). Он, конечно, запустился, но тут же завалил CPU – ведь модель детекции работала на процессоре. Я-то ждал, что GPU поможет, ан нет – нужно же tensorrt версия! Ошибка быстро нашлась, контейнер переключил на stable-tensorrt, но потерял час на скачивание нового образа (~6 ГБ). Вывод: используйте правильный тег образа для вашего ускорителя.
Грабли №3: Мало памяти. Я сперва дал VM только 4 ГБ RAM, думал “для Linux хватит”. И правда, Frigate себе брал ~500 МБ, ffmpeg чуть, да система ~1Гб – норм. Но стоило включить semantic_search, как память улетела в своп. Модель CLIP (даже small) + база данных + кэш – жрали около 6 ГБ. Добавил до 12 ГБ – стало лучше, но при старте LLaVA всё равно подпёрло. В итоге 16 ГБ — впритык, но хватает (пиково видел 12 ГБ usage при описании сразу нескольких кадров). Вывод: не жалейте RAM, лучше с запасом. Если у вас 8 ГБ или меньше – или не включайте эти фичи, или готовьтесь к тормозам.
Грабли №4: Долгая генерация описаний. Первые попытки с LLaVA 13B иногда не давали результата: событие проходит, а описания нет. Оказалось, таймаут 60 сек и конкурентные запросы. Если, например, 3 события одновременно, Frigate кидает 3 запроса, а Ollama (по умолчанию) обрабатывает их последовательно. В результате последний может не уложиться в минуту и Frigate его бросит. Решение простое: я ограничил частоту детекций (FPS 5, плюс задержка между детектами по настройкам Frigate), и в реальной жизни редко более 1 объекта сразу появляется. Так что проблема минимизировалась. Вывод: не перегружайте GenAI запросами, это не real-time штука.
Конечно, были еще мелочи, но перечислил основные, над которыми повозился. К счастью, сообщество Frigate активное: многие вопросы находил на Github Discussions и Reddit. Стоило погуглить ошибку – почти всегда кто-то уже спрашивал, и либо автор (Blake Blackshear), либо другие пользователи помогали с советом.
Краткий чек-лист по настройке для Лиги Лени
Ниже я свёл основные шаги и настройки в короткий список. Если решитесь повторить подобное у себя, пройдитесь по чек-листу – всё ли учтено:
Proxmox и железо: убедиться, что включен IOMMU/VT-d в BIOS. Прописать в /etc/default/grub нужные опции (intel_iommu=on или amd_iommu=on). Добавить видеокарту в vfio (в Proxmox /etc/modprobe.d/blacklist.conf добавить blacklist nouveau и blacklist nvidia, а в /etc/modules загрузить модули vfio). Перезапустить хост.
Создание VM: UEFI BIOS (OVMF), Machine type q35, vga: none, добавить устройство PCIe (GPU и связанный с ним аудиоконтроллер). Дать достаточное RAM (не меньше 8 ГБ, лучше 16). CPU type host, cores – по потребности. Диск – побольше под видео или подмонтировать сетевой/NAS.
Установка гостевой ОС: Поставить Ubuntu 22.04 (или Debian 12) внутри VM. Обновить систему. Установить NVIDIA драйвер (рекомендуемый проприетарный). Проверить nvidia-smi.
Подготовка Docker Compose: Создать docker-compose.yml с двумя сервисами – frigate и ollama (см. пример выше). Убедиться, что указан правильный image для Frigate (stable-tensorrt) и runtime: nvidia для обоих. Настроить volume и порты. Добавить tmpfs и shm.
Конфиг Frigate: Написать config.yml. Обязательные секции: detectors (указать type: tensorrt), model (путь к файлу .trt модели и размеры), cameras (вставить RTSP ссылки, роли, параметры детектора, объекты, маски и т.д. как нужно). При необходимости – mqtt (если использовать MQTT), detect общие настройки (например, максимальное количество одновременно отслеживаемых объектов, я не менял, по дефолту ок).
Запуск Compose: docker-compose up -d. Проверить логи: docker logs frigate -f – должны появиться сообщения о старте, подключении камер, инициализации детектора без ошибок. docker logs ollama -f – убедиться, что API запущен (может висеть в ожидании запросов).
Первый тест: Зайти в веб-интерфейс Frigate – http://<IP_VM>:8971. Создать пользователя/пароль (первый запуск). Увидеть камеры (должны отображаться превью потоков). Помахать рукой в зону видимости – убедиться, что событие фиксируется, появляется bounding box "person" на видео.
Проверка AI-описаний: Открыть вкладку Explore в UI Frigate. Найти последнее событие с объектом, посмотреть – появляется ли под ним текстовое описание. Если нет – проверить docker logs frigate на наличие ошибок GenAI (возможно, проблема с подключением к Ollama).
Оптимизация: Поправить пороги, маски, fps, если слишком много/мало срабатываний. Оценить загрузку: nvidia-smi – посмотреть, сколько памяти занято, нагрузка (Decoder, Encoder, Compute). docker stats – нет ли контейнеров с зашкаливающим CPU (в идеале CPU низкий, GPU берёт нагрузку).
Оповещения: Настроить желаемый способ уведомлений – MQTT, Home Assistant, Telegram-бот или просто email. Для Telegram: создать бот через BotFather, получить токен, написать скрипт (либо использовать готовые интеграции, например, Home Assistant Notify).
Резерв: Настроить автозапуск Compose при перезагрузке (можно через restart: unless-stopped уже сделано, но сам Docker должен стартовать; на Ubuntu это по умолчанию). Резервное копирование конфигов и, возможно, базы Frigate (файл frigate.db – содержит события и embeddings).
Мониторинг: Желательно настроить мониторинг дискового пространства (чтобы видеоархив не переполнил диск). Frigate умеет удалять по retain настройкам, но на всякий случай.
Обновление: Следить за апдейтами Frigate. Например, подписаться на релизы в GitHub или форум. Обновлять образ и конфиг по необходимости.
Фух, внушительный список. Но когда делаешь по шагам, всё не так страшно.
Выводы
Проект удался: я получил умную систему видеонаблюдения, которая работает полностью локально и не уступает во многом облачным аналогам. Frigate 0.15 приятно удивил функционалом: поиск по описанию действительно находит нужные кадры, и больше не нужно пролистывать часы записи в надежде увидеть, когда приходил почтальон. Достаточно вбить пару слов.
Конечно, за всё платим ресурсами: RTX 3050 не скучает – где-то 50–60% её вычислительной мощи постоянно в деле (детекция + AI). Электричество тоже тратится, но я посчитал: в простой мой сервер потребляет ~50 Вт, под нагрузкой ~120 Вт. За возможности, которые я получил, меня это устраивает.
Зато никакой абонентской платы сервисам и никаких проблем с приватностью. Все видеоданные остаются дома, в зашифрованном хранилище. Да и просто это было весело – настроить кучу технологий воедино: Docker, AI, FFmpeg, MQTT, etc.
Что дальше? Буду играться с более продвинутыми моделями (может попробую YOLO-NAS – хвалят за точность). Также подумываю прикрутить распознавание лиц (есть же локальные модели типа InsightFace), но это уже другая история. Frigate пока распознаёт только тип объектов, а не кто именно. Но с помощью дополнений и Home Assistant можно и это реализовать, если очень надо.
Буду благодарен за ваше участие, и планирую писать ещё =)
Например, в следующей статье могу рассказать об автоматическом управлении котлом отопления через Home Assistant и Node-Red.
Картинка для затравки:
P.S.
Т.к. на пикабу до сих пор не прикрутили нормальных код-сниппетов, прикрепляю репозиторий c конфигами из статьи.
Будут вопросы - задавайте, отвечу по мере возможности =)
Добавил поиск по базе видеособытий. Теперь ИИ нам изучит записи за указанный период и сделает общий обзор. Запрашивать можно полностью в свободной форме. Просить уделить внимание отдельным деталям. Примеры на видео:
Это было кастомное тяпляп решение для видеорегистрации событий и отправки в телегу. Софтина честно отработала год и почти не вылетала. Но пришло время всё нафиг переписать с нуля.
Коротко, что это и для чего:
У меня в доме стоит несколько камер наблюдения, сначала я использовал стандартные системы, они работают хорошо, но я не охранник чтобы сидеть постоянно и смотреть в экран, зато телефон у меня всегда под рукой, а в нем телега. Поэтому решил написать свой софт который будет писать с камер только реальные события, только нужные мне объекты и не будет срабатывать на всякий шум вроде дождей, ветра солнца итд. Я в курсе что есть Frigate NVR, Blue Iris и прочие крутые системы наблюдения. Но мне хотелось своё, простое, где можно быстро что то исправить и настроить для себя.
Прошлая моя прога использовала в качестве детектора объектов Codeproject AI (https://codeproject.github.io/) сервер. В новой я оставил опционально поддержку cai, но основная детекция происходит в коде с помощью ultrlytics yolo11.
Помимо детекции объектов была добавлена ИИ аналитика, с использованием GPT (Google Gemini модели, понадобится VPN).
Как это работает:
Вы пишете обычным русским языком: - "пришли мне уведомление если увидишь мужика с мороженным", или "на видео мерседес", и будете получать только то что конкретно интересует. Кроме того по окончании записи видеокуска, ИИ сделает аннотацию видео, запишет всё что видит. Цвет модель номера, в какой одежде и кто что делает. Затем это можно использовать для поиска событий. Например если на видео ограбление или другая подозрительная активность - это будет описано обычным языком.
Ну ладно хватит текста, пора картинки показать :)
На сервере прога выглядит незатейливо, но это уже не просто консоль.:)
На видео мы видим как соседский падла-кот метит мою машину. Разработка автоматической антикошачей турели это следующий проект :))
Дальше пример поиска в свободной форме по метаданным.
У машины номер 673 но видимость плохая, и номер плохо распознался, бывает:)
Распознавание авто номеров самодельное, обучал модель на своих данных, распознает только обычные белые номера, если нужно серьёзное распознавание, либо вам нужно тренировать свою модель, либо использовать Codeproject ai
Теперь к технической части: Програ работает строго на в Windows. Линукса не будет.
Есть две версии программы для CPU и для GPU (CUDA), при желании прогу можно масштабировать на разные GPU итд, у меня работает на mini PC с процом 7840hs, без проблем тянет 10 камер (фпс для детекции установлен 1-5 кадров, больше не надо).
Сообщения прикреплены, сначала скачать большой пак, затем последнее обновление, там только экзешник и ещё мелкие файлы. Их просто закинуть в папку с прогой.
Знаю как все не любят ссылку на телегу, но в данном случае это оправдано, поскольку прога работает с телегой если у вас нет tg то и прога не нужна. Во вторых это не канал для накруток и прочего, а просто канал где можно обсудить детали и спросить.
К главному:
Софтина сырая, не смотря на переделку она всё ещё является наколеночным софтом, который не гарантирует работоспособность и потребует от вас умения, терпения, базовых знаний json, винды итд. В папке examples лежит ридми файл где я на пальцах как мог объяснил о настройках. Документация есть тут: https://telegra.ph/Cam100Gram-opisanie-nastroek-02-24
PS: Не использовать для наблюдения в бане, а если использовать то делиться результатами со всеми :)
