I ran a real A/B on the recorder host: motion-detection decode on CPU versus NVDEC, same 11 cameras, same fps-cap, same scene. Recording itself is stream-copy (no decode) so footage continued either way.
The numbers
| Metric | NVDEC | CPU | Delta | | --- | --- | --- | --- | | Wall meter | 105 W | 73 W | -32 W (-30%) | | GPU power | 36.6 W | 8.8 W idle | -27.8 W | | Recorder CPU | ~26% | ~33% | +7% (about 0.08 cores) | | GPU temperature | 51 C | 35 C | -16 C |
Why CPU wins here
NVDEC has a fixed activation cost. Waking the decode block costs roughly 28 W no matter how trivial the workload is. At this scale (11 fps-capped sub-streams at about 0.08 cores of actual decode work), the CPU does it for free, while the GPU has to spin up just to do the same thing. PSU efficiency magnifies the savings, and the GPU fans wind down once it cools.
When NVDEC wins again
More cameras, higher fps, higher analysis resolution, or when the GPU is already awake for another workload (a streaming server, a local LLM). At those scales the CPU cost grows linearly and eventually crosses the GPU's fixed floor.
What shipped with it
HwAccel::Vaapi is now a first-class option (use an Intel iGPU instead of a discrete card), and decode mode is admin-selectable from the web console: auto / cpu / cuda / vaapi, plus an optional VAAPI device path. Changes hot-reload without a full restart: each camera picks up the new mode on its next supervisor poll. Reverts the same way.
This box has Intel UHD 770 (/dev/dri/renderD128) and the discrete NVIDIA both mapped, so all three modes are selectable from the admin UI on the same machine. Final prod state: vaapi + the Intel renderD128. Decision verified on the wall meter. Committed and pushed.