← Field notes

Object analytics across
GStreamer and camera NPUs.

CameraStack turns detections from TensorRT, ONNX Runtime and native camera SDKs into the same tracked ONVIF scene metadata: stable object IDs, source-space boxes and live model selection, on every platform.

6 August 2026Analytics

CameraStack now supports live object analytics across its GStreamer platforms and all three custom-SDK camera ports: the Rockchip RV1106, Sophgo SG2002 and Axera AX630C. Detected objects are tracked over time and published in the profile’s metadata stream with stable object IDs, source-space bounding boxes, class candidates and confidence. That stream carries ONVIF’s standard scene description schema, so any client that understands it can consume the video and its matching scene description through the same camera profile, with no CameraStack-specific integration.

The unusual part is not the detector alone. Camera hardware has no universal inference stack. An NVIDIA Jetson Nano uses DeepStream and TensorRT. A generic GStreamer host can use ONNX Runtime or a platform inference element. An Axera camera uses AX_ENGINE inside a small native producer linked to the vendor SDK. CameraStack treats those as composable platform stages rather than forcing one pipeline onto every target.

Different inference pipelines converging on one CameraStack scene plane

A vendor-neutral detection frame

The convergence point is a small detection frame: capture time, physical video-source dimensions, and a bounded list of labelled boxes. On GStreamer systems, raw model heads enter model-family decoders written in Go. Native camera producers use matching common C decoders and send only decoded scene records to the server. Each decoder pair is pinned to the same reference, class list, confidence rule, NMS behaviour, tie ordering and golden tensor fixtures. Raw vendor tensors never cross the producer protocol.

Above that boundary, every platform uses the same tracker and ONVIF serialiser. The tracker assigns stable IDs and emits explicit deletions when objects leave the scene. The serialiser maps COCO labels into broad ONVIF candidates such as Human, Vehicle or Animal where possible, while retaining the specific detector label. Capture time comes from the analysed video frame’s PTS, not from the later moment when inference finishes.

Coordinates belong to the video source

Coordinates always belong to the physical video source rather than an encoded profile. A detector may consume a 320x320 image while the camera serves 1080p main and lower-resolution sub streams, but its boxes are mapped back to the full source plane before tracking. The same metadata can therefore accompany either profile without stretching, mirroring or shifting boxes differently for each encoder.

Detection coordinates restored to the physical video source before tracking and ONVIF serialisation

On the native camera SDKs

The Axera AX630C integration shows what this looks like on a camera SoC. An unlinked IVPS branch applies the same orientation as the displayed video and feeds AX_ENGINE at 5 frames per second. It can run the portable PicoDet-S, YOLOX-Nano and PP-YOLOE-S models, Axera’s factory YOLOv5s, or the higher-level SKEL person-and-vehicle detector. The producer decodes raw heads or adapts SKEL’s already-decoded objects locally, while CameraStack still owns tracking and ONVIF. Video encoding, snapshots, OSD, Imaging, motion regions and object analytics all continue through one resident hardware video pipeline.

The Sophgo SG2002 port works the same way. Its Cvitek NPU runs PicoDet-S, YOLOX-Nano, Seeed’s YOLO11n and PP-YOLOE-S inside the resident native producer, at a selectable 1 or 5 fps cadence, and switching models replaces only the inference context while the encoders, snapshots and motion rules stay resident.

GStreamer on an old software base

The Jetson integration proves the GStreamer side does not require a modern desktop stack. The Nano remains on NVIDIA’s JetPack 4.6 GStreamer 1.14 base and uses DeepStream 6.0.1 elements, nvstreammux and nvinfer, with TensorRT engines built on the target. PicoDet’s FP16 engine sustained about 50 inferences per second in isolation, and the larger PP-YOLOE-S engine about 10 per second, both beyond CameraStack’s selected 5 fps analytics cadence. Object metadata ran while both 1080p hardware video profiles were strict-decoded and a snapshot was taken, with a stable daemon throughout.

Model selection is a live control

PicoDet-S and YOLOX-Nano are the compact portable models, and plain PP-YOLOE-S adds a larger royalty-free option. Camera-vendor models can also be enabled when their artifacts are present: Seeed’s YOLO11n, Axera’s YOLOv5s and SKEL, and Luckfox’s YOLOv5 are proven examples. CameraStack does not redistribute models whose rights are not independently established. It detects operator-installed artifacts and advertises only the choices that genuinely exist on that camera.

The model is a live ONVIF control rather than a compile-time choice. From a standard ONVIF client, an operator picks a model from the list the camera advertises and the running camera switches over, with no rebuild, restart or console access. Underneath, the fixed ObjectDetector analytics module exposes the available models, confidence range and platform-proven inference rates. A ModifyAnalyticsModules request changes the resident inference path transactionally, verifies the new state, and rolls back on failure. Tracking, transport, ONVIF serialisation and the video-source coordinate system remain unchanged across the switch.

Integrators choose the accelerator, precision and pipeline that fit their product, and CameraStack keeps client semantics, timestamps, object identity and metadata transport the same on every port.

Details on the ports are on the Server page, and evaluation builds are available: get in touch.