Open source computer vision security camera projects all share one assumption. Half the real world breaks it.

The active, widely-used list in 2026 is: Frigate (the most popular AI-first self-hosted NVR, Coral TPU acceleration, Home Assistant integration), ZoneMinder (the 20-plus-year incumbent, Perl plus PHP, shared memory IPC), Shinobi (Node.js NVR launched around 2017, cleaner UI than ZoneMinder), Viseron (Python, flexible detector and tracker pipeline), Scrypted (TypeScript, strong HomeKit Secure Video bridge), Kerberos.io (containerized pipeline of agent, machinery, hub), and DeepCamera (LLM-driven agent with local VLMs like Qwen and SmolVLM). MotionEye and iSpy/AgentDVR still show up on older lists but MotionEye is unmaintained and AgentDVR is only partially open source. Every project above inherits the same input assumption: it expects per-camera access over RTSP or ONVIF.

Because they all grew out of the self-hosted NVR community, which grew out of the Home Assistant and homelab worlds, where the typical camera is a consumer IP cam (Reolink, Amcrest, Dahua, Hikvision IP-first lines, UniFi Protect). Those cameras expose RTSP directly, so early open source NVRs standardized on RTSP ingest. Frigate's camera config expects an RTSP URL per camera. Shinobi, ZoneMinder, Viseron, and Scrypted all expect the same. ONVIF is the industry standardization of that pattern. The category never had a reason to consider non-IP inputs because the community it served already had IP cameras. The fact that every roundup compares these projects on UI and AI accuracy but ignores the ingest assumption is how the category blind spot became invisible.

Three things that do not show up in homelab reviews. First, a large share of installed cameras in the US multifamily, small commercial, and gas station market are not IP cameras. They are analog, HD-TVI, HD-CVI, or AHD cameras wired over coax to a DVR. There is no RTSP to point Frigate at because the cameras never produced RTSP in the first place. Second, even when the NVR is IP-based, many vendor NVRs (Swann, Lorex, Night Owl, Q-See, Zmodo, Samsung SDR-series) expose RTSP on the NVR itself but not for individual cameras, or require firmware logins that the property has lost years ago. Third, per-camera RTSP access means per-camera credentials, per-camera network reachability, per-camera firmware compatibility. A 16-camera install becomes 16 separate integration problems. None of this is visible in a roundup that compares detectors on a matched dataset.

Not at production quality, and not maintained. The homelab community has posted hobby projects that plug a USB HDMI capture card into a Raspberry Pi, read the DVR's wall-monitor output, run OpenCV motion detection on it, and post alerts to a Telegram bot. These work for a demo on one camera. They break the moment the DVR repaints its UI in firmware (the time overlay moves, the channel bug shifts, the tile grid changes from 4x4 to 3x3 when a camera drops offline). None of them ship per-DVR-vendor overlay templates, EDID-based auto-detection, NPU-accelerated inference on the composite tiles, or a disciplined event pipeline. Cyrano's HDMI ingest is the only implementation at that tier of reliability today. Short version: the open source category did not build this, and that is the gap this page is about.

No, and it does not need to for detection. The HDMI composite is 1920x1080 for almost every DVR sold in the last decade, which gives 480x270 per tile on a 4x4 grid (16 cameras) or 384x216 per tile on a 5x5 grid (25 cameras). A native camera RTSP stream might be 1920x1080 or 3840x2160 per camera. For forensic zoom, the native stream is higher resolution. For live human, vehicle, and package detection, 480x270 per tile is more than enough. The YOLO and ViT models used for this class of classification work fine at that input size. Detection is not the constraint; pipeline reliability and install time are.

Paid is the right choice when total cost of ownership matters, which is almost always true outside a homelab. Frigate requires a server you build and maintain, per-camera RTSP access you negotiate with the DVR vendor, a Coral TPU or capable GPU you source, a detection config you tune per camera, a retention policy you set, a Home Assistant stack you operate, and a notification pipeline you wire. At a single home with five Reolink cameras, this is fun. At a portfolio of apartment buildings with DVRs from five different vendors and cameras nobody remembers the passwords for, it is a full-time job. Cyrano ships a device that autodetects the DVR from HDMI EDID, loads the right vendor overlay template, does the inference on-device, and posts to WhatsApp. The right question is not free vs paid; it is engineering time plus risk vs flat subscription.

Yes, and this is a valid pattern if you have both IP cameras and a legacy DVR on the same site. Frigate handles the IP cameras over RTSP with its usual detector pipeline. Cyrano reads the DVR HDMI composite and handles the analog or HD-TVI cameras. Alerts can be federated into the same WhatsApp thread or PagerDuty escalation. We have not tried to replace Frigate on IP-native sites because it is genuinely good at what it does. The claim on this page is narrower: the open source category skipped the DVR HDMI ingest path, so for that specific input Cyrano is the honest option today.

Frigate defaults to MobileDet SSD on Coral TPU, with optional YOLO variants via ONNX, TensorRT, or OpenVINO for GPU acceleration. ZoneMinder uses its older Perl-based pixel-diff analysis by default and supports a plugin that wraps YOLO through a Python helper. Shinobi wraps TensorFlow and a handful of YOLO checkpoints behind a plugin system. Viseron ships with CodeProject.AI, DeepStack, or YOLO pipelines depending on how you configure it. DeepCamera in 2026 has pivoted heavily toward local VLMs (Qwen, DeepSeek, SmolVLM, LLaVA, and YOLO26 released January 2026). Cyrano ships a purpose-trained human/vehicle/package classifier on the device NPU, tuned against actual DVR tile imagery (overlays, low-light noise, coax-era compression artifacts). The training data looks different from a benchmark like COCO because the input looks different.

Three quick checks. First, look at the cable. Thick coax with a BNC twist connector going into a DVR is almost certainly analog, HD-TVI, HD-CVI, or AHD; ethernet with RJ45 going into an NVR or POE switch is almost certainly IP. Second, check the camera model. Any Reolink, UniFi, Amcrest, Axis, or Hikvision IP-series model has RTSP out. A Swann, Lorex, Night Owl, Samsung SDR, or Q-See system sold as a DVR kit is almost always analog or HD-TVI on coax. Third, try curling an RTSP probe from your laptop: ffprobe rtsp://admin:password@[camera-ip]:554/Streaming/Channels/101. If you can authenticate against an individual camera IP, open source NVRs are viable. If the only IP that responds is the DVR itself and it refuses per-camera RTSP, the open source category is mostly unavailable to you.

We intend to open source the overlay-template format and a reference parser so that any DVR vendor or community hobbyist can contribute templates for new firmware. The inference model, the per-tile scheduler, and the device firmware are not open; the honest reason is that a lot of the per-tile robustness (handling overlay bugs, time drift, encoder artifacts, tile-drop events) is hard-won engineering that we do not want to give away while we are still the only people solving this input. The template format being open means that if Cyrano goes away, the templates do not strand the installs.