Чому детекція об'єктів на відео впирається в затримку
У конвеєрі детекції об'єктів на відео вузьке місце майже ніколи не в самій моделі. Декодер віддає кадри з постійною частотою, а обробка кадру триває зі змінним часом: сцена ускладнилася, об'єктів у кадрі побільшало — і час на кадр зріс.
Різниця накопичується в черзі кадрів, і за кілька хвилин система аналізує те, що відбувалося на майданчику хвилину тому.
Переповнення черги кадрів — перше, що видно в метриках: буфер упирається в межу, і далі потрібна усвідомлена політика.
Якщо відкидати старі кадри, детекція йде за свіжими, але рветься безперервність треку об'єкта; якщо нові — зростає затримка виведення результату, і оператор бачить минуле. За відсутності явного правила рішення ухвалює бібліотека, і зазвичай це не те правило, яке потрібне задачі.
Пікове навантаження добиває картину: кілька потоків із камер стартують одночасно, і просідання на кількох потоках додається, а не усереднюється.
Пропуск кадрів за пікового навантаження — це не просто падіння точності: частина подій залишається непоміченою, і розбирати їх доводиться постфактум за записом, якщо він узагалі зберігся в достатній якості.
Звідси й вимоги: затримка має бути передбачуваною, а поведінка під навантаженням — заданою заздалегідь, а не з'ясованою на інциденті.
Розбираємо, як це закривається: як ділити ресурси між потоками, де свідомо різати роздільну здатність і частоту, які метрики дивитися, щоб відставання не накопичувалося.
Що дає перебудова конвеєра детекції
Перебудова конвеєра обробки потоку — це не заміна моделі, а розділення роботи на незалежні етапи: приймання й декодування, виведення моделі, трекінг, запис архіву.
У кожного етапу своя черга й свій ресурс, тому зростання кількості камер перестає обвалювати загальну пропускну здатність.
Розподіл навантаження між вузлами
Інференс на TensorRT винесено в окремий пул від декодування й постобробки, і масштабуються вони незалежно. Переповнення однієї черги більше не зупиняє решту: зайві кадри відкидаються за пріоритетом, а не накопичуються в буфері.
Частка кадрів, втрачених через переповнення, прямує до нуля, а вузьке місце видно за метриками, а не вгадується.
Стабільна затримка під навантаженням
Глибина черг обмежена, пріоритет віддано свіжому кадру: під піком система пропускає застарілі кадри замість їх накопичення. Затримка на видачі залишається в тому самому коридорі за подвоєння кількості потоків — оператор бачить подію, поки вона ще актуальна.
Запас за кількістю потоків
Пропускну здатність вимірюють заздалегідь, на тестовому профілі: видно, скільки камер тримає один вузол і в який момент потрібен другий.
Підключення нового потоку не потребує переписування логіки — розширюється лише пул обробників, тому запас планується, а не з'ясовується в момент запуску.
Усунений клас відмов
Раніше падіння одного процесу зупиняло весь конвеєр; тепер етапи ізольовані, і перезапуск триває секунди без втрати архіву. Окремо пішов клас відмов, пов'язаний із витоками пам'яті в довгих сесіях: обробник перестворюється за регламентом, а не за фактом зупинки.
Режими обробки потоку: пакетний, потоковий, гібридний
Режим обробки потоку вибирають не за смаком, а за тим, що відбувається з кадром після детекції: чи йде він в архів, чи чекає рішення оператора, чи одразу запускає дію.
Від цього залежить, де стоїть черга кадрів, скільки потрібно прискорювачів виведення і яка затримка виникає між подією та реакцією системи.
| Варіант | Коли підходить | Обмеження режиму |
|---|---|---|
| Пакетна обробка архіву | розбір записів за минулий період, зведення, пошук порушень за вже знятим матеріалом | подія виявляється із запізненням — реакція в момент того, що відбувається, неможлива |
| Обробка в реальному часі | контроль зон і реакція на подію в момент її появи | черга кадрів не повинна зростати: за нестачі обчислювальних ресурсів кадри починають губитися |
| Гібридна схема з периферійним вузлом | багато камер, слабкий або перевантажений канал зв'язку до центру | межі задає сам периферійний вузол — його ресурси й складність оновлення моделей |
Як вибрати режим під задачу
Рахуйте не кількість камер, а вимоги до затримки й повноти. Якщо результат потрібен за записаним матеріалом, пакетний режим дає рівномірніше завантаження прискорювача й дозволяє ставити моделі, які не вкладаються в темп живого потоку.
Коли подія потребує дії тієї ж секунди, беруть потоковий режим і заздалегідь визначають політику відкидання кадрів.
Перехід між режимами
Режими не взаємовиключні: той самий конвеєр обслуговує живий потік і за розкладом добирає архів на тих самих моделях. Змінюється лише джерело кадрів і пріоритет черги — за перевантаження частина кадрів іде в пакетний розбір, а не губиться. Так перехід на новий режим не потребує переписувати логіку детекції.
Як проходить впровадження: від аудиту потоку до передачі
Впровадження розбито на короткі етапи, і кожен закінчується перевірюваним артефактом — звітом, схемою або конфігурацією. Починаємо не з вибору моделі, а з розбору того, що реально приходить із камер і які події потрібно фіксувати.
- Аудит відеопотоку й сценарію. Дивимося кодеки, роздільну здатність, нічне знімання, перекриття й сліпі зони, поведінку об'єкта на межі кадру. Тут же фіксуємо перелік класів і допустиму частку пропусків — це майбутні рамки приймання.
- Схема розміщення обробки. Вирішуємо, що рахуємо на камері, що на локальному вузлі, що в центрі: де затримка критичніша, де дешевший канал, де система має пережити обрив зв'язку.
- Налаштування конвеєра. Складаємо ланцюжок декодування, детекції й трекінгу, пороги чутливості задаємо під кожен сценарій окремо, важкі потоки переводимо в пріоритет.
- Калібрування на архівних записах. Проганяємо еталонні фрагменти, рахуємо точність і повноту за класами та правимо пороги до узгоджених значень.
- Приймання на реальному потоці. Прогін на бойових камерах у робочі години, включно з піковими сценами й ніччю.
- Передача системи й навчання. Віддаємо конфігурації, схему розміщення й регламент обслуговування, навчаємо операторів і супроводжуємо перші тижні експлуатації.
Що вважається прийманням
Приймання йде не за демо-роликом, а за добовим прогоном на бойових камерах у робочі години. Рахуємо частку правильних спрацювань, кількість хибних тривог на камеру за добу й затримку від події до повідомлення — за цими числами етап і закривається.
Змішаний парк камер
Камери різних поколінь віддають потік по-різному, частина джерел слабша за інші. Для них знижуємо роздільну здатність аналізованого кадру або переносимо обробку на локальний вузол — змінювати парк не потрібно.
Що передаємо на руки: конфігурації, схеми, регламенти
Систему передаємо не як «у нас працює», а як відтворюваний контур: чергова зміна піднімає її на чистому вузлі за документом, без листування з авторами. Що входить у постачання:
- Конфігурації конвеєра: декодування, розмір батчу, пороги впевненості й трекінгу — в одному версіонованому файлі, правки застосовуються перезапуском без перезбирання образу.
- Схема потоків і вузлів: звідки приходить відео, де інференс, де сховище подій і метаданих, через що тривоги йдуть у суміжні системи.
- Матриця доступів і ролей: хто змінює пороги, хто перезапускає сервіс, хто лише читає архів; окремо — сервісні облікові записи для камер і черг.
- Регламент експлуатації: порядок запуску й зупинки, перевірка живості потоків, поведінка при обриві зв'язку з камерою — перепідключення з наростаючою паузою замість шторму запитів.
- Інструкції з чергування й розбору інцидентів: типові відмови, що дивитися першим, що ескалувати й у який термін.
- Скрипти розгортання й перевірний прогін на еталонному записі — приймання відтворюване, а не «на слово».
Склад документації на систему
Архітектурний опис вузлів, довідник за кожним параметром конфігурації з допустимими межами, керівництво з оновлення з процедурою відкату на попередній реліз, а також журнал змін — щоб за півроку було видно, чому пороги стоять саме такі.
Кейс: втрати кадрів у пікові години — що змінилося
На виробничому об'єкті детекція об'єктів на відео працювала в одному процесі із записом архіву, і в пікові години конвеєр переставав встигати за потоком.
Про збої дізнавалися за розходженням із записами, а не за оповіщеннями, тому вимірювання робили вже на накопичених даних за тиждень.
Початкова картина: де губилися кадри
Частка пропущених кадрів у пікові інтервали сягала 9–12%, а розкид затримки між кадрами різнився в рази: детектор то відпрацьовував миттєво, то відставав.
Хибні спрацювання давали близько третини тривог, а після падіння процесу сервіс піднімали вручну — час відновлення після збою вимірювався десятками хвилин і залежав від чергового.
Вимірювання після впровадження
Конвеєр рознесли на незалежні ступені — захоплення, інференс, постобробка — з чергами фіксованої глибини та скиданням застарілих кадрів замість накопичення.
Інференс перевели на актуальну гілку TensorRT з приведенням вхідних тензорів до єдиного формату, а пороги детектора відкалібрували на записах самого об'єкта, а не на публічних наборах.
Повторні вимірювання в ті самі пікові години: пропуски кадрів — частки відсотка, розкид затримки скоротився приблизно втричі, кількість хибних спрацювань упала на дві третини.
Відновлення після збою стало автоматичним — ступінь перезапускається без участі чергового, аналітика й архів не перериваються.
Що робити, якщо модель уже розгорнута, але не тримає навантаження?
Якщо модель уже розгорнута і результат є, але навантаження вона не тримає, причина частіше не у вагах, а в контурі навколо них: препроцесинг на процесорі, синхронні виклики, зайві копіювання кадрів, відсутність пакетної обробки.
Перший крок — первинні вимірювання: розкладаємо час на декодування, препроцесинг, виведення моделі, постобробку й відмальовування, дивимося заповнення черг і частку відкинутих кадрів.
За цими числами видно, що перевикористовуємо, а що перебудовуємо.
Йдемо через доопрацювання замість переробки: зберігаємо ваги, розмітку, контракти обміну й сховище результатів, змінюємо обв'язку — препроцесинг переходить на прискорювач, з'являється асинхронний конвеєр з обмеженою чергою та витісненням застарілих кадрів, пакет збирається за таймаутом.
Виведення прискорюємо на TensorRT: збираємо движок під конкретний пристрій і профілюємо шари, перебудовуючи найдорожчі ділянки мережі. Якщо впираємося в затримку, а не в повноту, частину кадрів пропускаємо усвідомлено — політика залежить від задачі.
Порядок робіт за кроками: вимірювання й профіль, потім правки контуру — черги, пакети, пам'ять, потім заміна середовища виконання і лише після цього полегшення моделі: квантування або дистиляція.
Черговість залежить від доступу до потоку до кодування і від того, потрібна детекція на всіх камерах чи на частині.
Новий контур піднімаємо поруч зі старим і перемикаємо трафік за камерами: порівняння йде на живих даних, відкат займає хвилини.
Точність, хибні спрацювання й підтримка: часті сумніви
Збираємо питання, які найчастіше виринають на захисті проєкту перед запуском. Відповідаємо по суті й без обіцянок «ідеальної точності» — на реальному об'єкті поведінку системи визначають шум у кадрі, якість мережі та вже змонтовані камери.
Як рахується точність і скільки буде хибних спрацювань?
Ми не показуємо одне усереднене число, а розбиваємо результат за класами й умовами знімання: день, ніч, дощ, контрове світло. У звіті фіксуємо дві метрики — частку пропущених подій і кількість хибних спрацювань за зміну.
Поріг упевненості виставляємо під вашу задачу: десь важливіше не пропустити, десь — не піднімати оператора через дрібниці.
Чи підійдуть камери, які вже встановлені?
Підключаємо наявний парк і перевіряємо його до старту: ракурс, висота, реальний потік із камери. Якщо модель фізично не дає потрібної картинки або точка стоїть у сліпій зоні — говоримо про це заздалегідь і пропонуємо місця, де заміна або доворот дасть ефект. Мовчки будувати систему на непридатних даних не будемо.
Що відбувається при обриві зв'язку або перезапуску вузла?
Вузол обробляє потік локально й продовжує детекцію без зовнішнього каналу. Кадри за час зникнення зв'язку йдуть у локальний буфер, після відновлення він розбирається — події не губляться.
При перезапуску живлення вузол піднімається сам, стан детекції відновлюється з локального журналу, ручне втручання не потрібне.
Чи можна донавчити модель на наших даних?
Так, і зазвичай це обов'язковий етап. Первинна модель навчається на відкритих наборах, далі — на ваших записах з об'єкта. Розмітку ведемо за спірними кадрами, де система сумнівається, тому цикл донавчання короткий. Нова версія потрапляє на об'єкт лише після перевірки на відкладеній вибірці.
Як перевіряється якість після передачі?
Віддаємо не лише модель, а й відтворюваний набір перевірок: тестові сцени, очікуваний результат, порядок прогону. Ви можете прогнати його самі будь-якої миті й побачити, де рішення просіло. Це ж слугує точкою відліку, коли на об'єкті змінюється освітлення або додаються камери.
Обговоримо задачу: надішлемо оцінку та план робіт
Щоб оцінка була реалістичною, а не «середньою по ринку», потрібен мінімум контексту. Нижче — дані для оцінки, які зазвичай надсилають на старті: цього достатньо, щоб порахувати склад робіт і порядок етапів без уточнювальних раундів на тиждень.
Якщо частина відомостей поки невідома — так і напишіть, закладемо припущення й перевіримо їх на першому етапі.
- Сценарій і мета: що детектуємо і де рішення ухвалює людина, а де потрібна автоматична реакція.
- Відеопотоки: кількість камер, їхній тип — стаціонарні, поворотні, реєстратори, — чи є нічне знімання й слабка освітленість.
- Де живе архів і як віддається потік: локальний реєстратор, мережеве сховище або хмара, за якими стандартними протоколами відеоспостереження.
- Вимоги до швидкості реакції: допустима затримка між подією й сигналом і що відбувається далі — журнал, повідомлення оператору, виклик зовнішньої системи.
- Обмеження щодо розміщення: закритий контур без виходу в інтернет, сервери замовника або хмара, вимоги до зберігання персональних даних.
- Приклади записів і розмітка: чи є вже відзняті фрагменти, які класи об'єктів важливі й що вважається хибним спрацюванням.
У відповідь надсилаємо оцінку зі складом робіт, план за етапами — від підготовки даних і навчання моделі до перевірки на вашому об'єкті — і метрики приймання: повнота виявлення, частка хибних спрацювань, затримка сигналу. Обговоримо задачу — повернемося з оцінкою та планом.
