System architecture

The Offline-First
Isolation Architecture.

We built OpenNVR with a fundamental assumption: IP cameras are inherently insecure. They cannot be trusted. The architecture is designed around strict network isolation and a fully decoupled, fault-isolated AI inference pipeline.

Topology: Dual-NIC Isolation

                               ┌──────────────────────────────────────────────────┐
                               │                 Open-NVR Server                  │
                               │                                                  │
  Untrusted Area               │       ┌──────────────┐     ┌────────────────┐    │
  IP Cameras (PoE)       [NIC 1]       │   MediaMTX   │     │  KAI-C Engine  │    │
  10.0.0.X Range   ────────────┼─────> │   Gateway    │────>│  Frame Slicer  │    │
  (No Internet Access)         │       │              │     │                │    │
                               │       └──────┬───────┘     └────────┬───────┘    │
                               │              │                      │            │
                               │              │ <WebRTC>             │ <JSON>     │
                               │              v                      v            │
  Trusted User LAN       [NIC 2]       ┌──────────────┐     ┌────────────────┐    │
  192.168.1.X Range ───────────┼─────> │ React NextJS │<────│  AI Adapters   │    │
  (Admin / Viewers)            │       │   Frontend   │     │  Microservice  │    │
                               │       └──────────────┘     └────────────────┘    │
                               └──────────────────────────────────────────────────┘
OpenNVR sovereign architecture: cameras on an isolated tier, KAI-C as the only edge, recording and AI inference and the audit log all staying on your hardware, cloud egress blocked
Cameras stay isolated; KAI-C is the only edge; recording, inference and the audit log never leave your hardware.
OpenNVR end-to-end data flow: cameras to MediaMTX, which records to disk (never gated) and republishes a substream to the always-on Tier-0 detect-pipeline (decode, motion, region, ONNX detect, track, best-frame). Tier-0 publishes events to the NATS bus. A gate runs expensive frame models (VLM, face, plate) once on the best frame, governed by KAI-C. The camera-agent and apps consume results, answering many questions from Tier-0 metadata with no VLM call. STT, TTS and the LLM are voice or text and are not gated.
End-to-end: an always-on cheap tier watches every camera and gates the expensive models, so AI runs on affordable hardware — recording is never gated.

1The Zero-Trust Camera LAN

In a standard deployment, cameras are placed on a dedicated, non-routable VLAN. They cannot reach the internet to "phone home" to malicious servers, and end-users cannot reach them directly. The OpenNVR server sits on the perimeter using a dual-NIC (Network Interface Card) configuration to bridge the gap safely.

OpenNVR uses the high-performance MediaMTX engine (written in Go) to ingest the raw RTSP feeds from the camera LAN, then exposes a controlled, encrypted WebRTC gateway to the trusted user network. If a camera is compromised by a botnet or malware, it has no route out — the isolated VLAN and default-deny forwarding rules give it nowhere to go.

2KAI-C: The Connective Middleware

At the core of OpenNVR's intelligence pipeline is KAI-C. It bridges the gap between the raw video streams and the Python-based Artificial Intelligence inference server.

KAI-C hooks directly into the MediaMTX output channels, extracts raw keyframes (I-frames) at configurable intervals without needing to fully transcode the stream, and saves them to a hyper-fast RAM disk via an `opennvr://` virtual URI syntax.

# Internal Request Lifecycle
1. MediaMTX passes RTSP track to KAI-C worker.
2. KAI-C saves frame to absolute virtual URI.
3. KAI-C executes HTTP POST to AI Adapter engine (Port 9100).
curl -X POST http://127.0.0.1:9100/infer -d '{"task": "person_counting", "input": {"frame": {"uri": "opennvr://camera_0/latest.jpg"}}}'

3Decoupled AI Processing

Most legacy NVRs bake object detection directly into the C++ video recording monolith running on the server. If a complex neural network throws an out-of-memory (OOM) exception or panics, the entire NVR crashes and you lose security footage.

We brutally decoupled them.

  • The Video Recording engine is written in Go and never touches PyTorch.
  • The AI Adapters engine is a separate Python FastAPI microservice.
  • They communicate purely via strict JSON Schemas over internal HTTP.

Result: If you drop experimental, untested Hugging Face code into your AI Adapters folder and it explodes, KAI-C gracefully logs a timeout error while the core Go routing engine continues tracking and recording your cameras without dropping a single frame.

4Compute-Gated Inference

Running a heavy neural network on every frame of every camera doesn't fit modest hardware. OpenNVR uses a two-tier, compute-gated pipeline so real AI runs on affordable boxes like a Raspberry Pi 5 or an Intel N100.

  • Tier 0 — always-on and cheap. A per-camera pipeline (motion → region → a lightweight ONNX detector → tracking → best-frame) watches every stream and publishes structured events. It runs on a pluggable backend: plain CPU, or an accelerator via OpenVINO / TensorRT on the same model.
  • The gate — spend the expensive models sparingly. Heavy models (scene-describing VLMs, face, license plate) run once, on the best frame of a real event — not on every frame — and every decision, including the ones it skips, is audited by KAI-C.
  • Recording is never gated. Video always records regardless of any AI decision — the AI only ever adds understanding, never gatekeeps your footage.

Shipping in stages: the always-on detection tier and the gate — which makes and audits every escalate/suppress decision — are live today; automatically running the gated models on those decisions is the next step.

Result: an always-on cheap tier answers most questions ("is anyone at the door?", "how many cars today?") with no expensive model at all, and reserves the costly models for the moments that actually matter — turning a workstation-class AI workload into something that runs quietly on hardware you already own.