An AI surveillance system is decided by what it reads, not what it detects.

It means the system's input is not the set of individual camera streams. It is the single composite frame that the DVR already renders to HDMI for the guard monitor. A standard DVR draws a 1x1, 2x2, 3x3, 4x4, or 5x5 grid of tiles onto a single 1920x1080 frame and pushes that out its HDMI port so a human can watch all the cameras at once. On a monitor-first system, the AI watches the same frame the human would watch. It does not open an RTSP stream, it does not ask for camera credentials, it does not touch the DVR's network configuration. The video path is a passthrough: DVR HDMI out goes into the Cyrano unit, Cyrano HDMI out goes to the existing monitor, and the monitor keeps showing what it has always shown. The AI reads the signal along the way.

On a 1920x1080 HDMI output rendered as a 5x5 grid, each tile is 384 by 216 pixels. That is the per-camera resolution the detector gets. On a 4x4 grid of 16 cameras the tile is 480 by 270 pixels. On a 3x3 grid of 9 cameras the tile is 640 by 360 pixels. The pixel budget is why the detector is optimized for person, vehicle, and package at typical property distances, and it is why the system deliberately does not advertise face identification on distant tiles. A face at 30 feet on a 384x216 tile is roughly 20 pixels tall. That is not enough pixels for reliable identification, and pretending otherwise is how capability-first AI surveillance systems oversell.

Because person, vehicle, and package are silhouette-class detections, not fine-grained identification. A person at 20 pixels tall is still detectable as a person; you just cannot tell which person. A vehicle at 40 pixels wide is still detectable as a vehicle; you just cannot read its plate. For property security, the question is almost always whether a person or vehicle is in a zone that should be empty at a given hour, not who that person is. The monitor-first input architecture is a deliberate tradeoff: you give up per-camera resolution and get a system that runs on every DVR ever sold, with zero camera replacement cost. For properties that actually need plate-level or face-level recognition on a specific gate, the supported pattern is to route that one camera's HDMI output to a Cyrano unit directly (1x1 grid, full 1080p), in addition to the multiview unit covering the rest of the property.

Step 1, find the HDMI cable that runs from the existing DVR or NVR to the guard monitor. On most properties this is a single cable behind the desk or inside the gatehouse. Step 2, unplug that cable from the DVR side. Step 3, plug it into the Cyrano unit's HDMI out port. Step 4, plug a short included cable from the DVR's HDMI out into the Cyrano unit's HDMI in port. Step 5, plug in power. Step 6, on the property dashboard, capture a reference frame and confirm the tile layout (2x2, 3x3, 4x4, 5x5) and which camera is in which tile. Total wall-clock time is usually under two minutes for the physical install, and an additional five to ten minutes for the per-tile calibration. The monitor keeps showing the same multiview it always showed. Residents and staff do not notice anything changed.

Any DVR or NVR that emits a standard HDMI multiview to a monitor, which is essentially every unit shipped in the last decade. Verified on Hikvision, Dahua, Lorex, Swann, Uniview, Amcrest, Q-See, Reolink, Annke, ZOSI, and a long tail of rebadges of those platforms. The failure modes are narrow: HDCP-protected outputs (almost never present on security DVRs, but occasionally on hybrid retail-and-signage devices) and analog-only BNC outputs on very old DVRs with no HDMI port at all. For the BNC-only case the fix is a $40 BNC-to-HDMI converter in front of the Cyrano unit. HDCP is the only hard stop, and in four years of deployments we have not encountered one on a property-grade DVR.

Three concrete reasons on deployed properties. First, most property managers do not know the DVR admin password. The camera installer set it up, left the building, and either the password is on a sticky note that has since been thrown away or it is written in a contract binder nobody has opened since 2019. RTSP requires that password. HDMI does not. Second, opening RTSP streams requires putting a new device on the same network segment as the DVR, which often requires IT or landlord involvement on properties that have ten different tenants on the same building network. HDMI is electrically isolated from the network. Third, RTSP per camera means 16 or 25 network connections at 1080p each, which is 40 to 60 Mbps sustained on the LAN. HDMI is a single wire with zero network load. Monitor-first solves all three problems by refusing to be on the network at all.

The unit has a 4G cellular modem with an eSIM that the unit uses to send event payloads and receive configuration updates. No property Wi-Fi, no property Ethernet, no camera network access. What crosses the property boundary: roughly 240 KB per delivered HIGH event (an 18 KB JPEG thumbnail, a 220 KB H.264 clip of about six seconds bracketing the detection, and a 612 byte JSON metadata object). Nothing else. No continuous upload of the multiview frame, no face embedding, no plate string, no audio, no live stream. The raw 1920x1080 multiview never leaves the building. That egress contract is what has made Cyrano approvable on privacy-sensitive properties where cloud AI surveillance is not.

The HDMI signal from the DVR is almost always 30 FPS, sometimes 25 FPS on European-region DVRs, occasionally 15 FPS on very old units that were configured for low-bandwidth remote viewing. The detector samples that signal at 1 FPS for the full 25-tile grid, which gives each tile one inference pass per second. That is sufficient for person, vehicle, and package detection at property distances (a person takes several seconds to cross any meaningful zone), and it keeps the per-unit inference budget within the $450 hardware cost point. Properties that need faster sampling on a specific camera get a second unit dedicated to that camera at 1x1 and the full 1920x1080 at a higher per-tile FPS.

During calibration the dashboard captures a reference composite frame and shows the installer a grid of numbered tiles (tile 1,1 through tile 5,5, or fewer depending on grid size). Next to each tile is a dropdown with the installer's camera names (front_gate, compactor_alcove, pool_deck, and so on). The installer tags each tile once. From that moment on, the system knows that tile [2,3] is compactor_alcove, and every event out of that tile carries the camera name on the payload. If the DVR layout is ever changed (a camera added, a channel renamed, the grid changed from 4x4 to 5x5), re-calibration is one button, captures a new reference, and the installer re-tags. No firmware flash, no model retrain.

Because public writeups are produced for three audiences and none of them need to know. Capability-oriented buyer's guides (Pelco, Avigilon, Coram) list what the model can detect, because that is what a demo sells. Policy pieces (Brookings, the ACLU) describe what the system could theoretically do, because the policy argument is at the capability level. Trend roundups repeat the phrase 'edge AI' and move on. The input architecture is the mundane operational question a property manager asks on day one: how do I plug this thing into what I already have. That question has a specific answer, and the answer is different for every AI surveillance system on the market. Almost none of them tell you until you are already on a procurement call. This page is the part we wish we had been able to Google in 2022.