gx
6608f5d2f6
Closes последний RED-flag из arch review. Что описано (§-sections): 1. Resources & lifecycle (socket / shm / IPC handles cleanup, crash recovery) 2. Shared memory byte-by-byte layout (offsets, packing, atomics) 2.1 frame meta (64 bytes) 2.2 slot descriptor (192 bytes) 2.3 subscriber slot (128 bytes) 3. Unix socket TLV protocol (8 message types, framing) 4. State machines (subscriber-side, publisher-side per-subscriber) 5. ACK protocol с cudaEventRecord / cudaStreamWaitEvent 6. Versioning rules (proto_version vs lib_version, reserved fields) 7. Conformance test skeleton (offset checks, sizeof checks, handshake) 8. Open для v0.2 (TLS, multi-format, ROCm) 9. Reference impl pointer (libcuframes/src/protocol.c — Phase 1) После v0.2 release — wire protocol frozen, breaking changes = bump proto_version. До v0.2 — experimental. Решает все 4 пункта из arch review section R4: ✓ SHM layout (annotated struct + ASCII layout) ✓ Socket protocol (state machine + message framing) ✓ Versioning rules ✓ Lifecycle / cleanup (incl. CUDA IPC handle leak при crash) Готов к Step 2 (Phase 1 implementation).
cuframes
Zero-copy sharing декодированных видеокадров между процессами через CUDA IPC.
Статус: ⚠️ Design phase. Дизайн-спецификация готова, реализация в процессе. Лицензия: LGPL-2.1+ Платформы: Linux, NVIDIA CUDA ≥ 12.0
Идея в одну минуту
Типичный setup с несколькими сервисами видеоаналитики:
Camera ─► ffmpeg #1 (NVR, decode + record)
─► ffmpeg #2 (AI-detector, decode + inference)
─► ffmpeg #3 (custom analytics, decode + ...)
Каждый сервис делает свой decode на GPU. На 16 cameras × 25 fps × 3 consumers это сотни лишних NVDEC operations и GB/s VRAM-bandwidth впустую.
cuframes устраняет дублирование:
Camera ─► ffmpeg + cuframes filter ─► VRAM ─┬─► consumer 1 (NVR)
├─► consumer 2 (AI)
└─► consumer 3 (analytics)
Один decode, frame остаётся в VRAM, любое количество consumers читают zero-copy через CUDA IPC.
Состав
- FFmpeg filter
cuda_ipc_export— добавляется в любой ffmpeg-pipeline libcuframes— C library + C++/Python bindings для consumers- Docker images — drop-in replacement для существующих setups (включая Frigate)
Quickstart
🚧 в разработке
# Producer (после v0.1)
docker run --gpus all -v /run/cuframes:/run/cuframes ghcr.io/<org>/cuframes-ffmpeg:N \
ffmpeg -hwaccel cuda -i rtsp://camera/stream \
-vf "scale_cuda=1920:1080,cuda_ipc_export=key=cam1" \
-c:v copy -f segment recording.mp4
# Consumer (C++)
#include <cuframes.hpp>
cuframes::Subscriber sub("cam1");
while (auto frame = sub.next()) {
// frame->cuda_ptr — device pointer, zero-copy
process_on_cuda(frame->cuda_ptr, frame->width, frame->height);
}
Документация
- docs/architecture.md — полный design document
- docs/protocol.md — wire protocol (в разработке)
- docs/quickstart.md — (в разработке)
Why
Подтверждённый спрос в Frigate community (#17033,
#20191, #21559)
— люди тычатся в NVDEC saturation при многокамерных setup'ах. Решения уровня
NVIDIA DeepStream закрытые / vendor-locked. Open source FFmpeg-plugin для этой
ниши не существует. См. подробный prior-art analysis в docs/architecture.md.
Roadmap
| Phase | Что | Срок |
|---|---|---|
| 0 | PoC spike, CUDA IPC latency measurements | 3 дня |
| 1 | libcuframes (producer/consumer ring buffer + handshake protocol) |
1 неделя |
| 2 | FFmpeg filter vf_cuda_ipc_export + patched FFmpeg build |
1-2 недели |
| 3 | C++ / Python bindings | 1 неделя |
| 4 | Docker packaging + Frigate drop-in image | 3-5 дней |
| 5 | Reference consumer: 16-камерный mosaic compositor | 1 неделя |
| 6 | OSS launch (HN, reddit, FFmpeg upstream PR) | 3-5 дней |
Contributing
Проект на ранней стадии. Перед PR сверьтесь с docs/architecture.md и CONTRIBUTING.md.