Video surveillance AI is a tile-resolution budget problem. Nobody on the SERP prints the budget.

It is a model that reads pixel frames off a camera feed (or off a recorder's composite multiview) and emits bounding boxes labelled with a class such as person, vehicle, or package. Everything marketed as video surveillance AI reduces to that loop: a frame goes in, bounding boxes plus labels come out, and a downstream filter decides whether a bounding box becomes an alert. The interesting question is not the loop; it is the frame the model is given in the first place.

A detection model cannot classify pixels that were never in the input. If a person needs at least 60 pixels of height to register reliably and the tile they appear in is only 216 pixels tall, they have to occupy at least 28 percent of the tile's vertical space. If a licence plate needs 20 pixels of character height, and the tile is 270 pixels tall at 50 feet of depth, the plate glyphs land at roughly 3 to 5 pixels tall and no model, however good, will read them. Tile resolution caps the category of detections before any AI runs.

It sees a 1920x1080 frame made of sixteen tiles, each roughly 480x270 pixels, with a live clock burned into the top-right corner, a per-tile name strip burned along the top of each tile, and a channel indicator in one corner of each tile. That is the entire input tensor to the model. If the mask file for this layout (conventionally 4x4-std.mask on the Cyrano edge unit) is not loaded, the detector will fire phantom boxes on the clock digits and the name-strip letters. With the mask loaded, the detector sees only the sixteen camera crops.

It depends entirely on where inference lives. A per-stream architecture opens 25 RTSP sessions, decodes 25 H.264 streams, runs 25 forward passes per tick, and fans the boxes back to a dashboard. A composite-frame architecture (the one Cyrano uses) opens one HDMI capture, runs one forward pass on the single composite frame, and maps each bounding box back to its tile using cached coordinates. For the same 25 cameras the compute budget differs by roughly 25x. That ratio is the reason a side-channel edge unit can run on a $450 accelerator instead of a rack.

Person detection, vehicle presence, package drop, loitering-dwell, tailgate at a vestibule, zone entry, and crowd density all survive 480x270 tiles. They rely on blob-scale features. Detection classes that need fine-grained per-pixel reads (licence plate character recognition at distance, facial recognition at distance, reading small printed text on a package label) do not survive. For those, the operator has to drill the DVR to a 1x1 layout so the full 1920x1080 is dedicated to one camera, and the model re-reads that single tile at full resolution for the duration of the fullscreen.

Not architecturally, though many vendors choose it for convenience. A detector small enough to run at 30 fps on a $300 accelerator does not need a datacenter. The reason cloud-hosted video surveillance AI exists is that sending frames to a GPU in a datacenter is easier to sell than shipping a box. The reason edge-hosted video surveillance AI exists is that shipping a box is easier to operate: frames never leave the property, the privacy story is simpler, the bandwidth bill is zero, and a dropped internet link does not break detection.

DVRs burn graphics into their HDMI output that are not part of any camera feed: a live clock, a per-tile name strip, a recording indicator, sometimes a weather widget. If a detector sees that composite without subtracting those glyphs, it fires phantom detections on the text. The overlay mask is a polygon file computed once per layout at install (for example 4x4-std.mask, 5x5-std.mask, 1x1-std.mask) that blanks those regions in constant time. On a Cyrano unit the masks live at /var/lib/cyrano/layouts and are keyed by a hash of tile geometry plus corner anchors. Without this artifact a composite-input model is unusable. With it, the composite is cleaner than a raw per-stream input, because the model never sees any rendered chrome.

Four artifacts give a complete picture. First, the current active layout_id of the input (4x4-std, 5x5-std, 1x1-std). Second, the tile resolution that falls out of that layout. Third, the list of detection classes enabled at that tile resolution. Fourth, the mask file bound to the current layout_id. If all four are present and mutually consistent, the deployment is healthy. If any is missing (for instance a layout_id with no mask), detections will either be phantom-prone or entirely wrong. Cyrano publishes these artifacts as readable files under /var/lib/cyrano on the edge unit; a vendor that refuses to show them does not want you to know what its model is actually looking at.

Any recorder that outputs a standard HDMI multiview to a guard monitor is a valid input. In practice that covers Hikvision, Dahua, Lorex, Swann, Uniview, Annke, Reolink, Night Owl, Amcrest, Q-See, and the long tail of rebranded recorders shipped to multifamily and commercial in the last ten years. The layout router on the Cyrano unit does not match on DVR brand; it matches on tile geometry and corner anchors. If the DVR drives 1920x1080 with a recognisable tile grid, the AI works.

On the Cyrano edge unit itself, which sits on the HDMI line between the DVR and the guard monitor. Model weights, layout cache, mask files, the filter stack, and the event queue all live on local storage. The only thing that leaves the unit is an already-filtered event payload (thumbnail, metadata, camera name, zone, dwell seconds, layout_id, latency_ms) sent over the customer's network to their WhatsApp or SMS endpoint. Raw frames never leave the property.