OpenNVR
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  │    │
                               │       └──────────────┘     └────────────────┘    │
                               └──────────────────────────────────────────────────┘

1 The 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.

2 KAI-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"}}}'

3 Decoupled 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.