Edge vs cloud video analytics: latency, bandwidth and cost

Run video analytics at the edge when your uplink cannot carry every stream or when someone must react within seconds, and in the cloud when you need heavy models, search across many sites and central review. Most real deployments end up split: detection and tracking near the cameras, with events, counts and short clips sent to a central system. The right split comes from three numbers you can measure before buying anything: bitrate per camera, how fast each answer is needed, and how many sites you have to look after.

The debate usually gets framed as a technology preference. It is closer to an accounting exercise, and the inputs are specific to your buildings.

Three places the model can run

"Edge" gets used loosely, so it helps to be precise. There are three places a video model can run.

The first is the camera itself. Many modern IP cameras have a small processor that can do motion detection or run a compact model. The second is a server on the same site: a box in the comms room or next to the recorder, often with a GPU, that receives the streams over the local network. The third is a remote data centre or public cloud, which receives streams or results over the site's internet connection.

A 2017 article from Microsoft Research in IEEE Computer argued that real-time video analytics would be the "killer app" for edge computing, and that the only practical design spans all of these tiers, from cloud and private clusters "all the way down to compute at the cameras". The authors' reasoning was about scale: citing an IHS report, they put the global installed base at one camera for every 29 people, and one for every eight in the US. Video has more data, more compute and tighter time limits than most other sensor data, which is why where you process it matters more than it does for a temperature sensor.

So the useful question is how to divide the work between the three tiers, and which numbers decide the division.

Bandwidth usually decides it first

Start with the uplink, because it is the number that ends most cloud-only plans.

Here is an illustration. Say each camera streams 1080p video at 4 megabits per second (your real figure depends on codec, frame rate and scene, so read it from your recorder). One camera then sends 4 million bits every second, which is 43.2 gigabytes a day. A warehouse with 40 cameras needs a sustained 160 megabits per second of upload, every hour of the day, and moves about 1.7 terabytes daily. Check the upload figure specifically, because many connections are sold with a slower upload than download, and upload is the direction that matters here.

The codec helps. The HEVC (H.265) standard was designed to cut bit rate by roughly 50 percent at equal perceptual quality compared with the standards before it, so switching cameras from H.264 can halve the bill on paper. Two cautions, though. That figure is a design target measured for human viewers, and a detector may react differently to the artefacts. And as an earlier article on accuracy explained, pushing compression too far costs detections on small, fast or badly lit targets. Bandwidth you save by squeezing the stream can come straight out of your accuracy.

Edge processing changes the arithmetic completely. If a site server watches all 40 streams over the local network, what leaves the building is a list of events: a count per hour, an alert with a timestamp, perhaps a ten-second clip when something needs a human to look. That is kilobytes per event instead of a continuous stream.

Filtering at the camera saves less than you would think

A popular middle path is to filter at the camera: drop frames where nothing changed and send only the interesting ones onward. It works, but the savings are smaller than the share of frames dropped.

The clearest evidence is Reducto, a system from UCLA presented at SIGCOMM 2020. The authors tested it on 24 hours of live video from seven traffic and surveillance cameras. A first finding is that commodity cameras have so little compute that they could only filter using frame differencing on low-level features, not a neural network. With careful tuning, Reducto filtered out 51 to 97 percent of frames while meeting the accuracy target for each query.

The bandwidth saving was 21 to 86 percent. In one set of experiments, the average was 22 percent.

The gap is there because video encoders already exploit the fact that consecutive frames look alike. A frame where nothing moved is cheap to encode, so dropping it saves little. The paper notes that longer segments saved more bandwidth because they needed fewer key frames, which are the expensive ones. So if your plan depends on camera-side filtering to fit the uplink, measure it on your own footage before buying anything. A quiet corridor and a busy checkout will give very different answers.

Latency: who is waiting for the answer?

People often treat latency as a reason to go to the edge by default. Look at who consumes each result first.

A weekly footfall report for a store manager can be computed hours after the fact. Nobody is harmed if the count for Tuesday at 6pm arrives at 6:05. A forklift entering a pedestrian zone in a loading bay is a different case: a warning that arrives after the person has already been hit is useless. Most deployments have both kinds of question running on the same cameras.

For the slow questions, the cloud's distance does not matter and its advantages (more compute, all sites in one place, easy model updates) do. For the fast ones, keep the loop local. The detection, the decision and the alarm should all happen on site, so a broken internet link does not silence a safety alert.

There is a third group in between: alerts that lead to an action taken by a person, such as sending a supervisor to check a zone or opening a maintenance ticket. These have a human in the loop already, so a few seconds of extra delay changes nothing. What matters there is that the right person sees the alert and decides. CloudOEngine's Autopilot handles this kind of step with approval rules: a triggered agent proposes the action and a person approves it in the app or through an email approve link before it runs (see the AI runtime). We cover the design of these approval steps in more depth in human-in-the-loop AI agents.

Where the compute bill lands

Compute is where the comparison gets slippery, because running detection on every frame of every stream is wasteful wherever you do it.

The NoScope paper put a number on the naive approach in 2017: running a state-of-the-art object detector in real time, at 30 or more frames per second, on a single video needed a $4,000 GPU. Hardware has moved on since then, so treat the dollar figure as historical. The more lasting point was how much of that work could be skipped. Using cheap specialised models and difference detectors for fixed-angle camera feeds, NoScope reported cost reductions of up to three orders of magnitude while staying within 1 to 5 percent of the full model's accuracy on the binary questions it tested.

Later research showed the same pattern from other angles. Chameleon (SIGCOMM 2018) tuned pipeline settings such as frame rate and resolution as conditions changed, and on five traffic camera feeds reached the same accuracy with 30 to 50 percent of the resources of a single fixed configuration. Focus (OSDI 2018) targeted questions asked after the fact, such as "find every frame with a bus last week". It built a cheap index when video arrived and ran the expensive model only at query time, and reported ingest that was 48 times cheaper than running expensive CNNs on everything, with query latency 125 times lower than NoScope.

What this means for the edge or cloud decision: the cost difference between a well-designed and a naive pipeline is often larger than the difference between running it on site or in the cloud. Before comparing hardware quotes, check whether the pipeline samples frames, uses a cheap first pass and only calls the big model when needed. A naive pipeline is expensive in both places.

The costs also have different shapes. Edge hardware is a capital purchase per site, plus someone to replace a failed disk in a town three hours away. Cloud compute is a running cost that scales with streams and hours, plus the uplink. For one large site with good IT staff, edge often wins. For 60 small sites with nobody technical on any of them, the maintenance burden of 60 boxes counts for more than it looks on a spreadsheet.

The split most sites end up with

In practice, the hybrid version is where most multi-site deployments settle. Detection and tracking run on a site server because that is where the full-quality stream is cheap. Safety alerts fire locally. Counts, events and short clips go to a central system, which holds the dashboards, compares sites, runs heavier models on the few clips that need them and gives reviewers one place to work.

Here is how the three options compare on the points that usually decide it.

That last row matters for privacy as well as cost. Footage of identifiable people can be personal data under data protection laws, and keeping raw video on site while sending counts outward reduces how much of it you move and store. Our article on DPDP and AI governance covers the obligations in more detail (it is not legal advice).

The hybrid design creates its own problem: you now have streams, site servers, central services and reviewers spread across many places, each with its own logins. Somebody has to answer "who could see camera 14 last month?" CloudOEngine connects camera streams, data and AI in one console with one permission model and one audit trail, which is the part of a multi-site rollout that tends to be patched together last.

What you lose when only numbers leave the site

The weakness of shipping results instead of video is that a number on its own cannot be checked. If the Koramangala store reports 1,240 visitors on Saturday (an illustration), and the central team only ever receives that figure, the only way to find out whether it is right is to go back to the site's recorder, if the footage is still there.

So whatever split you choose, keep evidence with the count. For each counted crossing, keep enough to replay it: a timestamp, the track, and a thumbnail or short clip. This costs far less uplink than a full stream and makes a count something a manager can trust. The practical methods for proving a count against hand-counted ground truth are covered in people counting with CCTV.

This is how CloudOEngine's Vision AI handles counting: two independent trackers follow each scene, every counted crossing is shown, and where the trackers disagree the case goes to a human review queue for your staff to check. A finalised count ships with a published accuracy report.

How I would decide

If I were planning a rollout tomorrow, I would do this in order, before talking to any vendor.

1. Read the real bitrate of each camera from the recorder, multiply by camera count, and compare it with the measured upload capacity of each site, not the advertised one.
2. List every question you want the cameras to answer, and mark each as needing an answer in seconds, minutes or days.
3. Put the seconds-level questions on site, without exception, so they survive a broken internet link.
4. For everything else, compare the cost of a site server plus its upkeep against the uplink and central compute for the same cameras, using the numbers from step 1.
5. Test any camera-side filtering on a full day of your own footage and measure the bandwidth it actually saves.
6. Decide what evidence travels with every count and alert, so the central team can check a number without visiting the site.

Step 1 is the easiest to skip, and skipping it is how the uplink limit shows up after the cameras are already installed.

How CloudOEngine helps

CloudOEngine is one platform and one console for connecting data, including databases, files and camera streams, running pipelines, an AI runtime with an LLM gateway, agents with tool access and RAG, and Vision AI with live video. All of it sits under one permission model and one audit trail, so the same rules decide who can see a camera, a count or a dashboard.

Governance is included rather than sold separately: tenant isolation, role-based access, audit logs and per-tenant encrypted secrets.

For counting, Vision AI runs two independent trackers on each scene. Where they disagree, the case goes to a human review queue where your staff check it. A finalised count ships with a published accuracy report, and every counted crossing is shown, so a store or site manager can replay the evidence behind any number.

When a camera event should lead to an action, Autopilot runs triggered agents with approval rules. An agent can propose a step such as filing a ticket, a person approves it in the app or through an email approve link before it runs, and every step and tool call is traced and can be inspected later.

AI also reads your real data schemas to propose KPIs, which helps when footfall or occupancy counts need to sit next to sales or operations data. CloudOEngine is built in Bengaluru, India.

Book a demo or see Vision AI.

Frequently asked questions

What is edge video analytics?

Edge video analytics runs the AI models close to the cameras, either on the camera itself or on a server at the same site, instead of sending every video stream to a cloud or remote data centre. Only results, such as counts, alerts or short clips, leave the site.

Is edge or cloud cheaper for video analytics?

It depends on how many cameras you have and what your uplink costs. Cloud processing needs every stream to cross the internet connection all day, while edge processing needs hardware on every site that someone has to maintain. Work out both from your own camera count, bitrate and site count before deciding.

How much bandwidth does one CCTV camera use?

It depends on the resolution, frame rate, codec and scene, so read the actual bitrate from your recorder or camera settings. As an illustration, a camera streaming at 4 megabits per second sends about 43 gigabytes in a day.

Can the camera itself run the AI model?

Some cameras can run small models, but commodity cameras have limited compute. Researchers behind the Reducto system found commodity cameras could only filter frames using simple frame differencing, so heavier detection usually runs on a server.

Does filtering frames at the camera save bandwidth?

Yes, but less than the share of frames dropped. In the Reducto experiments, dropping 51 to 97 percent of frames saved 21 to 86 percent of bandwidth, because video encoders already compress near-identical frames very efficiently.

What is a hybrid edge and cloud setup?

In a hybrid setup, a site server or the camera does detection, tracking and time-critical alerts locally, and sends events, counts and short clips to the cloud. The cloud handles heavier models, search across sites, dashboards and human review.

Sources

1. Real-Time Video Analytics: The Killer App for Edge Computing (Ananthanarayanan et al., IEEE Computer, 2017)
2. Reducto: On-Camera Filtering for Resource-Efficient Real-Time Video Analytics (Li et al., SIGCOMM 2020)
3. Chameleon: Scalable Adaptation of Video Analytics (Jiang et al., SIGCOMM 2018)
4. NoScope: Optimizing Neural Network Queries over Video at Scale (Kang et al., PVLDB 2017)
5. Focus: Querying Large Video Datasets with Low Latency and Low Cost (Hsieh et al., OSDI 2018)
6. Overview of the High Efficiency Video Coding (HEVC) Standard (Sullivan et al., IEEE TCSVT, 2012)

#video analytics #edge computing #cctv #computer vision #bandwidth