Adding AI to a legacy NVR: why protocol-level retrofit dies on a real fleet, and HDMI capture doesn't

Three things, usually all at once. First, the recorder is pre-2020 and was bought as a turnkey kit with whatever cameras the installer had on hand, so the fleet is heterogeneous (often three or four camera vendors on one NVR). Second, at least one batch of cameras is EOL: the manufacturer no longer ships firmware updates and the cameras only support ONVIF Profile S (live video, no event metadata), or in some cases only the vendor's proprietary SDK. Third, the network the cameras live on is flat and the credentials were lost two property managers ago. Each of these breaks a protocol-level AI overlay (RTSP pull, ONVIF subscription, vendor SDK). HDMI capture sidesteps all three because it reads the recorder's local display output, which the recorder is already drawing whether anyone watches it or not.

Three failure modes show up reliably on legacy fleets. (1) Codec mismatch: an old camera streams H.264 baseline at 5 fps over RTSP and the AI overlay's decoder expects H.265 main. (2) Profile mismatch: the camera supports ONVIF Profile S (video only, no events) but the overlay subscribes to Profile T metadata and gets nothing. (3) Credential drift: the cameras were configured by an installer who is no longer reachable, the admin password was rotated by the NVR but never propagated to the cameras, and pulling RTSP from the camera directly returns 401. On a mixed fleet of 12 cameras, you might get 7 working over RTSP, 3 working over ONVIF with reduced framerate, and 2 that refuse both and only show up on the NVR's local UI. HDMI capture bypasses all of this because the NVR has already done the negotiation and is drawing every camera onto its multiview output.

The recorder draws every camera onto a multiview composite for its local monitor port. That composite is a single rectangular video frame, typically 1080p or 4K at 25 to 30 fps, divided into a fixed tile grid (2x2 for four cameras, 3x3 for nine, 4x4 for sixteen, 5x5 for twenty-five). The edge AI device reads the HDMI output, splits the frame back into per-tile crops using a grid template captured at install, and runs detection plus classification on each tile. The cameras never see the AI box. The NVR never sees the AI box. The network never sees the AI box (other than for outbound alerts). The retrofit is electrically isolated from everything inside the existing CCTV stack, which is the property of HDMI capture that survives a legacy fleet.

If the NVR has a working HDMI output that can drive a multiview to a wall display, yes. That covers basically every consumer and prosumer NVR sold in the past 12 years, including Hikvision, Dahua, Lorex, Reolink, Amcrest, Swann, Annke, Uniview, Q-See, Night Owl, Defender, EZVIZ, Foscam, Zosi, Anpviz, and the Hikvision OEM rebrands sold under hardware-store private labels. The two edge cases are (a) headless NVRs (no HDMI port, only network output) and (b) NVRs whose HDMI is hardware-locked to a single resolution that does not match a 16:9 multiview the AI box can sample. Both are rare on multifamily property installs. On a legacy installation by an integrator, there is almost always a wall display somewhere in the leasing office or maintenance closet, and that display's HDMI run is the input the AI box uses.

Three things, none of them load-bearing for incident detection. (1) Per-camera metadata that lives in the protocol layer: ONVIF event subscriptions, vendor-specific PTZ position, badge swipe correlation routed through the NVR's API. The HDMI box can read what the recorder draws on screen, which on most NVRs includes the camera label and timestamp overlay, but it cannot see protocol-level events. (2) Original-resolution video for the cameras that are downscaled in the multiview: a 4K camera shown in a 5x5 tile is sampled at roughly 384x216 by the AI, which is fine for person and vehicle detection but not enough for license plate reading. The fix is to put high-detail cameras (LPR, entry door) on a separate dedicated tile or an expanded multiview. (3) Direct PTZ control: the AI box does not move the cameras. Static cameras only. For most multifamily and small commercial deployments, none of these are problems. For a site that needs LPR plus PTZ tracking, the right answer is HDMI for the bulk plus a small ONVIF integration for the two cameras that need it.

You disable the auto-cycle. Every NVR that does multiview also has a static-grid mode where one tile assignment stays on screen until manually changed. The install procedure on a legacy NVR is: (a) log into the local UI, (b) set the HDMI output to a fixed grid (2x2 to 5x5 depending on camera count), (c) lock the assignment so each camera occupies a known tile, (d) capture a one-shot calibration frame on the AI box that records the pixel boundaries of each tile, and (e) the runtime split-and-classify logic uses that calibration. If the operator later rearranges the grid, the install procedure is re-run, which takes about 30 seconds. The auto-cycle mode is incompatible because the AI box would have to track which camera is in each tile across a moving target, which is solvable but adds complexity that isn't justified on a legacy install.

If the NVR can show them on the multiview, the AI box can see them. PoE cameras added after the original install (via the NVR's built-in PoE switch on the back panel) typically appear as additional channels on the same recorder and get tiles in the multiview. That is the whole point of routing through the NVR: whatever shows up on the wall display is what the AI sees. Mixed analog (BNC) and IP (PoE) cameras on the same recorder all composite to the same HDMI output. The AI box does not care which physical interface a camera came in on. This is the single biggest practical reason HDMI capture wins on legacy fleets: a property that has 6 analog cameras from 2014 plus 4 PoE cameras added in 2020 plus 2 wireless cameras pushed in last year cannot be retrofitted via RTSP at the camera layer because the wireless cameras only push to the NVR over a vendor protocol, but all 12 of them appear on the multiview.

Detection and classification do, alerts depend on the alert path. The AI runs on the edge box, on-site, with no cloud round trip for inference. So if the ISP goes down at 02:00, the AI keeps detecting incidents and writing them to local storage. The alert delivery (SMS, voice call) requires a working uplink. On properties where uptime matters, the recommended setup is the AI box plus a cellular backup uplink for alerts only (a few dollars a month). The full footage stays local and is unaffected. This is the opposite of cloud-camera systems where an internet outage means the cameras stop recording entirely.

On a single property with one NVR and a wall display already running, this is a self-install. Plug HDMI from the NVR's secondary output into the AI box, run an ethernet cable from the AI box to your network, and walk through a one-time grid calibration in the dashboard. About two minutes on site. The legacy fleet doesn't change anything on this front because the AI box doesn't touch the cameras or the recorder's configuration. On a portfolio with many properties, the same process is repeated per property and runs about half a day end-to-end including mounting and labeling. No new wiring, no firmware updates, no credential discovery on the cameras.

Cyrano is $450 one-time hardware plus $200 per month per property starting month two. Replacing the legacy fleet end-to-end (new IP cameras, new PoE switch, new NVR, new wiring on a multifamily building, plus an integrator labor week) typically lands between $50,000 and $100,000 per property, plus an ongoing cloud subscription. The pricing gap is the entire reason HDMI capture exists: 99 percent of the value of a smart-camera retrofit on a multifamily property is real-time alerts and natural-language footage search, and both of those can be delivered without touching the cameras themselves. The cameras you have are good enough to detect an intruder. They were not good enough to know they were looking at one.