OpenNVR
System Architecture

The Offline-First
Isolation Architecture.

We built OpenNVR with a fundamental assumption: IP Cameras are inherently insecure. They cannot be trusted. Our architecture is designed around total mathematical containment and a fully decoupled, crash-proof 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 incredibly performant MediaMTX engine written in Go to ingest the raw RTSP feeds from the camera LAN. It then exposes a highly controlled, encrypted WebRTC gateway to the trusted user network. If a camera is compromised by a botnet or malware, it is mathematically trapped.

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.