The question comes up in almost every tender discussion: should video go to a server for analysis, or should the camera do the work? This post compares the two designs on four criteria. The bandwidth figures are worked examples with stated assumptions, not measurements from a specific site.
Key points
- Streaming one 2 MP camera at 4 Mbit/s (assumption) uses about 43 GB per day. Sending events instead can be a hundred times less.
- On-camera inference removes the network round trip from the decision path.
- When the link drops, an edge device keeps detecting and storing evidence. A server-side design stops seeing.
- Processing on site means raw footage does not have to leave the site.
- A central platform is still needed for validation, reports, device health and cross-camera search.
The two designs
| Criterion | Server (cloud) inference | On-camera (edge) inference |
|---|---|---|
| What travels upstream | Continuous video | Events, evidence images or clips, metadata |
| Decision latency | Encode, network, queue, inference, reply | Inference on the device |
| Link outage | Detection stops for the outage | Detection continues; data syncs later |
| Raw footage location | Leaves the site | Can stay on site |
| Model updates | One place | Pushed to each device |
| Compute per camera | Shared GPU pool | Fixed by the device |
Bandwidth: a worked example
Assumptions: one 2 MP camera, an H.264 stream at 4 Mbit/s, 20,000 vehicles per day, a 200 kB evidence image per vehicle and 1 kB of metadata per vehicle. Change any of them for your site.
continuous stream = 4,000,000 bit/s x 86,400 s / 8 = 43.2 GB per day
evidence per pass = 20,000 x 200 kB = 4.0 GB per day
metadata only = 20,000 x 1 kB = 20 MB per dayA corridor of 50 cameras streaming continuously would need 2.16 TB per day of backhaul. Highway sites often have one fibre or cellular link shared by several devices. Sending events instead of video is the difference between a link that copes and one that does not.
Latency: what the round trip costs
In a server design, each frame is encoded, sent, queued, decoded and analysed before any result returns. Each step adds delay, and the network adds variation. In an edge design the decision happens where the frame is captured. The VSDS product page states 40 ms violation detection per vehicle at the gantry.
Latency matters more for some functions than others. A speed display that warns a driver must respond while the vehicle is still in view. An incident alert to a control room should arrive in seconds. A monthly traffic report can wait for a batch job.
Failure modes
Server inference
- A link outage means no detections for its whole duration, and the gap cannot be recovered later unless video is buffered.
- Congested links drop frames or lower bitrate, which lowers plate read quality without any alarm.
- One central fault affects every camera at once.
Edge inference
- Compute on each device is fixed, so a larger model may need new hardware.
- Each device needs remote updates and health monitoring.
- Local storage must be sized for the longest expected outage.
Our products are built for the edge case. VIDS processes on the Local Processing Unit at the gantry, logs incidents locally and syncs to the central server when connectivity is available. GateGuard keeps making access decisions and logging evidence without internet. VSDS stores evidence locally and syncs to the cloud when the internet returns. For VIDES, the NHAI circular requires that AI models can be updated remotely without hardware changes.
Privacy and data handling
If inference runs on site, raw video does not need to travel. Our AI Search page states that queries are answered on the camera and footage never has to leave the site. What does travel (plates, evidence images, timestamps) is still personal data in many cases, so access control and retention still matter.
In India, the Digital Personal Data Protection Act, 2023 governs the processing of digital personal data, and Section 16 lets the Central Government restrict transfers to notified countries outside India. Our company FAQ states that our data is stored on India-based servers, retained for 1 year by default, and that on-premises deployment is available for clients who need data to stay in their own network.
The hybrid we use
We split the work by what each layer does best:
- On the camera: capture, detection, plate reading, violation logic and natural-language search. Our core software stack is written in C/C++ with GStreamer and runs on NVIDIA edge processors.
- In EdgeTrack: officer validation, e-challan push to NIC, reports, device health and one search across every connected camera.
EdgeTrack supports cloud deployment as standard and on-premises deployment for government and defence clients. The EdgeTrack page describes the dashboard. Our post on vision language models on the edge covers what runs on the camera, and our global shutter post covers capture. More briefs are on the Research page.
Frequently asked questions
Is cloud ANPR ever the right choice?
Yes, for sites with reliable links, low vehicle volumes and no need for a decision at the lane, such as a multi-site report on visitor counts. GateGuard Connect is a cloud platform for that kind of multi-gate oversight, with the plate reading still done on the edge device.
How much storage does an edge device need?
Multiply the evidence size per event by events per hour and by the longest outage you plan for, then add a margin. Use your own traffic counts; our figures above are assumptions.
Does edge inference make the system offline only?
No. Devices sync events and evidence to the central platform whenever a link is available. Edge inference only removes the link from the decision path.
Share this article