You bought a local NVR to stay off the cloud. Then the AI add-on put you back on it.

Because almost every AI bolt-on for consumer NVRs is architected as an RTSP consumer that lives somewhere else. The common shapes are: a mobile app that pulls camera feeds through the vendor's SaaS (footage transits their cloud even if it's also stored locally on the NVR), a Wi-Fi bridge that uploads motion clips for cloud inference, or an enterprise VMS that replaces the NVR entirely. Each one either opens a port, ships video off-site, or forces you to rewire cameras out of the NVR's PoE switch and into a different box. The only path that keeps everything local is inference that runs on a unit physically attached to the NVR, reading a signal the NVR is already emitting on its own. The HDMI multiview output is exactly that signal.

RTSP is the standard when you're willing to pay three costs: (1) credentials that must be stored, rotated, and scoped per camera; (2) network topology changes, because an RTSP consumer needs a route to each camera or to the NVR's RTSP proxy; and (3) the fragility of a vendor-specific stream URL format that breaks on firmware updates. HDMI avoids all three. The NVR is already decoding every camera into a composite frame for the monitor on the office wall. Tapping that HDMI port with a pass-through capture means one cable, no credentials, no port forwarding, no per-camera stream URLs, and zero changes to the NVR configuration. The trade-off is that you see one composite frame instead of N individual high-resolution streams, which is fine for event indexing (the use case) and not for evidence export (still the NVR's job).

The NVR composites every camera into a grid, typically 2x2, 3x3, 4x4, or 5x5 depending on how many cameras are live and how the operator configured the display. That gives a hard ceiling of 25 tiles on one HDMI port, because 5x5 is the largest simultaneous multiview consumer NVRs render; past 25 cameras the recorder starts cycling groups of cameras through the slots on a timer. Each tile is a live view of one camera, scaled down, typically 384x216 or 480x270 at the 5x5 scale. On top of the tile grid, the NVR paints its own chrome: a clock strip along the top or bottom, a per-tile camera-name banner that reads something like 'Cam01 Front Door' or 'Mailroom Interior', and a small channel bug (CH1, CH2, CH3). On some models there's a red recording dot and a disk-status icon. All of that gets baked into the HDMI frame before it reaches the capture card.

A person-detection classifier that sees those burned-in overlays will score false-positive bounding boxes on them. The colon glyph inside 14:32:07 looks like a tiny vertical person at the right scale. The letterforms of 'Mailroom Interior' score as low-confidence text-shaped objects. The red recording dot scores as a small object. Run the classifier on the raw HDMI frame and the event log fills with phantom detections on chrome pixels, not camera pixels. The fix is a per-layout overlay mask: a binary rectangle list that the pipeline paints black on the composite frame before any classifier runs. It's keyed by layout_id (4x4-std, 5x5-std, 3x3-std, 1x1-std, custom) because the chrome moves when the operator changes the grid. Store one mask per layout the NVR can produce, swap at inference time when layout_id changes, and every event after the swap is scored on pixels inside a tile. This is the preprocessing step every other HDMI-based analytics approach gets wrong, which is why people assume HDMI is unusable for AI.

That's a layout change, usually 4x4-std to 1x1-std or similar. The Cyrano engine notices the tile geometry changed, loads the overlay mask for the new layout_id out of its local cache, and resumes inference on the new grid. The event record written after the swap carries the new layout_id in the overlay_mask field, so the mask state at index time is reconstructable months later. The cache is populated at install time from a one-time layout sweep (the installer walks the NVR through each layout it supports). If an operator creates a brand-new custom layout that the cache hasn't seen, the engine flags it, captures a reference frame, and the mask gets computed on-box before inference resumes.

Any NVR that drives a monitor drives Cyrano, because the interface is the HDMI port, not a vendor-specific API. Confirmed on Hikvision DS-7xxx NVRs, Dahua NVR4xxx / NVR5xxx, Lorex N-series, Reolink RLN series, Uniview NVR301/302, Swann NVR-7xxx, Amcrest NV4xxx, ANNKE, EZVIZ NVR, Bosch DIVAR, Honeywell Performance series, Panasonic WJ-NX200/400, Samsung SRN, and the long tail of rebrands. Mixed fleets work the same way because the overlay mask is keyed per recorder model at install, and the event index upstream of the mask doesn't care which mask produced a given event. A property with one Hikvision NVR and one Dahua NVR renders a single unified search experience.

No. The Cyrano unit sits in pass-through: HDMI in from the NVR, HDMI out to the monitor the guard or property manager was already watching. The NVR sees one HDMI sink, exactly as it did before. No config change, no firmware change, no port opened on the NVR's LAN side. The monitor stays lit with the same multiview. If you unplug the Cyrano, the monitor goes straight back to direct-from-NVR. This matters for two reasons specific to local-NVR buyers: warranty and compliance. The NVR vendor can't void a warranty over a passive HDMI sink, and the compliance posture of 'local-only footage' doesn't change because nothing leaves the NVR.

Different problem. Frigate and CodeProject.AI are full NVRs; they want RTSP streams and they replace (or parallel) your existing NVR. That's a fine architecture if you're building a home lab from scratch. It's a bad architecture if you already have a Lorex or Hikvision NVR installed, cabled, and under warranty, because you'd be rebuilding the recording layer just to add the inference layer. The HDMI approach keeps the NVR as the recording layer (warranty, retention, evidence export all untouched) and adds inference alongside it. The event index writes back out to webhooks or a dashboard; it doesn't try to take over storage. If you're on Frigate and happy, stay on Frigate. If you have a consumer NVR and don't want to replace it, the HDMI path is the least-invasive option.

Up to 25 per HDMI tap, because that's the 5x5 multiview ceiling consumer NVRs render simultaneously on one output port. Past 25 cameras the NVR starts cycling groups through the slots on a timer, which breaks continuous per-camera inference. Properties with more than 25 cameras typically have two things: either the NVR already has a second HDMI output (most mid-range and higher NVRs do, labelled 'HDMI2' or 'SPOT'), or they're running multiple NVRs. Either way you add a second Cyrano unit on the second HDMI output, and both event streams land in the same index keyed by the property field. The 25-tile ceiling is per HDMI port, not per property.

Only the event row by default, and only if you want it to. The composite frame is cropped per tile, masked, classified, and discarded on the Cyrano unit. What gets written out is a nine-field JSON record per event (tile label, tile index, tile coords, property, layout_id, overlay_mask, event_class, iso8601 timestamp, latency_ms) plus a 480x270 thumbnail. You can route that to a local webhook for a PMS or ticketing system and have nothing leave the LAN. You can also route it to the Cyrano dashboard for portfolio search, in which case only the JSON record and thumbnail go over the wire, not the clip. The clip itself stays on the NVR's own disk under whatever retention policy you already have. That's the actual definition of 'local' that local-NVR buyers were asking for: storage local, inference local, and a choice about whether the event row syncs for cross-site search.

Three checks, then a decision. Check 1: confirm the NVR has an HDMI output that's currently driving a monitor (almost certainly yes). Check 2: walk the NVR through the layouts you actually use day to day (fullscreen, 4x4, 3x3) and write them down; those become the layout_ids the overlay mask has to cover. Check 3: count cameras; if you're over 25 you need a second HDMI output or a second unit. If all three check out, the install itself is under two minutes of physical work: HDMI out of the NVR into Cyrano HDMI-in, HDMI out of Cyrano into the monitor, one ethernet, one power. Everything else (overlay mask calibration, tile label OCR, event classifier loading) happens on the box without touching the NVR.