yuragb/c-_camera_yolo_service

Purpose and Entry Point

Camera CV Service is a C++17 edge video service: capture camera/file frames, run YOLO detection, and deliver low-latency H.264 WebRTC video plus detection/metrics metadata. The process entry point is src/main.cpp; CMake builds the native executable via CMakeLists.txt.

Runtime Composition

Startup loads environment-driven pipeline settings, selects platform services, capture input, inference backend, and WebRTC signaling/media services. Runtime configuration is centralized in include/core/pipeline/runtime_config.h and src/core/pipeline/runtime_config.cpp. OS-dependent defaults, paths, and camera enumeration are isolated behind include/platform/platform_services.h, with implementations in src/platform/windows/windows_platform_services.cpp and src/platform/linux/linux_platform_services.cpp.

Capture and Frame Ownership

CameraManager manages one or more sources and provides the pipeline’s current frames. Capture is abstracted by include/capture/video_source.h; the concrete OpenCV source supports cameras and video files in src/capture/opencv_video_source.cpp. Shared frame representation belongs in include/models/frame.h. This is the boundary between device/file I/O and all downstream processing.

Decoupled Video and Detection Flows

The architecture intentionally separates:

• Live path: latest capture frame → resize/encode → WebRTC media. Stale frames are dropped to cap latency.

• Detection path: captured frames → asynchronous inference → tracking → DataChannel JSON. It may lag and must not block video.

• Telemetry: video latency samples and interval metrics are generated independently of inference and sent through the DataChannel.

Pipeline coordination is rooted in src/camera_manager.cpp, src/inference_engine.cpp, and src/webrtc_service_media.cpp. Object tracking is a distinct post-inference stage in src/tracking_manager.cpp, backed by vendored third_party/ByteTrack-cpp.

Inference Boundary and Acceleration

InferenceEngine owns model execution and detection processing through a backend interface in include/inference_backend.h. src/inference_backend_factory.cpp chooses:

• ONNX Runtime implementation: src/onnx_runtime_backend.cpp

• optional TensorRT implementation: src/tensorrt_runtime_backend.cpp

TensorRT is compile-time gated and falls back to ONNX Runtime if unavailable. Models are external runtime assets under models/ or mounted paths, not repository contents.

WebRTC, Encoding, and Signaling

WebRTCService integrates libdatachannel peer connections, an H.264 media track (liveStream), and DataChannel (detectionStream). Responsibilities are split across src/webrtc_service.cpp, src/webrtc_service_peer.cpp, src/webrtc_service_media.cpp, and src/webrtc_service_signaling.cpp. Signaling uses an external WebSocket server for registration, SDP offers/answers, and ICE exchange; default STUN is Google’s public server. Optional HS256 JWT authentication uses OpenSSL and a shared signaling-server secret.

H.264 encoding is wrapped by include/openh264_encoder.h and src/openh264_encoder.cpp; OpenH264 is dynamically loaded at runtime.

Deployment Boundaries

The primary runtime is native Windows/Linux or Linux containers. Dockerfile provides the CPU image; Dockerfile.tensorrt and docker-compose.tensorrt.yml support NVIDIA TensorRT. Kubernetes/k3s deployment manifests are in k3s/05-yolo-service-deployment.yaml, with ConfigMap and Secret separation in k3s/02-yolo-service-configmap.yaml and k3s/02-yolo-service-secret.yaml. Cameras, models, media, GPU devices, and signaling remain external infrastructure dependencies.