Как не утопить RTSP в YOLO: real‑time‑конвейер на C++20, Clang и ONNX Runtime

Значимый прорыв формирует отрасль ИИ: alex-video-analytics 14 минут назад Объяснить с Как не утопить RTSP в YOLO: real‑time‑конвейер на C++20, Clang и ONNX Runtime Средний 10 мин 380 Высоконагруженные системы * C++ * Машинное обучение * Работа с видео * Кейс Из песочницы Привет, Хабр! Меня зовут Александр Кудряшов. Более тридцати лет я занимаюсь разработкой систем цифровой обработки сигналов, аудио и видео.

В последнее время я создаю собственную платформу видеоаналитики и сравниваю её серверные реализации на C++, Python и Rust. Это моя первая статья: в ней хочу поделиться не обзором готового продукта, а одной конкретной инженерной задачей, возникшей при его разработке. YOLO обрабатывает кадр дольше, чем камера формирует следующий.

Технические детали

Если построить видеосервер как последовательность read → motion → YOLO → encode, тяжёлая модель остановит чтение RTSP, очередь начнёт расти, а пользователь увидит не прямой эфир, а прошлое. В этой статье я разбираю конвейер своего сервера видеоаналитики на C++20. Его основная идея проста: для real‑time‑системы свежесть часто важнее полноты, поэтому между этапами нужны не бесконечные очереди, а ограниченные слоты последнего значения.

Покажу, как это сочетается с std::jthread, std::stop_token, OpenCV, ONNX Runtime и защитой от запоздавших результатов. Браузерный Viewer: RTSP‑кадр 2304×1296, области анализа, сопровождение целей и результаты YOLO. В строке состояния отображаются FPS сервера и клиента, потери, очередь и число перезапусков RTSP.

Постановка задачиСервер получает RTSP‑поток с камеры и одновременно должен:непрерывно читать и декодировать видео;обнаруживать движение и сопровождать цели;выполнять полнокадровый YOLO;дополнительно распознавать небольшие области сопровождаемых объектов;формировать JPEG‑preview и HLS;записывать события в PostgreSQL;по запросу сохранять исходный поток в MP4;оставаться доступным через REST API. Камера в моём тесте выдавала примерно 14 кадров/с. Один полнокадровый YOLO‑проход на CPU занимал около 1,7 с.

Отраслевые последствия

За это время приходило больше двадцати новых кадров. Если складывать их в обычную FIFO‑очередь, система гарантированно отстанет от реального времени. Увеличение очереди только откладывает момент, когда память закончится или задержка станет неприемлемой.

Поэтому сначала пришлось сформулировать контракт:Захват видео не ждёт аналитику. Медленный этап обрабатывает самый свежий доступный кадр, а устаревшие кадры допускается заменять. Это не универсальное правило.

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

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.