gx
b8661f4017
Phase 5e revisited: visual artefacts в bottom rows 16-cell grid'а оказались не race condition в cuframes ring buffer (как первоначальная гипотеза), а burstiness IDR. Сложный grid (много границ между ячейками) генерит огромные IDR (~400 КБ), которые переполняют mediamtx writeQueueSize=256 и discard'ятся → VLC видит покалеченный bitstream. Правильное решение — canonical low-latency streaming pattern: вместо периодических IDR использовать NVENC intra refresh. Вместо одного gigant'а intra-кадра раз в секунду, кодируем N столбцов intra-блоков в каждом кадре. За intra_refresh_period кадров — полный refresh. Bitstream становится почти ровным — все кадры одинакового размера, никаких spike'ов. Это индустриальный стандарт для low-latency: WebRTC, Twitch low-latency mode, GeForce NOW, Zoom — все используют intra refresh без IDR. Trade-off: новый клиент ждёт ~1 период (1 сек) для построения reference frame. Для CCTV приемлемо. ffmpeg snapshot one-shot не работает на таких потоках (нужен полный warmup), но VLC/TV/Frigate handles штатно. Содержимое: - cfc_encoder_config_t: добавлены intra_refresh + intra_refresh_period. - nvenc.c: при enableIntraRefresh=1 устанавливается intraRefreshPeriod/intraRefreshCnt и идуs IDR period отключается через NVENC_INFINITE_GOPLENGTH. - examples/grid_record: флаг --intra-refresh (период = fps). Live-validated: rtsp://192.168.88.23:554/load16ir - 16-cell 1080p 4×4 6Mbps intra refresh ON - mediamtx tишина: ни одного 'reader is too slow' warning'а - VLC connect → чистая картинка во всех 16 ячейках - 100 кадров логи: '1 IDR' (только начальный) — после стартового никаких больше IDR не было, ровный bitstream Этот flag не default для случая single-source (Phase 1 simple_record) — там IDR-based GOP всё ещё лучше (полный keyframe = быстрый connect). Включать осознанно для multi-source grid'ов через --intra-refresh.
cuframes-composer
Стандалонный композитор-демон для multi-source видео grid через CUDA + NVENC + RTSP.
Заменяет монолитный ffmpeg-конвейер (ffmpeg + vf_cuda_grid фильтр) для случаев, когда нужно:
- Поток продолжает работать при потере любого числа источников (graceful degradation)
- Композитор сам управляет частотой кадров и обработкой ошибок без зависимости от семантики ffmpeg-демухера
- Минимум перемещений данных: zero-copy CUDA от источника
cuframesнапрямую в NVENC
Статус
Phase 1 — MVP. В разработке. Не для боевой эксплуатации.
См. дизайн-документ для архитектурных решений и поэтапного плана.
Зависимости
- cuframes — библиотека zero-copy передачи кадров. Подключена как git submodule.
- nv-codec-headers — MIT-licensed заголовки NVENC API. Подключена как git submodule. Сама библиотека
libnvidia-encode.soгрузится черезdlopenпри старте (это даёт LGPL-совместимость — см. дизайн-документ часть 1.6). - CUDA Toolkit 12.x+ (для cuda runtime и компиляции)
- NVIDIA драйвер 525+ (для NVENC и
cuMemCreatePOSIX FD) - Linux 64-bit (POSIX shm, SCM_RIGHTS)
Дополнительно по фазам:
- Phase 3:
libfreetype(текст),lodepngчерез submodule (PNG-декодирование) - Phase 4:
libzmq(управление)
Сборка
git clone --recursive git@git.goldix.org:gx/cuframes-composer.git
cd cuframes-composer
cmake -B build -G Ninja
ninja -C build
Поэтапный план
| фаза | срок | результат |
|---|---|---|
| 1 | 1 неделя | один источник → NVENC → файл .h264 (доказательство zero-copy) |
| 2 | 2 недели | четыре источника + композиция через libcugrid |
| 3 | 2 недели | оверлеи + RTSP push к mediamtx + AAC passthrough из /live-audio |
| 4 | 1 неделя | паритет ZMQ-управления с фильтром vf_cuda_grid |
| 5 | 1 неделя | боевое развёртывание + MQTT health + watchdog |
| 6 | 2 недели | тесты + бенчмарки + документация |
Итого ~9 недель для одного разработчика.
Лицензия
LGPL-2.1-or-later. См. файл LICENSE.
NVENC SDK headers (third_party/nv-codec-headers) — MIT license, совместима с LGPL.