NVR With Person Vehicle and Pet Detection: 2026 Checks

Leo · 2026-10

An NVR with person vehicle and pet detection classifies objects on the recorder itself, so each clip is indexed by what triggered it, not by raw motion. A recorder that labels objects on the box is only as useful as the terms written around it. Camera count and bay count rarely decide the outcome; inference placement, the method behind the false-alarm figure, the ONVIF profile that carries the metadata, and the fee structure after purchase decide it.

What does person vehicle and pet detection actually mean on an NVR?

The feature means the recorder assigns an object class to each detection before the clip is written, so the index stores a person event at 02:14 rather than a motion event at 02:14.

Classic motion detection compares pixel brightness between frames. A passing shadow, a branch in wind, or a cat crossing a driveway all produce the same trigger, and an operator then spends time scrubbing footage to find out whether anything happened. A classifier returns a label with a confidence score, and the recorder can route the clip by class: persons to a priority folder, vehicles to a plate-review queue, pets to an ignore rule.

• The label survives search, so an operator can pull every vehicle event from a gate camera across 30 days.
• Alert routing changes, and a pet trigger no longer pages the on-call manager at 02:00.
• Retention can differ by class, which is where most of the storage decision actually sits.

A class label also makes an alert reviewable months later. Reviewers who open a clip six weeks after an incident can filter by class instead of watching a continuous timeline, and that change in workflow is the reason sites tolerate the extra configuration work a classifier requires.

Where should the classification run: camera, recorder, or cloud?

Classification should run where the compute, the storage, and the retention policy already sit, and for a US site under about 64 cameras that place is normally the recorder.

Inference placement outranks resolution in the buying order, because a 2 MP stream with reliable labels saves more review time than a 4 MP stream without them. The table explains why procurement teams ask about inference placement before they ask about camera count. A recorder that classifies locally keeps footage and labels on the same box, and the recurring cost is the storage the site already owns rather than a per-camera license. Hosting the classifier on the recorder also avoids the awkward case where a camera vendor’s analytics license lapses and the labels stop arriving while the video keeps recording.

Reading a published false-alarm figure correctly

A false-alarm figure is only comparable when the vendor states the scene, the lighting, the camera count, and the definition of a false alarm used in the test.

Two vendors can both publish an accuracy target and mean different things: one counts any non-target movement as a false alarm, the other counts only alerts that a human marked wrong after review. Ask for the test protocol, the camera models, and whether night-time infrared scenes were included. The published figure for the woCyber S1 line is a false-alarm rate below 3 percent for its on-device classification, a figure tied to that product line rather than to every deployment, and that number still deserves a two-week pilot on the buyer’s own site, because a loading dock at dusk does not resemble a test lab.

Which ONVIF profiles carry events and metadata?

ONVIF Profile M defines metadata and analytics configuration, Profile S covers video streaming, and Profile T covers advanced streaming including H.265 and analytics events.

A recorder that only consumes Profile S streams can still classify locally, because the classifier works on decoded frames. A recorder that wants the camera’s own labels has to consume Profile M or the vendor’s metadata extension. The ONVIF profile overview lists which services each profile requires, and the Profile M specification page describes the metadata stream that carries object classes. Buyers replacing a recorder while keeping the cameras should check both directions: what the camera can export, and what the new recorder can ingest.

Detection metadata next to video: the size difference

Detection metadata is small next to video, because a text record per event occupies a few kilobytes; the worked example below totals 526 MB for a full year on a 12-camera site.

Worked example (illustrative, not a measured result): assume 12 cameras, 60 events per camera per day, and 2 KB per stored event record including class, confidence, timestamp, and bounding box. Daily volume is 12 × 60 × 2 KB = 1,440 KB, or 1.44 MB per day. Across 365 days that is 526 MB. One hour of a single 4 Mbps stream is 4 × 3,600 ÷ 8 = 1,800 MB, so the annual metadata total is smaller than that single hour of video. Metadata is not the capacity driver; the driver is which streams are recorded and for how many days. The nvr-storage-planning-for-ip-camera-projects“>NVR storage planning math for IP camera projects covers the video side of that calculation.

The decision at a 40-camera property site

Consider a hypothetical property-management company running 40 cameras across four buildings, with a shared parking area where pets, wind-blown tarps, and headlights trigger the current motion rules.

In this hypothetical, staff review about 200 clips a week and can account for fewer than a third of them. The trade-off is not camera count but the recording policy. At 4 Mbps per camera, 40 cameras write 160 Mbps, which is 160 × 86,400 ÷ 8 ÷ 1,000,000 = 1.73 TB per day, so 30 days of continuous recording needs about 52 TB before RAID overhead. Event-only recording at the same resolution plus a continuous low-resolution overview stream keeps the reviewable evidence and cuts the written volume to the share of hours that contain events, so a site whose events cover 6 percent of hours writes about 6 percent of the continuous figure (illustrative, from the site’s own event log). The specification that makes this work is the class list and the per-class retention rule, not the bay count.

For sites that want the classifier and the retention policy inside one appliance, woCyber builds the products/s1-security-kit“>S1 as an edge AI NVR and private cloud NAS in a single unit. The published specification lists 7-, 14-, and 30-day retention tiers, PoE IP camera onboarding over ONVIF, and 100 percent local computation. The boundary between accounts on a shared appliance is a separate question: ask for a data-flow sketch that shows where each account’s footage lands, and treat the sketch as part of the written scope rather than as a summary of the product line. Integrators comparing that design against a separate NVR plus NAS pair can review the checks in ai-nvr-appliance-manufacturer-what-integrators-verify“>what integrators verify in an AI NVR appliance.

Running a two-week pilot that produces usable numbers

A pilot produces usable numbers when the site fixes the cameras, the scenes, and the review rule before the first clip is recorded.

1. Pick three scenes that already generate most of the nuisance alerts, including one night scene.
2. Record the alert volume from the existing system for seven days as a baseline.
3. Run the candidate appliance on the same cameras and scenes for seven days.
4. Have one reviewer mark every alert as correct or wrong, using the same definition throughout.
5. Compare the two counts per scene rather than per site, because one hard scene hides inside an average.

A pilot that only counts alerts misses the second question: whether the archive can still find a known event afterwards. Add one seeded test, such as a staff member walking a fixed route at a set time, and confirm that the appliance returns that clip when a reviewer searches by class and time window.

The pilot output is a per-scene ratio the buyer can put in the purchase file. A site that cannot staff the review step should treat any vendor figure as unverified, including a favorable one.

The clauses that belong in the purchase file

Each clause listed below is one a buyer can test, which is the difference between a specification and a datasheet.

• The class list, written as the exact labels the recorder outputs.
• The false-alarm test protocol, including scene, lighting, and camera models.
• The metadata export format, and whether labels survive a recorder swap.
• Per-class retention rules and the storage reserved for each class.
• The scope of account isolation on a shared appliance.
• The firmware update and vulnerability response policy; nas-supplier-cve-patch-policy-buyers-guide“>a supplier CVE patch policy is the document that answers it.
• Whether any analytics, seat, or camera license recurs after the hardware purchase.
• For private-label programs, the minimum order quantity and the branding scope.

A second copy in the cloud, and when it earns its place

A second copy protects against theft and fire, and the decision is about which clips leave the building rather than whether the recorder works.

Recorder-side classification keeps every frame local by default. Sites that want an off-site copy can add one, and the question to put to the vendor is which optional copy targets the firmware exposes and whether exported clips carry their labels. Teams weighing that against a subscription camera service can compare the two cost structures in ai-nas-vs-cloud-storage-small-business“>AI NAS versus cloud storage for a small business, and the wider product range sits under products“>woCyber products.