DVR person and vehicle alerts: five brands, five formats, and the one surface that already unifies them.

Most modern DVRs and NVRs ship a feature that fires alerts only when the motion event is classified as a person or a vehicle, instead of firing for any pixel change in the scene. Hikvision calls it Motion Detection 2.0 or Smart Event. Dahua calls it IVS (Intelligent Video System) and includes Tripwire, Intrusion, and Object Detection rules gated on person or vehicle. Lorex and Reolink consumer models surface a Smart Detection toggle with separate person and vehicle switches. Uniview groups it under Smart Event. The common shape is: the DVR or the camera ISP runs an object model on the live frame, decides whether the motion was a person, a vehicle, or neither, and only fires the alert when one of the two classes is present. The pitch is the same across every brand, fewer false positives from leaves and headlights, but the implementation is different on every brand, and the alerts do not interoperate.

Because the moment your portfolio has more than one brand of DVR, your alerts stop composing into a single stream. Hikvision events leave the DVR as ISAPI HTTP callbacks with one schema. Dahua events leave as alarm.cgi pushes with a different schema. Reolink consumer NVRs only export to the Reolink mobile app and the email relay; there is no documented webhook. Lorex (which is hardware mostly built by Dahua) sometimes exports through the Lorex Cloud, sometimes not, and the local API moves between firmware versions. Uniview has its own SDK that very few integrators have ever touched. If you operate a 12-property portfolio with three brands of DVR across it, you end up running three different alert ingestion stacks, three different tuning consoles, and three different on-call playbooks. Most operators give up and just log into each property's local console when something happens.

It depends on the wire. On TVI, AHD, and CVI analog DVRs, the cameras send raw video over coax and the DVR's chipset runs the classifier on the decoded frame. On IP NVRs the camera's onboard ISP runs the classifier and sends the per-class label to the NVR as part of the metadata channel; the NVR aggregates and surfaces the alert. On hybrid recorders some channels are analog and some are IP, and the same alert UI on the NVR is being fed by two different classifiers under the hood. The user-visible feature looks identical, but the recall, the latency, and the failure modes are completely different. Camera-side P&V tends to have better recall because the classifier sees the un-recompressed frame; DVR-side P&V tends to have lower latency on alarm output because the event is already on the recorder. Neither is automatically better.

Three reasons. First, the classifier is tuned for a generic scene, not your scene. A loading bay at 3am with a passing truck looks different to the model than a quiet front entrance at noon, and the same threshold is applied to both. Second, almost every brand silently runs a pixel-difference motion gate before the classifier ever sees the frame, so the model is being asked to label a clip the motion engine already pre-filtered. Sub-threshold humans (a slow approach, a person hugging a wall, a low-contrast outfit at dusk) never make it to the classifier. Third, the alert rule is usually a flat 'person detected in this zone' with no time-of-day, occupancy, or behavioral context. The vendors who ship this feature are competing on box specs, not on the operations layer that turns the label into a usable phone call.

Sometimes, partially. Hikvision and Dahua both expose enough of an event stream that an integrator can pull P&V alerts off the DVR and forward them. The catches are real: the schemas drift between firmware revisions, the network path from the DVR to the cloud usually requires opening inbound ports the IT team will not approve, and the events still inherit whatever recall ceiling the DVR's motion gate set. On Reolink consumer NVRs and many Lorex models there is no documented push API at all, you are stuck with the mobile app and email. So a portfolio-level central pipeline built on per-brand event ingestion is buildable on the high-end vendors and not buildable at all on the consumer ones, which is exactly the wrong shape if your portfolio is mixed.

Every brand of DVR draws the per-class label directly onto the rendered HDMI multiview composite. Hikvision draws a small white sans-serif label like 'Smart Event: Person' near the bottom edge of the tile. Dahua draws a colored bounding box (green, blue, or yellow depending on class) with the class name in the corner. Lorex and Reolink overlay a small icon (a stick figure for person, a car icon for vehicle) inside the tile. Uniview writes the rule name in a fixed-width strip. These overlays exist because the DVR is generating them for the on-site monitor, so a security operator looking at the wall display can tell at a glance whether the alert is a person or a car. They are also rendered before the HDMI output, which means anything tapping the HDMI line inherits all of them automatically. A downstream classifier can OCR the label, snap it to the camera ID by the tile-grid template, and treat the brand's native classification as a free signal alongside its own model. This is the surface that does compose across vendors, because the DVR did the compositing for free.

DVRs render their multiview deterministically. The tile layout is a fixed template (4 tiles in 2x2, 9 in 3x3, 16 in 4x4, 25 in 5x5) and the camera assigned to each channel always lands in the same tile. The DVR also draws the camera name strip at the top of each tile and, on most brands, the per-class label inside the tile. A classifier tapping HDMI captures the layout once at install time, stores the per-tile camera label and the per-tile pixel offset where the brand draws its P&V glyph, and writes both into a tile-grid template tied to that DVR's output resolution. From then on, every detection bounding box gets snapped to its tile by integer division on x and y, and both pieces of information (the camera ID and the brand's native class label) fall out of the lookup. The whole step runs in microseconds.

No, the brand label is a useful signal but not a sufficient one. The OCR result inherits everything the brand's classifier got wrong: the recall ceiling from the pre-filter motion gate, the silence on sub-threshold humans, the missed slow approaches. The right architecture is to run your own person and vehicle model on the same composite the DVR is rendering, and treat the OCR'd brand label as a parallel signal that boosts confidence when it agrees and surfaces a disagreement when it does not. If your model fires person and the brand label says nothing, that is the recall lift you came for. If the brand label says vehicle and your model also says vehicle in the same tile, that is a high-confidence event and you can route it directly to the per-class context map. The two streams reinforce each other; neither one alone is enough.

The classifier produces the class. The context map decides whether the class fires anything. A person at the parcel shelf during business hours is logged but does not page; the same person at the same shelf after the configured delivery window is a HIGH THREAT phone call. A vehicle in the loading bay during the day is normal; a vehicle in the loading bay at 3am pages on-call ops. Headlight sweep is silenced regardless of the brand label. Animals are dropped except in zones the property explicitly cares about. The map is the operations layer that the brand's native P&V alert never reaches, because the brand exposes 'Person detected in Zone 3' and stops there. The map is what turns a label into a phone call, and it has to live somewhere downstream of the brand's alert engine.

The cameras stay. The DVRs stay. The cabling stays. At each property a small edge device plugs into the back of the existing DVR over HDMI and reads the multiview the DVR was already drawing for the on-site monitor. The device runs object detection on the composite at native rate, OCR's the brand's per-tile P&V glyph as a parallel signal, de-tiles every detection back to a camera ID using the property's tile-grid template, and applies one shared per-class context map across all six properties. Alerts route to a single dashboard and a single on-call rotation regardless of whether the underlying box is a Hikvision, a Dahua, or a Lorex. Hardware is $450 one-time per property; software is $200 per month per property starting in month two; install takes about two minutes on site; all inference runs locally with nothing uploaded to the cloud. This is what portfolio-level P&V alerting actually looks like in practice.