Running many security video monitoring systems is a different problem from running one.

The plural is the whole problem. A single-site operator has one recorder, one guard monitor, and one camera count to worry about. A multi-site operator has 3 to 50 of each, often on different DVR brands with different layouts, and usually with different people answering the phone at each site. The top search results for this phrase quietly assume the single-site case and sell you one kit. The moment you run more than one, every question shifts: how do alerts deduplicate across sites, how do you compare event counts site to site, how do you tell a portfolio dashboard that a person flagged at property A tile 3 at 11:04 looks like the same person flagged at property B tile 7 at 11:07. None of that is possible unless every event from every unit carries the same structured payload. That is the thesis of this guide.

Nine fields plus a thumbnail, emitted as JSON. tile.label is the camera name as the recorder already overlays it (for example "Loading Dock NE"). tile.index is the row-major position in the multiview grid starting at 0. tile.coords gives x, y, w, h in the captured frame so you can reproduce the crop. property is the site identifier you assigned at install. layout_id is the recorder's layout like 4x4-std or 5x5-std. overlay_mask lists which DVR overlays were masked before inference (typically clock + cam_name_strip + channel_bug). event_class is the detection label (person_in_zone, vehicle_dwell, loiter, tamper, etc.). iso8601_ts is the recorder-clock timestamp. latency_ms is capture-to-delivery time. The thumbnail is a 480x270 JPEG crop of the relevant tile. Every Cyrano unit in the portfolio emits this identical shape.

If every event everywhere has the same ten keys, a portfolio SQL query is trivial: select property, event_class, iso8601_ts, tile.label from events where event_class = 'person_in_zone' and iso8601_ts between T1 and T2 and property in (A, B, C). Without the structured payload you are stitching together CSV exports from 8 different NVR software clients by hand, matching camera names that are inconsistent, and guessing clock drift. With the payload, cross-site correlation is a two minute SQL query or a Retool dashboard. This is the difference between running multiple isolated monitoring systems and running one federated one.

Every DVR stamps three things onto the HDMI multiview before sending it out: a running clock, a per-tile camera name strip, and a channel bug or mode badge. If you ran object detection naively the model would fixate on those pixels because they change every second. Cyrano masks them before inference and records which ones were masked as overlay_mask on the event. At portfolio scale the useful property is that identical recorder models share the same overlay_mask template. If you have 10 Hikvision DS-7716 recorders running 5x5-std, one overlay calibration applies to all 10. You do not calibrate site by site, and you have a paper trail proving the mask was applied every time.

One unit per recorder. Each unit covers up to 25 camera tiles pulled from a single HDMI multiview. A 4x4 layout covers 16 tiles. A 5x5 covers 25. A site with two recorders (north wing, south wing, for example) needs two units. A 12-building portfolio where each building runs a single DVR needs 12 units. Because the event shape is identical across units, the number of units does not change the downstream plumbing. A new property added next month drops into the same event pipeline on the same schema.

Yes. Supported recorders include 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 white-label rebrands. The recorder handles its own layout and overlay conventions. Cyrano detects the layout_id at boot, masks the correct overlays, and emits the same event shape regardless of brand. A portfolio mixing Hikvision at six properties, Dahua at three, and Lorex at one produces a single unified event stream with no per-brand integration work.

Three common patterns. First, a single WhatsApp group for the regional manager plus the on-call operator at each property, where every event routes with property name in the first line so on-call can triage at a glance. Second, a webhook into an existing incident management tool (Opsgenie, PagerDuty, or a Retool-backed dashboard) where routing rules decide who gets paged based on property, event_class, and time of day. Third, a hybrid where the webhook feeds a portfolio dashboard and the WhatsApp delivery doubles as a per-site notification for property staff. Because the event payload is identical across units, any of these patterns is a matter of configuration, not engineering.

Each unit has its own latency budget: 5 to 15 seconds end to end, with median around 7 to 8 seconds. Running 12 units does not slow any individual unit because each one is edge-local, inferring on its own frames, and shipping its own events. The portfolio stream is the union of per-unit streams. If one property's uplink is congested, latency_ms on that site's events climbs while neighboring sites stay fast. The metric is visible on every event which means you can chart p50 and p95 latency per property and detect a slow uplink before staff notice missed alerts.

iso8601_ts on every event is the recorder's own clock as captured from the multiview. Clock drift between recorders is real and matters for correlation. The simple operational answer is to NTP every recorder to the same source. The useful product answer is that Cyrano records the recorder's clock and its own wall clock at capture, so a portfolio dashboard can compute per-site drift from the difference and flag recorders that have walked more than a few seconds away from reference. Drift then becomes a maintenance ticket, not a silent source of bad correlation.

Video frames stay on the Cyrano unit sitting next to the recorder. Inference is edge-local. What leaves each property is the structured event payload (the ten fields above) plus a 480x270 thumbnail crop of the tile that triggered the event. There is no continuous outbound video stream and no cloud archive of raw footage. Long-form storage stays on the recorder, which was already doing that job before Cyrano arrived.

Under 2 minutes per recorder if a guard monitor is already connected, which it is on essentially every commercial DVR deployment. The HDMI cable 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 wall continues to show the same multiview because the pass-through preserves the signal. For a 12-site portfolio this means a one-day drive route per technician, not a multi-week integration project.