Two fleet cameras at the lowest recording setting documented for one current dashcam need 8 + 6 Mbps — 14 Mbps of upload, continuously.
TRAI's drive tests measured 4G-only upload at between 4.51 and 8.93 Mbps across India's four operators — standing still, at test hotspots, on a flagship phone.
Fleet video bandwidth starts from that mismatch: the recording stream does not fit down a 4G uplink, not even for two cameras, not even on a good day. Everything a fleet streams live is a smaller, separate stream built to fit. The engineering question is how many of those fit, and what number to plan against.
Two sides of the uplink budget
The budget has a supply side — what the moving link sustains upstream — and a demand side — bitrate multiplied by the number of cameras you want live. Sizing exercises often get the demand side roughly right and the supply side badly wrong, because they start from a coverage map or a headline speed.
Two properties of the supply side matter more than its average. It is upload, the direction mobile networks are least generous with: one of the most thorough recent driving studies found uplink an order of magnitude lower than downlink. And it varies continuously as the vehicle moves between cells, which is why the feed dies in dead zones rather than degrading gracefully.
Supply: what a moving 4G link actually carries upstream
Four independent measurements, from four methods, frame the range.
Source | Upload measured | Conditions |
|---|---|---|
TRAI drive test, West Bengal, Feb 2025 | 4G-only: BSNL 4.51 · Airtel 5.14 · Vi 7.14 · Jio 8.93 Mbps. 5G-only: Airtel 23.39 · Jio 40.57 Mbps | Static, at hotspots, flagship handset, 30-second file uploads |
TRAI, Jodhpur–Ahmedabad route, May 2026 | All technologies, average: BSNL 3.76 · Vi 8.81 · Jio 9.06 · Airtel 11.69 Mbps | Moving, 456.9 km rail route |
Opensignal India, Oct–Dec 2025 | Upload experience: BSNL 2.5 · Vi 5.9 · Jio 8.0 · Airtel 8.4 Mbps | Crowdsourced from real users, all technologies |
US cross-country drive, Nov 2024 | Median 18–35 Mbps across three operators; bottom quarter of one operator's LTE samples at or below ~1 Mbps | 5,700+ km, moving, 2-minute uploads |
The Indian figures cluster tightly: a typical upload experience of roughly 6 to 12 Mbps on the main private networks, higher where 5G is present, and much lower on BSNL. That consistency across a regulator's drive test and a crowdsourced dataset is worth something.
But every Indian figure here is an average, and averages hide exactly the part a live stream cares about. The US study is the one that publishes a distribution, and its tail is the warning: even where the median is healthy, a quarter of samples on one operator's LTE layer sat at about 1 Mbps. We could not find an equivalent percentile breakdown for Indian roads — TRAI publishes averages and signal-quality buckets, not throughput percentiles. That is a real gap in public data, not something to fill with a guess.
The median is not the budget
A live stream does not care about the average uplink over a journey. It cares about the uplink in the worst stretch it has to survive, because that is where it stalls.
So the planning number is a floor, not a mean. The data above supports a simple rule: plan live video against low single-digit Mbps of upload per vehicle, and treat anything above that as headroom. Averages of 6–12 Mbps tell you the link is often better. The distribution from the driving study tells you it is regularly far worse, and your stream has to live through those stretches too.
The best planning number is your own. Fleets that log uplink throughput and signal against GPS on their actual routes can replace this rule of thumb with a measured floor per corridor.
Demand: recording bitrate versus live bitrate
The demand side has two very different numbers, and confusing them is a common sizing error in fleet video.
Stream | Bitrate (one current two-camera unit) | Where it goes |
|---|---|---|
Recording, per camera | 6 to 25 Mbps, depending on quality setting and camera | Local storage; uploaded later, selectively |
Live view, per camera | About 600 kbps | Over the cellular uplink, in real time |
The live stream runs at roughly a tenth to a fortieth of the recording rate. That ratio is the whole design: the recording is sized for evidence, the live stream is sized for the link. The usual design, and the one this unit documents, is two encodings at once — a high-bitrate main stream to disk and a low-bitrate substream for live viewing — and only the substream is meant to cross the cellular network live.
How many live feeds fit
With both sides in hand, the arithmetic is short. Live video cannot run at 100% of the measured link: packet overhead, retransmission and the adaptive rate control that keeps real-time video alive all need margin. The table below keeps 30% in reserve — a planning assumption, not a sourced figure — and assumes 600 kbps per live feed.
Sustained upload | Usable for video (70%) | Live feeds at 600 kbps |
|---|---|---|
1 Mbps | 0.7 Mbps | 1 |
2 Mbps | 1.4 Mbps | 2 |
5 Mbps | 3.5 Mbps | 5 |
9 Mbps | 6.3 Mbps | 10 |
20 Mbps (good 5G) | 14 Mbps | 23 |
Read against the planning floor, the practical answer for a four-camera vehicle on Indian 4G is: one or two live feeds reliably, all four some of the time. That is also how live view tends to be used — an operator looks at one camera on one vehicle when something happens, not every camera on every vehicle all day.
At 600 kbps each, one live feed is about 0.27 GB per hour; four at once is just over 1 GB per vehicle-hour. What that costs across a fleet is a business question, covered in the cost post linked below — not this post's arithmetic.
Everything else on the same uplink
Live video is not the only thing leaving the vehicle. GPS and telematics data are small. Event clips are not. A 90-second clip recorded at 14 Mbps is about 160 MB, and pushing it at 5 Mbps occupies the whole uplink for roughly four minutes — during which any live feed from that vehicle is starved.
So the uplink needs a priority order, decided in advance: live view when an operator is actually watching, event clips otherwise, bulk footage never — that last one belongs at the depot, as store-and-forward for fleet video explains.
Techniques that help, and one that hurts
- Adaptive bitrate is mandatory. Real-time video must lower its bitrate as the link weakens rather than fail outright — bandwidth estimation is why a call downgrades before it drops. On a vehicle it is constantly working.
- A more efficient codec buys headroom, with a catch. H.265 records the same quality in fewer bits than H.264, but the storage codec can break the live path when browser playback is the destination.
- On-demand switching beats always-on. Streaming only the camera an operator has open, and only while it is open, turns a four-camera problem into a one-camera problem.
- Simulcast is the wrong trade on a vehicle. It sends several encodings of the same camera so a server can pick one per viewer — which spends uplink to save downlink. On a constrained cellular uplink with one or two viewers, that is usually backwards: send one adaptive stream and let the server handle distribution.
For how those streams travel once they leave the vehicle, the architecture between vehicle and command centre walks the full pipeline.
The Bottom Line
The recording stream never fits down a moving 4G uplink; live fleet video is always a smaller substream built for the link. Indian 4G averages 6–12 Mbps upstream, but averages hide the stretches where live video stalls, so plan against a low single-digit floor.
On that floor, one or two live feeds per vehicle are reliable and more is opportunistic. Stream on demand, keep adaptive bitrate on, and keep bulk footage off the cellular link entirely.
What's Next
The arithmetic here is per vehicle. Multiplying it across a fleet — data, staff and platform — is the subject of what it takes to watch a fleet live.
Frequently Asked Questions
How much bandwidth does fleet video need?
It depends on which stream. Recording runs at roughly 6 to 25 Mbps per camera on one current fleet dashcam, which is why it stays on the vehicle. The live-view stream sent over cellular is much smaller, around 600 kbps per camera, or about 0.27 GB per hour.
What upload speed does 4G give a vehicle in India?
Typically around 6 to 12 Mbps on the main private networks, based on TRAI drive tests and Opensignal's crowdsourced data, with 5G much higher where available and BSNL much lower. These are averages; moving vehicles regularly see far less, so plan live video against a low single-digit Mbps floor.
How many live camera feeds can a truck stream over 4G?
Reliably one or two, and all four some of the time. At 600 kbps per feed with 30% of the link held in reserve, a 2 Mbps uplink carries two feeds and a 5 Mbps uplink carries five. Most fleets stream only the camera an operator opens, which keeps demand inside that budget.
Why can't a fleet stream recording-quality video live?
Because the recording bitrate exceeds the uplink. Two cameras at the lowest documented recording setting of one current unit need 14 Mbps, while TRAI measured 4G-only upload of 4.5 to 9 Mbps. Recorders therefore encode a separate low-bitrate substream for live viewing.
Should fleet video use simulcast?
Usually not from the vehicle. Simulcast sends several encodings of one camera so a server can choose per viewer, which costs uplink — the scarcest resource on a truck. Samvyo, based on SFU architecture, can take a single adaptive stream from the vehicle and handle distribution to viewers at the server side, where bandwidth is not the constraint.
Does 5G solve fleet video bandwidth?
It raises the ceiling where it is available: TRAI measured 5G-only upload of 23 to 41 Mbps on two operators. But coverage on highways is uneven and operators often keep uplink traffic on slower layers, so a 5G fleet still needs a plan for 4G-level upload. WebRTC-based platforms, Samvyo among them, adapt bitrate to whatever the link sustains, which is how a live feed survives the switch between the two.
