Every guide on AI powered surveillance skips the capture point. It is the detail that decides whether the system fits cameras you already own.

It is a system that applies a detection model to camera pixels in real time, then routes the resulting events to a human or a rule engine. The parts that get discussed in articles are the model (person, vehicle, package, anomaly) and the events (alerts, dashboards, escalations). The part that almost never gets discussed, and which decides whether the system can exist on cameras you already own, is the capture point: the physical place where the AI actually reads pixels from. Per-camera IP streams, purpose-built AI sensors, and DVR HDMI multiview are three different capture architectures with radically different install cost, compute shape, and compatibility envelope.

Every DVR and NVR made in the last fifteen years renders a mosaic of camera tiles to an HDMI port so a guard can watch a monitor. The signal at that port is a 1080p composite frame with every camera already drawn into a grid (typically 2x2, 3x3, 4x4, or 5x5). A device that taps that port gets access to all 25 cameras at once with a single HDMI cable. It does not need to know the cameras' IP addresses, it does not need ONVIF credentials, it does not need the DVR vendor to expose an RTSP endpoint. That is why retrofit AI is even possible on the vast majority of existing apartment, jobsite, and commercial DVRs: you stop fighting the network and you start reading the picture the DVR is already drawing.

Five physical motions. One: unplug the HDMI cable going from the DVR to the guard monitor. Two: plug that end of the cable into the Cyrano unit's HDMI input. Three: plug a short HDMI cable from the Cyrano unit's HDMI passthrough into the guard monitor. Four: connect ethernet to the Cyrano unit. Five: connect power. The guard monitor keeps showing the DVR's composite multiview continuously because the unit's passthrough is live. Total clock time on a running DVR, with everything handy, is under 2 minutes. The DVR is not rebooted. No camera is touched. No firmware is flashed. No network credential is entered anywhere.

On the device. The HDMI signal goes into a capture chip, the composite frame is decoded in RAM, and a detection model runs on the unit's local accelerator. The original full frame and the 24 other tiles of unrelated feeds never leave the building. Only event artifacts leave: a ~18 KB thumbnail crop of the triggering tile, a ~220 KB six-second clip of that tile around the detection, and a small structured metadata blob (zone id, dwell seconds, time, class, confidence). Average off-property traffic per event is around 240 KB. There is no continuous upload of full frames, and there is no biometric index (no face embeddings, no license plate strings, no gait vectors) constructed at any stage.

The DVR has already done the hardest part. It decodes every camera's stream, scales it to a tile, positions the tile in a grid, and re-encodes the grid as one HDMI frame. The Cyrano unit receives that composite frame and treats each tile as a region of interest. One inference pass per composite frame processes all 25 tiles in parallel. A per-tile zone mask is applied so the on-screen clock, per-tile camera name strip, and DVR channel bug do not confuse the detector. If the operator switches the DVR to fullscreen on one camera during an incident, the unit re-scopes to that single camera at full resolution, so accuracy actually climbs during active events rather than dropping.

Because in the real buildings Cyrano deploys into, RTSP is unreliable as a capture architecture. The DVRs are a mix of rebranded Hikvision, Dahua, Lorex, Uniview, Swann, and LTS units. Some expose RTSP only when a specific proprietary app has negotiated a session. Some put RTSP behind a firmware flag the integrator forgot to enable. Some rotate credentials on reboot. Some cap concurrent RTSP sessions so low that adding an AI client bumps the guard's phone app off. Analog cameras on BNC inputs do not expose RTSP at all; the DVR is the only component that ever sees them as pixels. HDMI multiview bypasses all of that. If the guard can see the feed on the monitor, the adapter can run inference on it.

Exactly three artifacts, and nothing else. One thumbnail crop, roughly 320x240, of the tile that fired, roughly 18 KB. One short clip, six seconds, of that same tile bracketing the detection, roughly 220 KB. One JSON metadata object describing the event: zone identifier, dwell in seconds, wall-clock time, class (person, vehicle, package), confidence score, and the tile index within the DVR layout. Nothing else leaves. No full-resolution multiview frame, no continuous stream, no face embedding, no plate string, no audio, no telemetry from the 24 other tiles that did not fire. Average total bytes per event is about 240 KB. Delivery target is a WhatsApp thread with on-call staff; end-to-end latency from composite frame to phone buzz is about 1.1 seconds in typical deployments.

The install procedure includes a one-time calibration pass: the unit captures a reference composite frame, the installer confirms which tile is which camera (a dropdown per tile), and the system records the pixel rectangles for the DVR clock, the per-tile camera name strip, and the channel bug. Those rectangles become zero-mask regions before the detector sees the frame. If the DVR layout is later changed (3x3 to 4x4, or a channel is renamed), the calibration is re-run in under a minute from the property staff's phone. The model itself is unchanged; only the per-tile coordinates move.

Two reasons. First, no frames are being shipped to a cloud ingest, so the vendor is not paying for ingest, storage, GPU inference, and egress per camera per month. Second, a single edge device covers up to 25 cameras off one HDMI input, which amortizes the device cost across the whole property instead of per camera. At a typical 16-camera property, Cyrano works out to roughly $13 per camera per month on a whole-property price of $200. Per-camera AI cloud platforms are usually priced between $20 and $120 per camera per month, because the per-camera cloud compute is the product.

Both. The adapter is agnostic to what the DVR is recording. If a feed makes it into the DVR's HDMI multiview (and essentially all feeds do, that is the point of a DVR), the adapter can run inference on it. That includes analog 960H and HD-TVI cameras on BNC inputs, PoE IP cameras on the NVR's built-in switch, and wireless cameras paired to the recorder. The DVR is the normalization layer. The adapter only has to understand HDMI, and HDMI is the one signal every modern DVR has to emit to be sellable.