Object detection

EverNVR runs DAMO-YOLO-T locally. Settings → Object detection shows the requested backend, the backend actually running, and any fallback reason. Detection examines frames from the stream the recorder already receives, so it costs the cameras nothing extra. On the CPU it competes with recording for the processor; an accelerator frees that capacity for more cameras.

Selection	Behavior
Automatic	Try Hailo, then use CPU if it cannot start
CPU (ONNX)	Use the processor even if a Hailo device is present
Hailo accelerator	Request Hailo, with visible CPU fallback on accelerator failure

Select Save to apply the selection and restart detection. Recording and camera connections continue, tracking identities start fresh, and detection zones are resent. A saved selection overrides the EVERNVR_DETECT_BACKEND environment default.

Per-camera filtering

In Cameras → Detection, adjust Ignore detections below and objects shorter than. These confidence and size floors filter detections before tracking; increasing them can remove small or uncertain real objects as well as nuisance detections. The size floor drops a detection outright. The confidence floor decides what can start a new track: a detection under it, or under the detector's own starting threshold, never opens a visit, but it can keep an object that is already being tracked (see Objects that sit still).

A detection schedule limits the days and hours when the camera is watched. Review that schedule before investigating missing detections. Recording policy is configured separately on the Recording tab.

Recognition floors control appearance matches against Known objects. Use reviewed sightings to judge a change. Detector confidence, identity matching, and action-rule thresholds serve different purposes.

When the detector changes its mind

The model does not always give one object the same name from frame to frame. A distant vehicle may read as a car, then a truck. A small or low-resolution animal may read as a cat, then a dog, then a bird. Within the vehicle group (car, truck, bus, and motorcycle) and within the animal group, a new name for an object in the same place continues that object's track. It stays one visit and does not register as a departure plus a new arrival. The visit carries the name that most of its sightings agreed on.

A track never crosses those groups. A person never continues as an animal or a vehicle, a vehicle never continues as a person, and a bicycle is tracked on its own. When two objects of the same group are in view together, such as a car beside a truck or a bird near a cat, the tracker favors keeping each name on its own track and does not join objects of very different sizes, so they normally stay separate.

Objects that sit still

The model is often less sure of an object that has stopped moving: a person who sits down or turns away, or a cat that curls up, can score well under the confidence needed to start a track. Tracking uses two thresholds. A detection needs the higher one to start a track and to confirm it as an arrival. Once an object is confirmed, a lower-scored detection of the same kind (or the same vehicle or animal group) that overlaps its current box keeps the track alive, so the visit does not end while the object is still in plain view. A low-scored detection elsewhere in the picture, or of a different kind, does not, and never starts anything on its own. The visit ends as before once the object has gone undetected, at either threshold, for a short run of frames.

The model can also box one object in pieces, such as a lying animal scored whole and again for half its body. A box that lies mostly inside a stronger box of the same kind is treated as part of that object rather than a second one when it is under the starting threshold, or when it is an animal. Two people close together, such as an adult with a child in front, stay two people.

PTZ cameras and camera-moved alarms

While a PTZ camera moves, detection on it is held: no frame of the pan is examined, so nothing streaking across a zone becomes an event, and any stay that was open when the move began ends at that moment. The hold lasts from the first sign of a move (a command from the recorder, or a position change the recorder observes on a camera it follows for privacy masks) until the camera has settled. Detection then starts over on the new view. Whatever is already in that view, a parked car or someone standing in it, is treated as having been there before the camera looked: it is drawn and counted, but it opens no visit and raises no event until it moves, and that first movement is recorded as its arrival. The same applies to the view a camera shows when detection first starts on it. A move the recorder made or saw is never reported as a camera-moved alarm; the detector learns the settled view as its new reference and reports moved only if the camera is later shifted off that view.

A camera the recorder is steering with auto tracking is the one exception to the hold. Its frames are still examined, because the recorder steers by the objects found in them, but nothing is judged: no visit, zone event or tamper report comes from a view that is turning under the detector. The hold becomes an ordinary one when the follow ends, and detection learns the settled view as after any other move.

A camera cutting to its night mode is not tampering either. The same scene at a fraction of its daytime contrast, or lit by the camera's infrared, is recognized as the view the camera already had and adopted as its normal; the detector compares the picture's edges as well as its tones, so sky, wall and tree staying where they were counts for more than how each is lit. A blinded or moved fault that is standing is reconsidered while it stands: a new picture that holds steady, with something in it, for ten minutes becomes the camera's view and the fault clears by itself. A flat picture, or one that keeps changing, never does.

Hailo setup and fallback

On Ubuntu 24.04 and 26.04, the installer configures a Hailo-8 it finds. Install Hailo stack in Settings handles supported incomplete installations through the recorder's host service: the driver, firmware, runtime and detection model. Building the runtime can take several minutes, during which detection uses the CPU and recording continues. It may require a reboot; it never reboots the host automatically. See the full installation procedure.

Accelerator failures can latch CPU fallback. The recorder then retries the preferred backend after 1, 2, 4, 8 and 16 minutes, and every 30 minutes after that, for as long as it takes; the detector status shows when the next attempt is due. Save retries immediately and starts the schedule over. A bad frame or a decoding error on the host is answered as one lost frame and never counts as an accelerator failure; a generic detector stall restarts the requested backend rather than treating CPU load as one.

Detection rate and camera count

Every camera shares one accelerator, so the figure that has to fit is cameras multiplied by the detection rate. The rate is one site-wide setting, not a per-camera one: EVERNVR_DETECT_FPS in configuration, five per second by default.

On a machine like the development host, plan on about 20 cameras at 5 per second. Adding cameras beyond that means lowering the rate — 24 at 4, 32 at 3 — which costs tracking detail on fast movement but nothing in recording.

A camera's detection schedule and the recorder's motion gate mean fewer frames reach the accelerator than the rate suggests. Treat that as margin for the night when wind and rain move every scene, not as room for extra cameras. See detection capacity.

Detection accuracy and sustained camera capacity have not been qualified. Check the support limits and test the real scenes.