{"slug": "opennvr-0-1-10-running-an-open-source-nvr-s-ai-on-the-qualcomm-hexagon-npu", "title": "OpenNVR 0.1.10: running an open-source NVR's AI on the Qualcomm Hexagon NPU", "summary": "The OpenNVR project released version 0.1.10, the first with hardware-acceleration flavours, adding Qualcomm Hexagon NPU support via ONNX Runtime's QNN execution provider shipped as a plugin wheel. On an Arduino Ventuno Q (Dragonwing IQ-8275), YOLO detection dropped from 164 ms per frame on eight CPU threads to 8.6 ms on the NPU in fp16, and the full stack handled 16 cameras at 2 fps with no dropped frames versus 4 on CPU. The project reports the NPU's own share of an adapter call is about 9 ms, leaving JPEG decode and preprocessing as the bottleneck.", "body_md": "OpenNVR is an open-source (AGPL) NVR that records and streams from any ONVIF or RTSP camera and runs the AI model you choose behind them: YOLO detection, pose, face recognition, plate OCR, open-vocabulary detection, and a vision-language agent that can look at a scene and reason about it. It runs on hardware you own, air-gapped if you need, with every inference audited.\n\nVersion 0.1.10 is the first release with hardware acceleration flavours, and this post is about the one I have numbers for: Qualcomm's Hexagon NPU.\n\nArduino Ventuno Q: Qualcomm Dragonwing IQ-8275 (QCS8275), eight ARM cores, a Hexagon NPU, Ubuntu 24.04. Small, fanless, the kind of thing that sits behind a few cameras in a shop or a plant.\n\nAll measured on that board with the published container images. Full windows, settle times and caveats are in the [benchmark doc](https://github.com/open-nvr/open-nvr/blob/main/bench/ventuno-q-benchmark-2026-10-30.md).\n\nTier-0 detector (YOLO, one frame):\n\n| Device | ms per frame | \n|---|---|\n| CPU, 8 threads | 164 | \n| Hexagon NPU, fp16 | 8.6 | \n\nIn the full stack (streams, decode, tracking, the API, all on the same box):\n\n| Device | Cameras at 2 fps, no drops | Host idle | \n|---|---|---|\n| CPU | 4 (10 cameras drop half their frames) | ~4 % | \n| NPU | 16, 0 dropped | 46 % | \n\nThe adapters that sit behind the detector, end-to-end on one 1080p JPEG:\n\n| Adapter | CPU | NPU | \n|---|---|---|\n| YOLO | 141 ms | 77 ms | \n| Pose | 108 ms | 64 ms | \n| Package detection | 100 ms | 60 ms | \n| Face recognition (InsightFace) | 443 ms | 62 ms | \n| Plate OCR | 248 ms | 62 ms | \n\nThe NPU's own share of an adapter call is about 9 ms. The rest is JPEG decode and preprocessing on a busy CPU, so the adapter path is now bounded by image handling, not inference.\n\nEverything goes through ONNX Runtime's QNN execution provider, shipped as a plugin wheel (`onnxruntime-qnn`). There is no Qualcomm SDK to install on the host. The `-qualcomm` container gets the DSP device node, the DMA heap, and two host libraries bind-mounted, and that is it.\n\n```\ngit clone https://github.com/open-nvr/open-nvr.git && cd open-nvr\n./start.sh        # OPENNVR_ACCEL=auto detects /dev/fastrpc-cdsp and picks the qualcomm flavour\n```\n\n`OPENNVR_ACCEL=cpu|intel|qualcomm` overrides the probe. A box with only a CPU gets exactly the images it got before.\n\nCompiled graphs are cached, so the second start skips the ~6 s compile. The pipeline reports which provider ONNX Runtime really ran on, and a request for an accelerator that silently fell back to CPU shows up as `requested != effective` in the metrics instead of being hidden.\n\n`providers=` list is silently ignored. It has to be attached by device with `add_provider_for_devices`.` python:slim` lacks `libatomic1`. The HTP backend fails to load and the session falls back to CPU with no error.`up`.\n\n```\npython -m detect_pipeline.bench --latency 200 --providers CPUExecutionProvider\npython -m detect_pipeline.bench --latency 200 --providers QNNExecutionProvider:htp\n```\n\nIt reports median, p90 and min per device, names the provider that really ran, and exits non-zero if the accelerator fell back.\n\nNVIDIA, desktop GPUs and Jetson. If you have a Jetson, Rockchip or Hailo box you'd lend to a benchmark, I have one board and would like more.", "url": "https://wpnews.pro/news/opennvr-0-1-10-running-an-open-source-nvr-s-ai-on-the-qualcomm-hexagon-npu", "canonical_source": "https://dev.to/varun_pratapsingh_d70428/opennvr-0110-running-an-open-source-nvrs-ai-on-the-qualcomm-hexagon-npu-5199", "published_at": "2026-10-31 10:15:25+00:00", "updated_at": "2026-10-31 10:19:25.522449+00:00", "lang": "en", "topics": ["computer-vision", "ai-infrastructure", "ai-tools", "mlops", "developer-tools"], "entities": ["OpenNVR", "Qualcomm", "Hexagon NPU", "ONNX Runtime", "Arduino", "Dragonwing IQ-8275", "InsightFace", "NVIDIA"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/opennvr-0-1-10-running-an-open-source-nvr-s-ai-on-the-qualcomm-hexagon-npu", "markdown": "https://wpnews.pro/news/opennvr-0-1-10-running-an-open-source-nvr-s-ai-on-the-qualcomm-hexagon-npu.md", "text": "https://wpnews.pro/news/opennvr-0-1-10-running-an-open-source-nvr-s-ai-on-the-qualcomm-hexagon-npu.txt", "jsonld": "https://wpnews.pro/news/opennvr-0-1-10-running-an-open-source-nvr-s-ai-on-the-qualcomm-hexagon-npu.jsonld"}}