What a camera does to a CPU

Same footage. Same result. A fraction of the load.

Most camera-analytics pipelines reprocess the whole frame, every frame, forever — whether or not anything moved. Pick a stream and watch three approaches carry the same analytics. Only the work changes.

These are sample fixed-camera clips used for illustration. The core grid is a visualization, not a measurement of a real node; percentages are driven live by how much of each frame that method must actually recompute. When the whole frame changes at once — a camera bump, a lighting shift, a scene cut — HST detects it and falls back to the dense path rather than pay to schedule every tile, then resumes tile-delta once the scene settles.

No optimization

full recompute

Every tile, every frame. The default in most deployments — and what melts the cluster.

Node load100%

tiles/frame 576▲ thermal throttle

Motion ROI

bounding box

Best-in-class open source (OpenCV / Frigate). Background subtraction, then analytics on a box around each moving blob.

Node load—

tiles/frame —warm

HST

tile-delta

Recomputes only the tiles whose pixels actually changed — and falls back to the dense path when too much changes at once.

Node load—

tiles/frame —cool

Measured, not mimicked

The benchmark behind the demo

The live panels above are illustrative. These numbers are measured wall-clock CPU, single core, OpenCV 5.0, running the identical analytics (blur → Sobel → threshold) over the evaluation streams. Two workload weights: light (edge pass) and heavy (adds bilateral denoise, ≈ a detection front-end). Baselines are the actual open-source options: frame-differencing gates (à la motion/ZoneMinder) and MOG2 background subtraction (à la Frigate).

17.6×

less analytics CPU — HST vs full recompute, quiet high-res stream, heavy workload

2.8×

less analytics CPU — busy 720p stream, heavy workload

identical

HST output vs full recompute, tile-exact

1784 / 1800

frames the frame-diff gate skipped while ~12 tiles/frame were genuinely changing

The main result is that HST dirty-tile scheduling is cutting analytics CPU while preserving full-recompute-equivalent output. On the heavy workload, we are seeing 2.8× less analytics CPU on the busy 720p stream and 17.6× less analytics CPU on the mostly static 2260×1272 stream. The important part is that this is not a cheap frame-skip trick: the output remains tile-exact against full recompute, while the open-source frame-diff style gate skips localized changes and MOG2 can cost more than it saves.

Full recompute HST tile-delta Frame-diff gate MOG2 gate

Stream A · Heavy

720p busy scene — the hard case

Stream B · Heavy

2260×1272 quiet — the cluster case

Stream A · Light

where scheduling overhead shows

Stream B · Light

high-res quiet, cheap per-pixel work

pipeline / cpu ms·frame⁻¹	A · light	A · heavy	B · light	B · heavy	fidelity
Full recompute	1.9	23.2	8.8	77.3	reference
HST tile-delta	3.1	8.4 2.8×	3.2 2.7×	4.4 17.6×	tile-exact = full
Frame-diff gate (OSS)	0.7	7.6	0.4	1.0	misses localized motion
MOG2 gate (OSS)	13.7	26.7	37.3	49.4	costs more than it saves
H.264 decode (all pipelines)	+4.9		+15.6		unavoidable

HST wins exactly where the theory predicts

2.8× less analytics CPU on busy 720p and 17.6× on mostly-static high-res under heavy per-pixel work. Big, quiet frames feeding heavy analytics — the camera-cluster profile — sit squarely in the HST envelope. Both figures are single-core analytics-stage measurements on Apple Silicon (arm64), July 2026. We have not run this across a cluster, so we do not claim a cluster-level core, power, or temperature result.

The open-source gates trade correctness for cheapness

The frame-diff gate posts the lowest CPU, but it is all-or-nothing: on Stream B it skipped analytics on 1,784 of 1,800 frames while ~12 tiles/frame were genuinely changing — localized motion it never saw. MOG2 is worse: its background model is a full-frame op every frame, so it costs more than the analytics it gates. HST is the only option delivering full-recompute-equivalent output at fractional cost.

Scheduling overhead is real — and bounded

Under light workloads HST ties or loses (3.1 vs 1.9 ms on busy A): dispatch cost exceeds pixels saved. Merging adjacent dirty tiles into runs already cut it from 5.2 → 3.0 ms. What is left is dispatch overhead we have not yet measured a fix for. And when the change is too large, HST falls back to dense rather than pay — the same behavior shown live above.

Decode is the floor nobody escapes

H.264 software decode costs 4.9 ms/frame (A) and 15.6 ms/frame (B) for every pipeline, HST included. For light analytics, decode — not analytics — is the dominant heat source. Scope the CPU-reduction claim to the analytics stage, or pair it with hardware decode on the cluster nodes.

Method: single core · OpenCV 5.0 · Apple Silicon (arm64) · July 2026 · 594 + 1800 frames · identical blur → Sobel → threshold analytics across every pipeline. Range across these runs is 2.8–17.6× on heavy analytics; on light analytics HST ties or loses, because H.264 decode — not analytics — dominates the frame budget.