Intelligence for existing cameras
Most sites already have cameras. They were bought over years, from several manufacturers, and they record to a recorder that keeps footage and little else. Finding out what happened means scrubbing video, and the cameras' own motion alerts are too noisy to act on. Replacing the array to get modern analytics is expensive and disruptive.
EverNVR takes the other route. It connects to the cameras already on the network over ONVIF or RTSP and does the analysis on the recorder. The intelligence lives in the recorder, so a ten-year-old bullet camera and a new dome get the same detection, rules, and search.
What stays the same
- The cameras. EverNVR manages the settings it depends on and leaves the rest alone. Today that is each camera's clock: the time, the recorder's time zone and the recorder as its NTP server, set automatically and verified. It does not change resolution, codec, bitrate, or frame rate, does not install firmware, and does not reboot a camera. Every camera write is audited and listed in camera connections.
- The existing recorder. EverNVR can run alongside it. It uses one connection per camera unless an installer enters the camera's known limit, and never tests for that limit by opening streams. With a known limit, at least one session is always reserved for the incumbent system; when no slot is free, EverNVR pauses rather than taking one.
- The network and the site. Recording, detection, and search run on the local recorder. Nothing depends on a cloud service, and the optional AI agent only sends what an administrator allows.
What it adds
| Capability | What it gives a site with ordinary cameras |
|---|---|
| Object detection | People, vehicles, and animals found by a local model, on frames from the stream already open, so the camera does no extra work |
| Zones and action rules | Rules for arrival, loitering, leaving, occupancy, and absence in drawn areas, on a schedule, with notifications, footage preservation, and arm/disarm |
| Events and investigation | Visits instead of raw motion clips, traced across cameras and searchable by description, color, and appearance |
| Known objects and face and plate recognition | Familiar people and vehicles told apart from unrecognized ones, so rules can ignore the regulars |
| "Something unusual" and the morning briefing | Each camera's normal learned from the site's own history, and a daily summary of the night and of anything that departed from it |
| Deterrence and PTZ response | A camera's light, siren, or relay switched by a rule; PTZ cameras aimed at a trigger, patrolled, or set to follow a target |
| Site plan | Cameras placed on a drawing of the property, PTZ cameras turned toward a detection seen by a fixed camera, and trails shown on the plan |
| Privacy masks | Areas concealed in live view, playback, and exports, including on PTZ cameras |
| Health monitoring | Offline cameras, a camera that has been moved or blinded, storage faults, and recorder faults raised as alarms instead of discovered after an incident |
| AI security agent | Optional second opinions on events and plain-language questions about what the recorder saw |
| HTTP API and MQTT | Events and pictures handed to access control, alarm panels, and building systems |
Cameras that run their own analytics keep them. EverNVR can also listen to the camera's own events and use them in rules, but it does not need them: a camera with no analytics at all gets the full set above.
What the cameras still decide
Software cannot add pixels. A camera's resolution, lens, placement, and night performance still limit what can be detected and recognized: a face across a parking lot at night on a 2 MP camera will not be identified, however good the model. Detection quality on a site depends on those cameras, and on zones and floors tuned during commissioning.
Capacity depends on the recorder's hardware and the detection rate, not on the cameras. See support and current limits for what has been measured, and commission each site on its actual cameras.