Ready-made camera software for the SG2002: capture, hardware encode, RTSP streaming and a standards-compliant ONVIF interface, integrated directly against the Cvitek/Sophgo MPI video pipeline SDK.
The silicon
A tiny edge-AI camera SoC: RISC-V and Arm application cores on one die, a neural engine, and a 5-megapixel ISP and hardware video pipeline, with the DRAM in the package.
On this silicon
The SG2002 has no vendor GStreamer stack; its camera and encoder are reached through the Cvitek/Sophgo MPI (Media Processing Interface) SDK. CameraStack handles platforms like this with a C producer: a custom adapter, written in C straight against the vendor SDK, that owns the media pipeline from sensor to hardware encoder and hands encoded video to the portable core. RTSP streaming and the ONVIF services run in the shared generic core which provides the core feature set shared with every other platform.
The producer implements the vendor-specific feature set in full. Encoder settings changed through ONVIF are applied live: frame rate and bitrate change mid-stream with no disconnection, and synchronisation-point requests map to on-demand IDR keyframes. JPEG snapshots and OSD text overlay run through the same pipeline. Encoding is demand-driven per profile: each hardware encoder runs, and draws power, only while clients consume its stream. The sensor, ISP and analysis pipeline stay resident throughout, so snapshots, motion detection and object analytics keep working while the video encoders are idle, and a resumed stream starts on a fresh keyframe.
Everything above the producer comes from the shared portable core, and this port inherits it all for free: the full RTSP transport family (interleaved TCP, UDP, HTTP tunnelling, WebSocket and multicast), metadata streaming, and eight ONVIF services, Device, DeviceIO, Media, Media2 (Profile S and Profile T), PTZ, Events, Imaging and Analytics. Events include the ONVIF ImageTooDark tampering topic, and the PTZ service made its CameraStack debut with this port.
The producer captures the camera’s microphone through ALSA and hands G.711 mu-law audio, 8 kHz mono at 64 kbps, to the core as a second RTP track, so a single RTSP session carries video and audio together. Audio is exposed through the standard ONVIF objects, an AudioSource, AudioSourceConfiguration and AudioEncoderConfiguration, which a client lists and attaches to a profile through Media1 or Media2, and it travels over the same unicast and multicast transports as the video. Audio is offered only when the microphone is present.
On this port the PTZ service drives physical pan and tilt motors: AbsoluteMove, RelativeMove, ContinuousMove, Stop, presets and a home position, from any ONVIF client. PTZ is advertised only when the actuator hardware comes up, so a camera without motors presents as a camera without PTZ rather than one with controls that do nothing.
The Analytics service runs ONVIF MotionRegionDetector rules: up to four named polygons, each with its own sensitivity and damping. The SG2002’s IVE block measures 4x4 block differences in hardware, and CameraStack evaluates the polygons on the resulting 32x18 activity grid at 5 samples per second, so motion detection never scans full video frames on the CPU.
Object detection runs on the SG2002’s TPU. The ObjectDetector analytics module advertises the model files installed on the camera, PicoDet-S, YOLOX-Nano and PP-YOLOE-S among them, and a standard ONVIF client can switch the model, confidence threshold and detection rate live. Detected objects are tracked with stable IDs and published as ONVIF scene metadata alongside the video.
The Imaging service is wired to the ISP: brightness, contrast and colour saturation, and automatic or manual exposure with manual exposure time and gain. A change is validated, acknowledged by the producer and then persisted, and accepted settings are replayed after a restart.
The producer builds against the Cvitek/Sophgo MPI middleware, the same SDK used across the CV180x, CV181x and SG200x parts. Capture runs through VI, the video input module that owns the sensor and ISP; VPSS, the video processing subsystem, scales and converts each stream profile; and VENC drives the hardware H.264, H.265 and JPEG encoders. RGN composes the text overlay, IVE computes the motion activity grid in hardware, and the object models run on the TPU, the SG2002’s neural engine. The port is proven with live multi-profile streams from a 5 MP OV5647 sensor.
$ ffprobe rtsp://<user>:<pass>@sg2002.lan:8554/onvif/Profile_1
ffprobe version 7.1.5-0+deb13u1 Copyright (c) 2007-2026 the FFmpeg developers
...
Input #0, rtsp, from 'rtsp://<user>:<pass>@sg2002.lan:8554/onvif/Profile_1':
Metadata:
title : CameraStack Server (SG2002)
Duration: N/A, start: 0.068875, bitrate: N/A
Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080, 30 fps, 30 tbr, 90k tbn
Stream #0:1: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
Stream #0:2: Data: noneThe main profile carries three tracks: 1080p30 H.264 video, a G.711 audio track from the camera's microphone, and the ONVIF metadata stream carrying analytics and events.
Field note
We brought CameraStack up on SG2002 hardware as a standards-compliant network camera, and used the port to bring the ONVIF PTZ service into the core: PTZ requests from any ONVIF client driving the pan-tilt hardware.
Read the port storyBuild on it
The port work is already done, at the level of the MPI SDK your board already has. Use CameraStack Server as your complete camera stack, or as a drop-in ONVIF interface for a pipeline you already have. Evaluation builds are available to teams building real products.
Talk to us about the SG2002