CameraStackTalk to us
← Field notes

ONVIF MotionRegionDetector
without full-frame CPU processing.

CameraStack's ONVIF MotionRegionDetector evaluates polygons on a small activity grid, not on full video frames: one shared rule evaluator fed by a GStreamer sampling branch or by the motion hardware of three camera SoCs.

3 August 2026Analytics

CameraStack now implements the ONVIF MotionRegionDetector rule across its GStreamer backends and all three external-producer camera platforms. A client defines an arbitrary polygon over the video source, arms it, and receives a named ONVIF event when motion enters or leaves that region. The event carries both the physical video-source token and the rule name, so a viewer can retrieve the same polygon through the Media service and draw it over either encoded stream. CameraStack also derives the conventional whole-source MotionAlarm from the same observations.

Sampling instead of analysing frames

On GStreamer platforms, a leaky analysis branch samples a small 128x72 luma image at 5 frames per second. It averages each 4x4 group into a 32x18 activity grid, then compares consecutive grids in pure Go. Rate limiting happens before colour conversion and scaling, so the CPU never has to analyse every full-size video frame. The branch is active only while at least one motion rule is armed, and the same small luma image also supplies CameraStack’s ImageTooDark measurement.

An ONVIF polygon rasterised onto a 32 by 18 activity grid

The same rules on SoC motion hardware

Custom-SDK cameras use the same model without sending raw video into the Go server. The native producer receives one complete, transactional rule set, programs or reads the SoC’s motion hardware, and returns a compact activity map. The measured maps differ by platform: Rockchip RV1106 IVS provides 30x17 cells over a 960x540 analysis channel, Sophgo SG2002 IVE SAD provides 32x18 cells from a 128x72 branch, and Axera AX630C IVES provides 84x47 cells over the 2688x1520 source.

Shared evaluator for all platforms

The portable part lives in CameraStack’s shared producer library. It rasterises each ONVIF polygon into the platform’s activity cells, applies per-rule sensitivity and transition damping, and formats named MotionRegionDetector events plus the aggregate alarm. Only the thin vendor boundary knows whether the SDK supplied packed bits or one byte per cell. The result is one behaviour across GStreamer and three distinct camera SoCs: the software path works behind both RTSP serving backends, and the simulator supplies a repeatable acceptance source, all without forking the ONVIF behaviour or the external-producer design.

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