Rutba Vision: video surveillance for camera networks past the size one recorder copes with

First published on rutba.io.

A handful of cameras is a product you buy. A hundred and fifty, writing terabytes a day, is an operations problem, and it fails the same ways each time. The disks fill and recording silently stops. The event database bloats until queries time out. A camera's clock drifts and its footage stops counting as evidence. And one box is the whole system, so one failure is an outage. Rutba Vision is built around those failures, and this is how.

The same software at every size

Every machine runs the same node agent, and a site's nodes take three roles. Edge nodes hold the cameras: the relay keeps the only connection to each camera and fans it out to the recorder, live view, detection and RTSP out. Analysis nodes run the AI and codec work, and are added as the analytics grow. The core runs the Vision Bus, the index, the API and the console. A branch with a handful of cameras runs all three roles on one machine, and a large warehouse spreads them over several. Nothing changes but the node count.

Sites stand alone, and HQ sees them together

Each site records and analyses its own cameras and keeps its own footage. Sites dial out to a hub at HQ over TLS, so no site needs an inbound port. Each uplink keeps a 30-day outbox that drains in order when the line comes back, and moves on only when the hub acknowledges, so an outage of days loses nothing.

The hub holds the sites' events, incidents, tracks, thumbnails and health in one store, and fetches footage from a site only when someone opens it. A regional hub can uplink to a national one, so the picture follows the way the organisation is run.

Recording is the floor, not the feature

The recorder copies each camera's own stream into self-contained fMP4 segments and hashes every file with SHA-256 as it writes. Nothing is decoded on the way, so recording costs packet handling rather than a GPU. Segments are written to a spool and renamed into place, so a crash never leaves half a segment in the catalogue, and each one plays on its own.

Nothing above the recorder can stop it. Detection, AI, indexing and distribution can all be down, and footage is still written, catalogued and kept. Cameras are assigned to nodes rather than tied to one: a node silent for 15 seconds loses its cameras to the others, and recording resumes there.

The everyday failures are dealt with where they happen. Each edge node's storage guard enforces retention and free space itself. Metadata is kept in one file per day, so expiring it is deleting a file and nothing bloats. Video is stamped in UTC as it arrives, so footage never depends on a camera's clock, and the clocks are still checked on a schedule.

AI where it earns its keep

Detection is switched on camera by camera, each with its own stream, resolution and frame rate. A loading bay can watch for theft and loitering, while a corridor that only needs recording costs nothing but disk. Zones mark what matters, such as a doorway or a restricted aisle, and masks leave out a public pavement or a swaying tree. Flicker that never stops, such as an on-screen clock or a blinking LED, is learned and left out of motion without a mask.

Inference runs through one runtime on a CPU, an Intel GPU or an NVIDIA card, and the default detectors are permissively licensed. Search takes plain language: ask for a red car at the north gate after 10pm yesterday, and it reads the time, the camera, the colour and the object out of the question. The AI runs on site, so the footage stays there.

Evidence that holds

An evidential hold on a camera's footage is never deleted, whatever the retention setting or the pressure on the disks. An export is the segments joined without re-encoding, with a manifest of SHA-256 hashes saying who exported it and when. One command reports every camera's clock against the server, so whether the cameras are in sync is a question with an answer.

Feeds the systems you already run

Video walls and other VMS pull RTSP from Rutba Vision instead of from the cameras. Incidents open tickets in ERP systems and service desks over signed webhooks, and building systems get doors and alarms over MQTT. Cameras are declared in one file rather than set up in forty clicks nobody can review.

The bus, the relay, the recorder, the store, the search and the console are our own code, and each borrowed engine sits behind one module of ours, so replacing it means replacing that module.

On your site

Rutba Vision is the one Rutba service you host yourself. Your team can run it on your site, we can run it for you with the footage still on your premises, or a chain of branches can each run their own nodes and join at a hub. Whichever it is, the hardware and the footage are yours.

If you have run a large camera estate, which of these failures reached you first? The product page is at rutba.io/services/vision.