Midgarda – Vision

The problem it solves

Recording a hundred cameras is not a video problem, it is a storage and reliability problem. A hundred simultaneous writers turn what looks like sequential streaming into random I/O that a spinning disk cannot keep up with, and at steady state the system deletes as fast as it writes, forever. Most of the design work is in staying ahead of those two realities rather than in the video itself.

The decisions that shape it

• ONVIF only, no vendor drivers — manufacturer APIs break on firmware updates nobody controls. For a product supported by one person, a firmware push silently stopping a customer's recording is not a survivable support burden.
• Copy-only recording — streams are written straight to disk without decoding. No CPU cost, no generational quality loss, and no codec patent exposure from ever instantiating an encoder.
• Permissive licences only — nothing under the GPL, because linking it would force the whole product open source.
• A thin seam around the ingest engine — the media server runs as a supervised subprocess behind an interface of roughly two hundred lines, so replacing it later is one module rather than an untangling job.
• Built to be maintained by one person — every architectural choice is weighed against that, not against how sophisticated it could be.

Tech stack

Release history

Progress on the platform. Followers get an email whenever a new entry lands here.

• Sep 2026 — Step 7: control API and web interface — live status, add and manage cameras while recording, search with in-browser playback, and evidence export as a zip with a SHA-256 manifest that can be re-verified later. Password-protected, with requests checked and credentials redacted throughout. (in development)
• Sep 2026 — Step 6: scale bench to 100 simultaneous streams, measuring CPU, memory and write rate, killing the media server mid-run and forcing the disk-space floor. It found four real defects, all fixed. (in development)
• Sep 2026 — Step 5: keyframe thinning — each closed segment is cut down to its keyframes for a long-term archive tier with its own retention, about 2× smaller on a static scene and 7× with motion. (in development)
• Sep 2026 — Step 4: retention manager — ages recordings out per camera and keeps the volume from filling, deleting oldest-first in small batches and never touching the file being written. Clears 20,000 files in under 8 seconds. (in development)
• Sep 2026 — Step 3: camera database and fleet supervisor — every enabled camera recorded at once, with staggered, jittered startup so a shared outage does not become a synchronised reconnect storm. (in development)
• Sep 2026 — Step 2: single-camera recorder running on a supervised media-server subprocess, writing segment files with a health watchdog. (in development)
• Sep 2026 — Step 1: single-camera ONVIF control layer — network discovery, profile and stream-URI retrieval, and a capability probe, with a test suite. (in development)

Next: a camera database and per-camera state machine to take it from one camera to ten with staggered startup, then the retention manager.