Почему детекция объектов на видео упирается в задержку
В конвейере детекции объектов на видео узкое место почти никогда не в самой модели. Декодер отдаёт кадры с постоянной частотой, а обработка кадра идёт с переменным временем: сцена усложнилась, объектов в кадре стало больше — и время на кадр выросло. Разница копится в очереди кадров, и через несколько минут система анализирует то, что происходило на площадке минуту назад.
Переполнение очереди кадров — первое, что видно в метриках: буфер упирается в предел, и дальше нужна осознанная политика. Если выбрасывать старые кадры, детекция идёт по свежим, но рвётся непрерывность трека объекта; если новые — растёт задержка вывода результата, и оператор видит прошлое. При отсутствии явного правила решение принимает библиотека, и обычно это не то правило, которое нужно задаче.
Пиковая нагрузка добивает картину: несколько потоков с камер стартуют одновременно, и просадка на нескольких потоках складывается, а не усредняется. Пропуск кадров при пиковой нагрузке — это не просто падение точности: часть событий остаётся незамеченной, и разбирать их приходится постфактум по записи, если она вообще сохранилась в достаточном качестве.
Отсюда и требования: задержка должна быть предсказуемой, а поведение под нагрузкой — заданным заранее, а не выясненным на инциденте. Разбираем, как это закрывается: как делить ресурсы между потоками, где сознательно резать разрешение и частоту, какие метрики смотреть, чтобы отставание не накапливалось.
Что даёт перестройка конвейера детекции
Перестройка конвейера обработки потока — это не замена модели, а разделение работы на независимые этапы: приём и декодирование, вывод модели, трекинг, запись архива. У каждого этапа своя очередь и свой ресурс, поэтому рост числа камер перестаёт ронять общую пропускную способность.
Распределение нагрузки между узлами
Инференс на TensorRT вынесен в отдельный пул от декодирования и постобработки, и масштабируются они независимо. Переполнение одной очереди больше не останавливает остальные: лишние кадры отбрасываются по приоритету, а не копятся в буфере. Доля кадров, потерянных на переполнении, уходит в ноль, а узкое место видно по метрикам, а не угадывается.
Стабильная задержка под нагрузкой
Глубина очередей ограничена, приоритет отдан свежему кадру: под пиком система пропускает устаревшие кадры вместо их накопления. Задержка на выдаче остаётся в том же коридоре при удвоении числа потоков — оператор видит событие, пока оно ещё актуально.
Запас по числу потоков
Пропускная способность измеряется заранее, на тестовом профиле: видно, сколько камер держит один узел и в какой момент нужен второй. Подключение нового потока не требует переписывания логики — расширяется только пул обработчиков, поэтому запас планируется, а не выясняется в момент запуска.
Устранённый класс отказов
Раньше падение одного процесса останавливало весь конвейер; теперь этапы изолированы, и перезапуск занимает секунды без потери архива. Отдельно ушёл класс отказов, связанный с утечками памяти в длинных сессиях: обработчик пересоздаётся по регламенту, а не по факту остановки.
Режимы обработки потока: пакетный, потоковый, гибридный
Режим обработки потока выбирают не по вкусу, а по тому, что происходит с кадром после детекции: уходит ли он в архив, ждёт ли решения оператора или сразу запускает действие. От этого зависит, где стоит очередь кадров, сколько нужно ускорителей вывода и какая задержка возникает между событием и реакцией системы.
| Вариант | Когда подходит | Ограничения режима |
|---|---|---|
| Пакетная обработка архива | разбор записей за прошедший период, сводки, поиск нарушений по уже снятому материалу | событие обнаруживается с отставанием — реакция в момент происходящего невозможна |
| Обработка в реальном времени | контроль зон и реакция на событие в момент его появления | очередь кадров не должна расти: при нехватке вычислительных ресурсов кадры начинают теряться |
| Гибридная схема с периферийным узлом | много камер, слабый или перегруженный канал связи до центра | границы задаёт сам периферийный узел — его ресурсы и сложность обновления моделей |
Как выбрать режим под задачу
Считайте не число камер, а требования к задержке и полноте. Если результат нужен по записанному материалу, пакетный режим даёт более ровную загрузку ускорителя и позволяет ставить модели, которые не укладываются в темп живого потока. Когда событие требует действия в ту же секунду, берут потоковый режим и заранее определяют политику отбрасывания кадров.
Переход между режимами
Режимы не взаимоисключающие: один и тот же конвейер обслуживает живой поток и по расписанию добирает архив на тех же моделях. Меняется только источник кадров и приоритет очереди — при перегрузке часть кадров уходит в пакетный разбор, а не теряется. Так переход на новый режим не требует переписывать логику детекции.
Как проходит внедрение: от аудита потока до передачи
Внедрение разбито на короткие этапы, и каждый заканчивается проверяемым артефактом — отчётом, схемой или конфигурацией. Начинаем не с выбора модели, а с разбора того, что реально приходит с камер и какие события нужно фиксировать.
- Аудит видеопотока и сценария. Смотрим кодеки, разрешение, ночную съёмку, перекрытия и слепые зоны, поведение объекта на границе кадра. Здесь же фиксируем перечень классов и допустимую долю пропусков — это будущие рамки приёмки.
- Схема размещения обработки. Решаем, что считаем на камере, что на локальном узле, что в центре: где задержка критичнее, где дешевле канал, где система должна пережить обрыв связи.
- Настройка конвейера. Собираем цепочку декодирования, детекции и трекинга, пороги чувствительности задаём под каждый сценарий отдельно, тяжёлые потоки уводим в приоритет.
- Калибровка на архивных записях. Прогоняем эталонные фрагменты, считаем точность и полноту по классам и правим пороги до согласованных значений.
- Приёмка на реальном потоке. Прогон на боевых камерах в рабочие часы, включая пиковые сцены и ночь.
- Передача системы и обучение. Отдаём конфигурации, схему размещения и регламент обслуживания, обучаем операторов и сопровождаем первые недели эксплуатации.
Что считается приёмкой
Приёмка идёт не по демо-ролику, а по суточному прогону на боевых камерах в рабочие часы. Считаем долю верных срабатываний, число ложных тревог на камеру в сутки и задержку от события до уведомления — по этим числам этап и закрывается.
Смешанный парк камер
Камеры разных поколений отдают поток по-разному, часть источников слабее остальных. Для них снижаем разрешение анализируемого кадра или переносим обработку на локальный узел — менять парк не требуется.
Что передаём на руки: конфигурации, схемы, регламенты
Систему передаём не как «у нас работает», а как воспроизводимый контур: дежурная смена поднимает её на чистом узле по документу, без переписки с авторами. Что входит в поставку:
- Конфигурации конвейера: декодирование, размер батча, пороги уверенности и трекинга — в одном версионируемом файле, правки применяются перезапуском без пересборки образа.
- Схема потоков и узлов: откуда приходит видео, где инференс, где хранилище событий и метаданных, через что тревоги уходят в смежные системы.
- Матрица доступов и ролей: кто меняет пороги, кто перезапускает сервис, кто только читает архив; отдельно — сервисные учётные записи для камер и очереди.
- Регламент эксплуатации: порядок запуска и остановки, проверка живости потоков, поведение при обрыве связи с камерой — переподключение с нарастающей паузой вместо шторма запросов.
- Инструкции по дежурству и разбору инцидентов: типовые отказы, что смотреть первым, что эскалировать и в какой срок.
- Скрипты развёртывания и проверочный прогон на эталонной записи — приёмка воспроизводима, а не «на слово».
Состав документации на систему
Архитектурное описание узлов, справочник по каждому параметру конфигурации с допустимыми границами, руководство по обновлению с процедурой отката на предыдущий релиз, а также журнал изменений — чтобы через полгода было видно, почему пороги стоят именно такие.
Кейс: потери кадров в пиковые часы — что изменилось
На производственном объекте детекция объектов на видео работала в одном процессе с записью архива, и в пиковые часы конвейер переставал успевать за потоком. О сбоях узнавали по расхождению с записями, а не по оповещениям, поэтому замеры делали уже на накопленных данных за неделю.
Исходная картина: где терялись кадры
Доля пропущенных кадров в пиковые интервалы доходила до 9–12%, а разброс задержки между кадрами отличался в разы: детектор то отрабатывал мгновенно, то отставал. Ложные срабатывания давали около трети тревог, а после падения процесса сервис поднимали вручную — время восстановления после сбоя измерялось десятками минут и зависело от дежурного.
Замеры после внедрения
Конвейер разнесли на независимые ступени — захват, инференс, постобработка — с очередями фиксированной глубины и сбросом устаревших кадров вместо накопления. Инференс перевели на актуальную ветку TensorRT с приведением входных тензоров к единому формату, а пороги детектора откалибровали на записях самого объекта, а не на публичных наборах.
Повторные замеры в те же пиковые часы: пропуски кадров — доли процента, разброс задержки сократился примерно втрое, число ложных срабатываний упало на две трети. Восстановление после сбоя стало автоматическим — ступень перезапускается без участия дежурного, аналитика и архив не прерываются.
Что делать, если модель уже развёрнута, но не держит нагрузку?
Если модель уже развёрнута и результат есть, но нагрузку она не держит, причина чаще не в весах, а в контуре вокруг них: препроцессинг на процессоре, синхронные вызовы, лишние копирования кадров, отсутствие пакетной обработки. Первый шаг — первичные замеры: раскладываем время на декодирование, препроцессинг, вывод модели, постобработку и отрисовку, смотрим заполнение очередей и долю отброшенных кадров.
По этим числам видно, что переиспользуем, а что перестраиваем. Идём через доработку вместо переделки: сохраняем веса, разметку, контракты обмена и хранилище результатов, меняем обвязку — препроцессинг уходит на ускоритель, появляется асинхронный конвейер с ограниченной очередью и вытеснением устаревших кадров, пакет собирается по таймауту.
Вывод ускоряем на TensorRT: собираем движок под конкретное устройство и профилируем слои, перестраивая самые дорогие участки сети. Если упор в задержку, а не в полноту, часть кадров пропускаем осознанно — политика зависит от задачи.
Порядок работ по шагам: замеры и профиль, затем правки контура — очереди, пакеты, память, затем замена среды исполнения и лишь потом облегчение модели: квантование или дистилляция. Очерёдность зависит от доступа к потоку до кодирования и от того, нужна детекция на всех камерах или на части.
Новый контур поднимаем рядом со старым и переключаем трафик по камерам: сравнение идёт на живых данных, откат занимает минуты.
Точность, ложные срабатывания и поддержка: частые сомнения
Собираем вопросы, которые чаще всего всплывают на защите проекта перед запуском. Отвечаем по существу и без обещаний «идеальной точности» — на реальном объекте поведение системы определяют шум в кадре, качество сети и уже смонтированные камеры.
Как считается точность и сколько будет ложных срабатываний?
Мы не показываем одно усреднённое число, а разбиваем результат по классам и условиям съёмки: день, ночь, дождь, контровой свет. В отчёте фиксируем две метрики — долю пропущенных событий и число ложных срабатываний за смену. Порог уверенности выставляем под вашу задачу: где-то важнее не пропустить, где-то — не поднимать оператора по пустякам.
Подойдут ли камеры, которые уже установлены?
Подключаем существующий парк и проверяем его до старта: ракурс, высота, реальный поток с камеры. Если модель физически не даёт нужной картинки или точка стоит в слепой зоне — говорим об этом заранее и предлагаем места, где замена или доворот даст эффект. Молча строить систему на непригодных данных не станем.
Что происходит при обрыве связи или перезапуске узла?
Узел обрабатывает поток локально и продолжает детекцию без внешнего канала. Кадры за время пропадания связи уходят в локальный буфер, после восстановления он разбирается — события не теряются. При перезапуске питание узел поднимается сам, состояние детекции восстанавливается из локального журнала, ручное вмешательство не нужно.
Можно ли дообучить модель на наших данных?
Да, и обычно это обязательный этап. Первичная модель учится на открытых наборах, дальше — на ваших записях с объекта. Разметку ведём по спорным кадрам, где система сомневается, поэтому цикл дообучения короткий. Новая версия попадает на объект только после проверки на отложенной выборке.
Как проверяется качество после передачи?
Отдаём не только модель, но и воспроизводимый набор проверок: тестовые сцены, ожидаемый результат, порядок прогона. Вы можете прогнать его сами в любой момент и увидеть, где решение просело. Это же служит точкой отсчёта, когда на объекте меняется освещение или добавляются камеры.
Обсудим задачу: пришлём оценку и план работ
Чтобы оценка была реалистичной, а не «средней по рынку», нужен минимум контекста. Ниже — данные для оценки, которые обычно присылают на старте: этого хватает, чтобы посчитать состав работ и порядок этапов без уточняющих раундов на неделю. Если часть сведений пока неизвестна — так и напишите, заложим допущения и проверим их на первом этапе.
- Сценарий и цель: что детектируем и где решение принимает человек, а где нужна автоматическая реакция.
- Видеопотоки: число камер, их тип — стационарные, поворотные, регистраторы, — есть ли ночная съёмка и слабая освещённость.
- Где живёт архив и как отдаётся поток: локальный регистратор, сетевое хранилище или облако, по каким стандартным протоколам видеонаблюдения.
- Требования к скорости реакции: допустимая задержка между событием и сигналом и что происходит дальше — журнал, уведомление оператору, вызов внешней системы.
- Ограничения по размещению: закрытый контур без выхода в интернет, серверы заказчика или облако, требования к хранению персональных данных.
- Примеры записей и разметка: есть ли уже отснятые фрагменты, какие классы объектов важны и что считается ложным срабатыванием.
В ответ присылаем оценку с составом работ, план по этапам — от подготовки данных и обучения модели до проверки на вашем объекте — и метрики приёмки: полнота обнаружения, доля ложных срабатываний, задержка сигнала. Обсудим задачу — вернёмся с оценкой и планом.
