AI powered surveillance at 25 cameras is a batching problem, not an inference problem.

Inference is almost never bound by raw work; it is bound by per-call overhead. On small models (the person, vehicle, package detectors most surveillance systems actually use), a single 1920x1080 forward pass costs roughly the same wall-clock time as a single 640x384 forward pass because the fixed costs (kernel launch, memory binding, output decode) dwarf the flop count at these resolutions. So a system that runs 25 separate inferences on 25 streams pays 25x the overhead. A system that runs one inference on a frame that already has 25 tiles composited into it pays that overhead once. On a Cyrano unit, one forward pass across a 5x5 composite completes in ~18.4 ms. Run sequentially as 25 small inferences on the same silicon, that same scene costs ~200 to 450 ms. Same model, same silicon, same cameras. The only difference is where the batching happened.

Inside your existing DVR or NVR, before Cyrano is even involved. Every DVR on the market drives a guard monitor over HDMI by rendering a composite multiview: for a 16-camera property, that is typically a 4x4 grid at 1920x1080; for a 25-camera property, a 5x5 grid with tiles around 380x216 each. The DVR's composite is the batch. Cyrano plugs into the HDMI output, decodes the composite frame to RGB, feeds it into one forward pass, and slices the output detection tensor by tile coordinates to figure out which camera each bounding box belongs to. The batching cost is paid by the DVR's hardware compositor, which is a dedicated chip optimized to do exactly that. The AI device spends zero cycles stitching frames; they arrive already stitched.

They can in principle, but the deployment shape forbids it. A cloud vendor ingests each camera as a separate RTSP stream, arriving at the data center as independent TCP flows with independent timestamps. To batch them, the vendor would have to buffer each stream, wait for frames at matching wall-clock moments across all N streams, composite them into a grid in software, run one inference, then demux the results. That adds buffering latency (typically 100 to 400 ms), fails the moment any one camera drops or stutters, and wastes GPU memory staging intermediate composites. The DVR-HDMI path avoids all of that because the compositing was done deterministically by the DVR at frame-time, on silicon designed for it. Cyrano inherits that work for free. A cloud pipeline cannot.

About 0.72 milliseconds per camera per frame. The math: one forward pass covers all 25 tiles in ~18.4 ms. Divide by 25 cameras and the amortized per-camera cost is 18.4 / 25 = 0.736 ms. Compare that to a per-stream architecture running the same detector on the same hardware: each stream costs ~30 to 50 ms of wall-clock time because each pays its own kernel launch, memory binding, and output decode overhead. Twenty-five streams at 30 ms each is 750 ms of compute per round, or a hard cap of ~1.3 frames per second if serialized. The same silicon in the Cyrano deployment runs at roughly 30 frames per second across all 25 cameras. The compute cost difference is not a model choice; it is an architecture choice.

Yes, up to 25 cameras per unit, which covers the overwhelming majority of Class B and C multifamily properties and nearly every standalone construction site. The 25-camera ceiling is not a compute ceiling; it is a pixel-density ceiling. When tiles drop below roughly 380x216 each (the size at which a person at typical camera distances is still a detectable number of pixels tall), detection accuracy starts to degrade. For properties with more than 25 cameras, the right answer is usually a second Cyrano unit tapped into a second DVR output or a second DVR, not a bigger single unit. Per-camera cost stays constant, because each unit is doing one-pass batching across its own 25-tile composite.

Both. The approach is agnostic to camera protocol because Cyrano never reads camera streams directly. It reads the DVR's HDMI output, which is a post-decoding, post-compositing signal. The DVR has already converted whatever arrived on its BNC or RJ-45 inputs (analog NTSC, PoE H.264, ONVIF RTSP, whatever mix the property happens to have) into raw RGB pixels in the composite grid. That means the inference pipeline does not care whether a given tile originated from a 2014 analog BNC dome or a 2024 PoE 4K bullet; by the time it hits the HDMI output it is just pixels in a rectangle. Mixed-brand, mixed-generation camera installations (common on older multifamily) work without firmware changes, without RTSP credentials, and without ONVIF negotiation.

The frame changes from a 5x5 grid (25 tiles) to a 1x1 grid (1 tile), and the inference pass becomes a one-camera high-resolution pass instead of a 25-camera low-resolution pass. Cyrano detects the layout change from the HDMI signal, switches the tile-slicing coordinates accordingly, and continues to run one forward pass per frame. The per-frame cost stays roughly the same (~18 ms); what changes is the effective camera coverage during the zoom. The layout change is recorded in every event payload as layout_id (for example 5x5-std vs 1x1-std), so an integrator can always reconstruct which compositing mode was active when an event fired. The batching never stops; it just operates on a different grid shape.

Per-camera cloud services run one inference pipeline per stream, in a data-center region, paid for by the camera. That model prices at $20 to $120 per camera per month, because the vendor has to pay for a GPU slice that never sees another camera's pixels. Cyrano runs one inference pipeline for up to 25 cameras, on a device already physically sitting at the property, plugged into the DVR. The per-camera math falls to roughly $12.50 per camera per month at a 16-camera property on the $200 per month plan. The cost compression is directly downstream of the batching architecture; it is not a temporary promotional price. You cannot get to that price point if every camera triggers its own inference.

No, for the classes this market actually uses. The dominant detectors for property surveillance (person, vehicle, package, and a small set of pose/action heads) are trained and evaluated on crops at roughly the same scale a DVR tile produces (~380x216 or larger). A 4K per-camera inference does not help detect a trespasser any earlier; it helps read a license plate, which is a narrow subset of deployments. For the 95 percent of multifamily, industrial, and small-business surveillance workloads that are about 'is there a person in a restricted zone right now,' the composite tile is already above the accuracy-saturation resolution of the model. Extra pixels upstream are wasted on a detection task the DVR tile already solves.

The compositing step is not proprietary — every DVR already does it because guard monitors need it. The inference step uses standard detectors running in a standard runtime on a small edge accelerator; it is not a custom model architecture. What Cyrano owns is the installed integration: the HDMI capture path, the overlay-mask handling that zeroes out the DVR's clock and channel-bug glyphs, the layout_id cache that remembers each DVR compositing mode, and the zone and dwell logic that converts raw detections into a 50-to-1 compressed alert stream. The batching insight itself is architectural and available to anyone willing to build against an HDMI capture point instead of 25 separate RTSP streams.

About 1.1 seconds in typical deployments. Budget: ~2 ms HDMI frame decode to RGB, ~18 ms inference across all 25 tiles, ~4 ms zone-rule application and packet building, then the dominant remaining time is the network hop to the cloud control plane and the WhatsApp push delivery. The inference is already the cheapest part of the end-to-end path; shaving milliseconds off it would not change the user-visible latency because the last hop (mobile push delivery) dominates. The batching is what lets the inference be cheap enough that it does not even register in the total latency.

No. You need a DVR or NVR that drives an HDMI output at 1920x1080 (effectively every DVR shipped in the last decade) and an HDMI cable. That is it. The Cyrano device plugs into the DVR's HDMI out and passes the signal through to the guard monitor with negligible latency on that pass-through path, so no existing workflow changes. Install time is about two minutes on a running DVR. Cameras stay, wiring stays, the DVR stays, the guard monitor stays. The only thing that gets added is the device that harvests the free batching the DVR was already doing.