Edge, server or cloud: where should video analytics run
Video analytics can run at the camera, on a server at the site or in the cloud. This guide explains what decides the choice for each site and ends with a short checklist.
Where the analytics run is an early design decision in a video project. It affects how much network each site needs, how soon an alert can reach an operator, where video travels and who looks after the equipment. It can be costly to change later, because the hardware is chosen to suit it.
The three places analytics can run
Each option does the same work. It takes video from a camera, runs a trained model on it and turns what the model finds into events and alerts. What differs is how far the video travels before that happens.
- At the edge. The model runs on the camera itself, or on a small processing unit near it, often called an edge box. Video is analysed close to where it is captured.
- On a server at the site. Cameras send their streams over the local network to servers with graphics processing units (GPUs), usually in the site's own equipment room. This is also called on-premise.
- In the cloud. Streams, or selected parts of them, travel over the site's outside link to a remote data centre. Processing, dashboards and storage are managed centrally.
With the first two, video can stay inside the site and only events need to leave it. With the third, the video itself has to cross the link. Most of the factors below follow from that difference.
What crosses the site link
The further from the camera the analysis happens, the more video the network has to carry.
The three places in order of distance from the camera. Analysis can happen at any of the highlighted points. Only the cloud option needs video to leave the site.
What decides the choice
Work through these eight factors for each site. The answers often differ from one site to the next within one organisation.
- Bandwidth and connectivity
- Video needs far more bandwidth than events. A site on a slow, shared or metered link can rarely send many camera streams out, so the analysis usually has to happen at the site. Where a fast private link already exists, central processing becomes practical.
- Urgency of alerts
- An intrusion or safety alert is useful only while someone can still act on it. Analysis at the site avoids the delay of sending video over a long link first. Counts, heatmaps and similar reports are less urgent and can be processed centrally.
- Data sensitivity and residency
- Some organisations do not allow video to leave their own network. Air-gapped sites have no outside connection at all. Both cases point to edge devices or on-premise servers, with software updates brought in by an approved offline route.
- Site and estate size
- A large site with many cameras can justify its own servers and the staff to look after them. An estate of many small sites, each with a few cameras, is often better served by edge devices or by cloud processing managed from one place.
- Model weight and multi-camera analysis
- Small devices typically run lighter models and fewer analytics at once. Heavier models, several analytics on one stream, and analysis that combines views from several cameras usually need the processing power of a server, at the site or in the cloud.
- Many devices or central servers
- Each edge device is a small computer to power, secure, monitor and update. Across a large estate that adds up to a real maintenance workload. Servers and cloud processing concentrate the work in fewer places, but a fault there can affect more cameras.
- When the link drops
- Outside links fail from time to time. Ask what each design does when that happens. Analysis at the site can carry on detecting, so check whether events are stored and sent on once the link returns. Cloud analysis for that site stops until video flows again.
- Capital or operating cost
- Edge devices and servers are usually bought up front and then maintained. Cloud processing is more often paid for as it is used, for as long as the cameras are analysed. The link that carries the video is part of that cost. Compare the options over the expected life of the system.
Mixed estates are normal
An estate does not need a single answer. A remote gate may be analysed at the edge, a main building on its own servers and a group of small branches in the cloud. Decide site by site, then check that alerts from all of them reach operators in one console.
A short decision checklist
Answer these in order for each site. The first answers rule options out. The later ones choose between what is left.
-
Decide where video may go
If video must stay on the site, or the site is air-gapped, the choice is between edge and on-premise.
-
Measure the outside link
Note the bandwidth available at busy times, what it costs and how often it fails. Compare that with the number of streams you would send.
-
Separate alerts from reports
List the events that need a response within moments. Those are usually the ones to analyse at the site.
-
Count cameras and sites
Record how many cameras each site has, and whether it has a secure room, power and someone to look after a server.
-
List the analytics
Mark those that need heavy models or several cameras together. They usually need a server.
-
Name who maintains it
Decide who monitors, updates and replaces equipment at each site, and how updates reach it.
-
Cost it over its life
Add up hardware, links, cloud charges, power and maintenance for the years the system is expected to run.
How Videolytical approaches this
Videolytical analytics run on edge devices, on-premise GPU servers or cloud instances, and the three can be mixed in one estate. Edge deployments keep working without connectivity. On-premise deployments keep video inside the customer's network and suit air-gapped sites, which are updated offline with signed packages. Network and GPU sizing follow a site survey and camera audit, and a pilot on a small set of cameras comes before scale-out.
Discuss your sites with our engineers
Ask for an architecture and sizing discussion, or arrange a live demo on your own footage.