Video analytics only earn their keep when they cut false alarms, surface real events, and do it without ballooning your bandwidth bill. The deployment choice that drives all of that is where the AI runs: on the camera (edge) or on a central server. Lead with the use case, not the brochure.
Edge Analytics: Processing on the Camera
Edge analytics run object detection, classification, and event logic on the camera's own processor. Modern cameras from Axis, Hanwha, i-PRO, and Bosch ship with capable on-board compute.
Strengths:
- Low latency. Decisions happen at the source, so alerts fire in near real time.
- Bandwidth savings. The camera sends metadata and events instead of streaming raw video to a server for analysis. This matters on constrained WAN links and remote sites.
- Resilience. Analytics keep working even if the network link to the server drops.
- Scales linearly. Each camera brings its own processing, so adding cameras adds capacity.
Trade-offs:
- On-board compute is finite, so the heaviest models or multi-stream correlation may not fit.
- Capability is tied to the camera; upgrading the algorithm can mean upgrading hardware.
Server Analytics: Centralized Processing
Server-side analytics pull streams into a central appliance or GPU server, often inside the VMS (Milestone, for example) or a dedicated analytics platform.
Strengths:
- Heavy models. Servers run more demanding algorithms and can correlate across many cameras at once.
- Cross-camera logic. Tracking a subject across the facility or fusing feeds is easier centrally.
- Mixed fleets. A server can add analytics to older cameras that have no edge capability.
- Faster iteration. Update the model on the server without touching field hardware.
Trade-offs:
- Bandwidth. Raw streams must reach the server, which loads the network.
- Latency and dependency. A server or link failure can take analytics offline for many cameras at once.
- Cost. GPU servers, power, and cooling add capital and operating expense.
A Hybrid Is Usually the Right Answer
Most mature deployments are not either/or. The pattern that works:
- Run edge analytics for high-value, latency-sensitive triggers: line crossing, intrusion zones, loitering, vehicle/person classification at the perimeter.
- Use the edge to pre-filter, sending only relevant events and metadata upstream.
- Reserve server analytics for heavy lifting: forensic search, cross-camera tracking, and analytics on legacy cameras.
This keeps the network quiet, alerts fast, and the expensive central compute focused on what only it can do.
How to Decide
Work through these for each site:
- Latency: Does the response need to be immediate? Lean edge.
- Bandwidth: Is the link constrained or metered? Lean edge.
- Model complexity: Need cross-camera correlation or forensic search? Lean server.
- Fleet age: Mix of old and new cameras? Server fills the gaps.
- Failure domain: Can you tolerate one server outage taking down many cameras? If not, push logic to the edge.
Compliance Does Not Stop at the Algorithm
An analytics layer is only as clean as the hardware under it. Edge analytics run on the camera, and server analytics still depend on cameras feeding them, so every imager and appliance has to be TAA compliant and free of NDAA Section 889 covered equipment. We design analytics architectures on 889-clean lines so the intelligence you deploy does not become an audit liability.
Want an edge, server, or hybrid analytics design matched to your sites and bandwidth?
Get a quote or contact our team to scope your analytics architecture.