CameraStack on the
Axera AX630C.

Ready-made camera software for the AX630C: capture, hardware encode, RTSP streaming and a standards-compliant ONVIF interface, integrated directly against Axera's vendor SDK.

Available reference platform Class / Camera SoC

The silicon

Inside the
AX630C.

An edge-AI vision SoC built for smart cameras: a dual-core application processor, a high-TOPS neural engine, and a 4K-capable AI-ISP and hardware video pipeline on a single die.

CPU: Dual-core Cortex-A53; up to 1.2 GHz
AI engine: 12.8 TOPS; INT4 (3.2 TOPS INT8)
ISP: AI-ISP, up to 4K; 2-frame HDR, 3DNR
Video encode: H.264 & H.265; up to 4K @ 30fps
Memory: LPDDR4x; up to 4 GB

On this silicon

What runs today.

01 Sensor capture through the AX630C's AI-ISP pipeline
02 Multi-profile hardware encode, H.264 and H.265
03 The full RTSP transport family: TCP, UDP, HTTP tunnelling, WebSocket and multicast
04 ONVIF Device, DeviceIO, Media, Media2, Events, Imaging, Analytics and Advanced Security services
05 TLS: HTTPS management and snapshots, RTSP over HTTPS, secure WebSocket and rtsps:// streaming, with camera-held certificates managed through the ONVIF TLS Configuration Add-on
06 Polygon motion detection: ONVIF MotionRegionDetector rules on a hardware activity grid
07 NPU object detection with tracked ONVIF scene metadata and live model selection
08 Imaging control wired to the ISP: brightness, contrast, saturation, exposure and white balance
09 JPEG snapshots and multi-slot text OSD with transparency
10 Live encoder control: frame rate, bitrate and GOP changes mid-stream, codec swaps in place, on-demand keyframes
11 Demand-driven encoding: each hardware encoder runs only while clients consume its profile
12 Metadata streaming and events, including the ONVIF ImageTooDark tampering event

How this port works

The AX630C has no vendor GStreamer stack; its camera and encoder are reached through Axera’s native SDK. CameraStack handles platforms like this with a producer plugin: a small native component that owns the vendor media pipeline, sensor through ISP, scaler and hardware encoder, and hands encoded video to the portable core. RTSP streaming and the ONVIF services run in the shared generic core, a single static binary unchanged from every other platform.

Control flows the other way too. Because the producer owns the encoder, settings changed through ONVIF are applied live through the vendor API: frame rate, bitrate and GOP change mid-stream, a codec change rebuilds only the selected encoder channel while the sensor, ISP and sibling stream keep running, and synchronisation-point requests map to on-demand keyframes. 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 and object metadata flowing with both video encoders idle.

The integration sits at the level of the SDK that comes with the chip’s BSP, the same SDK any custom AX630C board design already has, and it carries across the Axera chips that share the same SDK.

Analytics, Imaging and OSD

The Analytics service runs ONVIF MotionRegionDetector rules: up to four named polygons, each with its own sensitivity. The AX630C’s IVES block supplies an 84x47 activity grid at 5 fps over the full video source, and CameraStack maps arbitrary ONVIF polygons onto it, so motion detection never scans full video frames on the CPU.

Object detection runs on the AX630C’s NPU. The ObjectDetector analytics module advertises the models present on the device, the portable PicoDet-S, YOLOX-Nano and PP-YOLOE-S among them alongside Axera’s factory detectors, and a standard ONVIF client can switch the model, confidence threshold and detection rate live while the camera keeps running. 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: brightness, contrast and colour saturation, automatic or manual exposure, and automatic or manual white balance with independent red and blue gains. BacklightCompensation is implemented through the ISP’s exposure position weighting.

JPEG snapshots come straight from the hardware at both profile resolutions, including while the video encoders are paused. The text OSD provides four slots per profile with plain text, date and time modes, standard and custom positions, and foreground and background transparency, and the same OSD state is applied to live video and snapshots.

Built on the Axera SDK

The port builds against the V3.0.0 Axera MSP SDK tree, with a pinned GNU AArch64 toolchain so builds stay reproducible. The producer links Axera’s runtime libraries directly: libax_sys for system and memory management, libax_ivps for the image and video processing subsystem, libax_venc for the hardware encoder, and libax_ae and libax_awb for the ISP’s auto-exposure and auto-white-balance control. IVES computes the motion activity grid in hardware, and AX_ENGINE runs the object models on the AX630C’s NPU.

ax630c / live stream probe

$ ffprobe rtsp://<user>:<pass>@ax630c.lan:8554/onvif/Profile_1
ffprobe version 7.1.1-1ubuntu4.2 Copyright (c) 2007-2025 the FFmpeg developers
  ...
Input #0, rtsp, from 'rtsp://<user>:<pass>@ax630c.lan:8554/onvif/Profile_1':
  Metadata:
    title           : CameraStack Server (AX630C)
  Duration: N/A, start: 0.138167, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt470bg/bt470bg/bt709, progressive), 2688x1520, 30 fps, 30 tbr, 90k tbn
  Stream #0:1: Data: none

The main profile runs at 2688x1520. The probe's second track is the ONVIF metadata stream, carrying analytics and events alongside the video.

Build on it

Designing an
AX630C product?

The port work is already done, at the level of the 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 AX630C