How this port works
The RV1126B has no CameraStack GStreamer dependency; its camera and
encoders are reached through Rockchip’s RKMPI SDK, as on the
RV1106. CameraStack handles platforms like this with
a C producer: a compact native adapter, written in C straight
against RKMPI and Rockchip’s AIQ libraries, that runs the vendor media
pipeline from sensor to hardware encoder and hands encoded video and
audio to the portable core. The Go server is built for the SoC’s 64-bit
Arm environment and does not link the vendor SDK.
Control flows the other way too. Because the producer controls the encoders directly,
settings changed through ONVIF are applied live: frame rate, bitrate and
GOP change mid-stream, a codec change rebuilds only the selected VENC
channel, and a main-profile change between 1080p and 4K moves only that
branch of the pipeline, while the sensor, ISP, audio, sibling stream and
analysis path keep running. Synchronisation-point requests map to
on-demand IDR keyframes, and every new reader starts on a complete
keyframe. Encoding is demand-driven per profile: each hardware encoder
runs, and draws power, only while clients consume its stream, while the
resident pipeline keeps snapshots, motion events, audio and object
metadata flowing with both video encoders idle. The proven profiles are a
main profile at 1920x1080 or 3840x2160 at up to 30 fps and a sub profile
at 640x360 at up to 10 fps, each selectable between H.264 High and H.265
Main. Those are the resolutions tested on the reference port; other
resolutions are supported and can be configured for a product.
Audio
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 on the main profile, so a single RTSP session carries video and
audio together; the sub profile carries video and metadata only. 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.
RTP timestamps advance by sample count, so audio and video stay aligned
over long sessions.
Analytics, Imaging and OSD
The Analytics service runs ONVIF
MotionRegionDetector
rules: up to four named polygons, each with its own sensitivity and
damping. The RV1126B’s IVS block measures a 30x17 activity grid over a
resident 960x540 analysis channel, and CameraStack rasterises arbitrary
ONVIF polygons onto it, so motion detection never scans full video
frames on the CPU and keeps running while both video encoders are idle.
Object detection runs on the RV1126B’s
NPU. The
ObjectDetector analytics module advertises the models present on the
device: the royalty-free portable PicoDet-S, YOLOX-Nano and PP-YOLOE-S,
alongside the vendor example detectors, YOLOv5s and YOLOv10n (if
their artifacts have been installed). CameraStack advertises only the
models genuinely present and does not redistribute vendor detectors
whose rights are not independently established, so a licensable model
is available only where it has been supplied for the device. A standard
ONVIF client can switch the model, confidence threshold and 1 or 5 fps
detection rate live. A model change replaces only the private RKNN
context and buffers; the sensor, ISP, both encoders, audio and the
daemon stay resident. Detected objects are tracked with stable IDs and
published as ONVIF scene metadata, and metadata-only clients can
subscribe without waking a paused video encoder.
The Imaging service is wired to the ISP through AIQ: brightness,
contrast and colour saturation, sharpness, automatic or manual exposure,
automatic or manual white balance with independent red and blue gains,
and backlight compensation. ImageTooDark is derived from the ISP’s
exposure-normalised environment statistic, sampled once a second, which
survives a covered lens under automatic exposure.
JPEG snapshots come straight from the hardware at both profile
resolutions, including while the video encoders are paused. Rockchip RGN
provides four text OSD slots per profile with position, black or white
foreground and background across the full transparency range, and plain
or date-and-time text. The same OSD state is composited into the
independent JPEG snapshots and survives paused encoders, codec
replacement and a main-profile resolution change.
Built on the Rockchip RKMPI SDK
The producer builds against Rockchip’s RKMPI middleware and AIQ tuning
libraries. Capture runs through VI, the video input module that drives the
sensor and ISP; VPSS scales the resident source into the main, sub and
analysis outputs; the main and sub outputs feed VENC 0 and VENC 1, the
hardware H.264, H.265 and JPEG encoders; the IVS block computes the
motion activity grid in hardware; and RGA performs the colour conversion
and resize that feed the object models on the RKNPU2 neural engine. The
producer builds on the same shared common core as the RV1106 and
CameraStack’s other custom-SDK platforms, so framing, configuration,
motion-grid mapping, event formatting, OSD rendering, pause state and
the object-model decoders are well-tested portable code, with only small
RV1126B-specific customisations on top: the RKMPI topology, ISP
controls, RKNPU2 tensor handling and the ALSA audio route. The port is
proven with a Sony IMX415 sensor at 3840x2160, 30 fps.