The security video monitoring system you already own is the tiled HDMI grid on the guard wall.

Three pieces of hardware that already exist: cameras (analog or IP), a recorder (DVR or NVR) that ingests every camera and writes it to disk, and a wall monitor connected to the recorder's HDMI multiview output that mosaics every camera into one tiled grid (commonly 2x2, 3x3, 4x4, or 5x5 layouts). That tiled HDMI signal is the security video monitoring system's actual visual artifact. It exists 24x7 whether anyone looks at it or not. Adding intelligence does not require new cameras, new wiring, or a new recorder. It requires reading the signal that the recorder already produces.

RTSP requires per-camera credentials, ONVIF compatibility, network reachability for every camera, and a per-stream decode pipeline. On a 25-camera site that is 25 separate negotiations and 25 decoders running. The DVR HDMI multiview is one signal. The recorder has already done the decoding, layout, and synchronization. One HDMI capture brings every camera into the inference engine in one frame, with the recorder's clock embedded. There is no firmware to flash on the cameras, no port forwards to open, and no credential rotation to coordinate. Cyrano captures the multiview, parses the layout id (for example 4x4-std or 5x5-std), and indexes each tile back to the camera name strip the recorder already overlays.

Every DVR adds three overlays onto the HDMI tiles: a clock readout, a per-tile camera name strip, and a channel bug or mode badge. If you ran object detection naively, the model would learn to fixate on those pixels because they change every second. Cyrano emits an overlay_mask field with every event listing which overlays were masked before inference, tied to the recorder's layout_id. A typical event reads overlay_mask = clock + cam_name_strip + channel_bug, layout_id = 4x4-std. This pre-empts any review challenge that the model fired on baked-in pixels rather than scene content. It also keeps a stuck DVR clock from generating a parade of motion alerts.

Up to 25 tiles per unit, off a single DVR HDMI multiview. That maps to recorders running 4x4 (16 tiles), 5x5 (25 tiles), or smaller layouts. Properties with more than 25 cameras typically have multiple recorders already, and add a Cyrano unit per recorder. The math here matters: 25 simultaneous inference streams off one HDMI input runs at a fraction of the cost and complexity of 25 RTSP decoders.

Inference runs on the Cyrano edge unit, sitting next to the recorder. Video frames stay on the device. What leaves the building is structured event metadata: tile.label (camera name), zone name, event class, dwell seconds, ISO 8601 timestamp, a 480x270 thumbnail crop of the relevant tile, overlay_mask, layout_id, and capture-to-delivery latency in milliseconds. Delivery is a WhatsApp message, a phone call, or a webhook. The recorder continues to handle long-form storage. Cyrano does not duplicate the archive.

Under 2 minutes on a recorder that already has a guard monitor connected. The HDMI cable that runs from the DVR to the wall monitor unplugs from the monitor, plugs into Cyrano's HDMI input, and a second HDMI cable from Cyrano's pass-through output goes back into the wall monitor. Network in, power in. The guard wall continues to display the same multiview because Cyrano passes the signal through. Inference begins on the captured copy within seconds of boot.

Compatibility is defined at the recorder, not the camera. Any DVR or NVR with an HDMI multiview output works, which includes Hikvision DS-7xxx, Dahua XVR and NVR, Lorex, Amcrest, Reolink NVR, Uniview, Swann, Night Owl, Q-See, ANNKE, EZVIZ, Bosch DIVAR, Honeywell Performance, Panasonic WJ-NX, and most rebranded white-label recorders. Camera mix can be analog over BNC, IP over PoE, or both, because the recorder has already normalized them into the multiview signal by the time Cyrano sees the frame.

5 to 15 seconds end to end. Capture frame, run inference, evaluate against the configured zones and event classes, build the event payload with tile thumbnail, deliver to WhatsApp or webhook. Latency_ms is recorded with every event so you can audit it. On a properly configured deployment, the median lands near 7 to 8 seconds. Anything above 15 seconds usually points to a network egress problem on the property's uplink rather than the inference path.

It can, and it can also feed one. The cheapest configuration is direct WhatsApp delivery to a property team that already responds to maintenance pings on the same channel. The next configuration is a hybrid: alerts route to an in-house operator during business hours and to an outsourced monitoring agency overnight, both consuming the same event stream. The most stable configuration we see at scale is a property staff group during business hours plus a paid central station after midnight, with the same Cyrano events feeding both endpoints. The system itself is the alert producer; the choice of who acts on it is operational.

Cyrano does not store long-form video (the recorder already does). Cyrano does not replace cameras. Cyrano does not access the cloud for inference. Cyrano does not police access control directly (it can hand off events to access control systems via webhook). Cyrano does not coach staff on what to do once they receive an alert. The product is intentionally narrow: turn the multiview signal that already exists into structured events, fast enough to act on.