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 switches to the dense path, then resumes tile-delta once the scene settles.
No optimization
full recomputeMotion ROI
bounding boxHST
tile-deltaMeasured, not mimicked
The benchmark behind the demo
The live panels above are illustrative. These numbers are measured wall-clock CPU, single core, OpenCV (version not recorded), 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).
HST dirty-tile scheduling cuts analytics CPU substantially: on the heavy workload, 2.8× less analytics CPU on the busy 720p stream and 17.6× less on the mostly static 2260×1272 stream. It is more selective than the open-source alternatives — the frame-diff style gate skips localized changes, and MOG2 can cost more than it saves. Correction, 2026-08-10: this passage previously claimed the output was “tile-exact against full recompute”. That was wrong and has been withdrawn. The gate marks a tile clean when its frame-to-frame mean absolute luma delta stays under a threshold (default 4.0) and reuses that tile’s cached result — so sub-threshold change is carried forward rather than recomputed. Measured against a true full recompute on real footage at that default, output differs in 794 of 795 frames. This is a tunable staleness/CPU trade, not a lossless cache. The CPU figures above are unaffected; what changes is that they buy an approximation, not an identical answer.
Stream A · Heavy
Stream B · Heavy
Stream A · Light
Stream B · Light
| pipeline / cpu ms·frame⁻¹ | A · light | A · heavy | B · light | B · heavy | fidelity |
|---|---|---|---|---|---|
| Full recompute | 1.9 | 23.2 | 9.0 | 77.3 | reference |
| HST tile-delta | 3.0 0.65× | 8.4 2.8× | 3.2 2.8× | 4.4 17.6× | threshold-gated reuse — differs from full |
| Frame-diff gate (OSS) | 0.7 | 7.5 | 0.4 | 1.0 | misses localized motion |
| MOG2 gate (OSS) | 13.7 | 26.6 | 37.9 | 49.6 | costs more than it saves |
| H.264 decode (all pipelines) | +4.9 | +15.6 | unavoidable | ||
Where the gain appears
2.8× less analytics CPU on busy 720p and 17.6× on mostly-static high-res under heavy per-pixel work, both against full recompute. Big, quiet frames feeding heavy analytics — the camera-cluster profile — sit squarely in the HST envelope. Light analytics on a busy 720p frame is the other end of it: there HST reads 0.65× and loses, because the bookkeeping costs more than the 1.9 ms of work it is skipping. Every figure here is a single-core analytics-stage measurement taken in July 2026 on an arm64 Mac. The exact machine was not recorded, so read the architecture and not the part.
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.
It gets out of its own way
Merging adjacent dirty tiles into runs took dispatch from 5.2 → 3.0 ms on this harness — a single unpublished run, one compiler, with nothing else held fixed, so read it as a direction and not as a measured factor. When a whole scene turns over at once, the path switches to dense and back on its own, which is the behaviour the panels above show live. Nothing downstream has to be told which mode it is in.
Decode is a shared constant
H.264 software decode costs 4.9 ms/frame (A) and 15.6 ms/frame (B), identical across every pipeline here. These figures measure the analytics stage, which is the part that scales with resolution and detector weight. On cluster nodes, hardware decode takes the constant off the CPU entirely and the analytics saving lands on top.
Method: single core · OpenCV, version not recorded · arm64 Mac (inferred from when the run happened, not recorded) · 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. Every ratio on this page is computed from the unrounded run; the table and charts show the same figures rounded to one decimal. Recompute from the rounded cells and you will land within about 2% of what we quote, not on it exactly — that is the rounding, not a second measurement.