Разработка системы трекинга объектов на видео (Object Tracking) под ключ

Почему трекинг объектов срывается на реальном видео

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

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

Отдельная история — потеря объекта в кадре: она почти никогда не совпадает с моментом исчезновения. Сопровождение срывается за секунды до него, когда объект замедляется, меняет направление или сливается с фоном. По отраслевым наборам вроде MOT Challenge видно, насколько лабораторное качество расходится с боевым: разница в доле верных идентификаторов измеряется десятками процентов.

Считается это не картинкой, а событиями. Разорванная траектория либо превращается в лишнее срабатывание, либо теряет событие целиком, и решение принимается по неполной картине. Дальше разбираем, как это закрывается: от выбора модели под конкретную сцену до логики сопоставления и проверки траекторий.

Что даёт система видеоаналитики: измеримые эффекты

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

Меньше пропусков объектов

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

Устойчивость к перекрытиям

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

Слабый свет и ночные смены

Ночью часть кадра теряется из-за шума и засветки, поэтому настраиваем предобработку кадра и режим подсветки. Если сцена физически не покрывается, система помечает зону как непокрытую, а не выдаёт ложные события.

Способы трекинга объектов: сравнение и ограничения

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

Как выбираем режим под сцену

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

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

Как мы внедряем видеоаналитику: этапы работ

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

1. Аудит видеоархива. Смотрим записи с каждой камеры в разные часы и при разной погоде: пересветы, взаимные перекрытия, дрожание кадра. На выходе — перечень камер с устойчивой картинкой и точки, где нужна правка расстановки.
2. Разметка сцен. Отмечаем целевые объекты, ложные цели и проблемный фон: блики, тени, отражения в витринах, движение веток. Пропуск шага оборачивается переобучением уже после запуска.
3. Калибровка зон контроля. Линии и области привязываем к реальной геометрии площадки, а не к пикселям — при сдвиге камеры зона остаётся корректной. Проверяем, что объект не «прыгает» между зонами на границе.
4. Настройка порогов срабатывания. Подбираем время нахождения в зоне, минимальный размер объекта и число подтверждающих кадров: уходят срабатывания на пролетающую птицу и на прохожего рядом с зоной.
5. Проверка на исторических записях. Прогоняем готовую конфигурацию по архиву за разные смены и считаем долю ложных событий и пропусков, а не оцениваем «на глаз».
6. Приёмка системы. Замеряем точность на живом потоке в часы пик и фиксируем показатели в протоколе. Передаём регламенты: как добавить камеру, обновить зону, разобрать спорное событие.

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

Состав поставки: конфигурации, схемы зон, регламенты

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

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

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

Кейс: сократили ложные срабатывания на складе втрое

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

Что было до внедрения

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

Что изменили и что получили

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

За первый месяц эксплуатации: ложные срабатывания упали с 40+ до 12–14 за смену, доля пропущенных нарушений — ниже 2%, задержка от события до сигнала оператору — 1–2 секунды. Журнал треков хранится 30 дней, поэтому спорный случай разбирается по фрагменту с идентификатором, а не по вырванному кадру.

Что делать, если камеры и архив уже развёрнуты?

Менять парк камер не нужно. Аналитика подключается к тем потокам, которые камеры и регистраторы уже отдают в сеть, поэтому запись продолжает идти своим ходом, а трекинг работает параллельно на отдельном вычислительном узле и ничего не перехватывает в существующей схеме.

Ключевой момент — разделение потоков. Трекинг забирает поток пониженного разрешения и работает по нему, а поток основного качества остаётся на запись в архиве, поэтому качество и глубина хранения не проседают. Если камера не отдаёт отдельный поток, аналитику ставят на копию основного через отдельный сетевой интерфейс, чтобы видеорегистратор не терял кадры. Разные производители камер и регистраторов сводятся к единому входу через профили совместимости ONVIF, а для закрытых моделей поток снимается прямо с регистратора — так решение не привязывается к одной марке оборудования.

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

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

Частые технические вопросы и ограничения

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

Что со слабым освещением и перекрытиями?

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

Нужно ли менять камеры на объекте?

Как правило нет: работаем с потоком, который уже отдают камеры заказчика по открытым стандартам, а на слабых моделях оцениваем достаточность качества съёмки до подписания. Узкие места по обзору фиксируем в отчёте по обследованию, чтобы не выяснять их на приёмке.

Кто отвечает за ложные срабатывания?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Этого достаточно, чтобы посчитать нагрузку и собрать план внедрения под ваш контур — без долгой переписки и предположений наугад.

В ответ вы получаете пакет, по которому можно принимать решение:

• Техническую оценку: достижимую точность сопровождения на ваших записях, узкие места сцены (перекрытия, плотный поток, ночь), классы отказов и что с ними делаем.
• План внедрения с этапами, порядком работ и точками, где вы принимаете результат.
• Границы работ: что входит в нашу зону, а что остаётся на вас или на подрядчике по камерам и серверам.
• Схему потоков данных — от захвата кадра до события в вашей учётной системе.
• Требования к съёмке и площадке, если часть проблем решается настройкой камер, а не кодом.
• Критерии приёмки: показатели, по которым мы вместе проверим результат на записях, не участвовавших в настройке.

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