One current eight-channel vehicle recorder built for commercial fleets ships with three separate ways to move footage. It carries a 3.5-inch hard drive, an M.2 SSD and an SD slot up to 256 GB, alongside 4G and Wi-Fi.
That hardware is telling you something. MDVR cloud upload is not one pipe. It is a routing decision — which footage leaves the vehicle by which path, how fast, and at what cost — and a fleet that treats it as a single "sync to cloud" setting ends up paying cellular prices for footage nobody needed, or waiting days for footage someone needed that afternoon.
Four paths, not one
Counting the option that usually goes unnamed, there are four ways footage leaves a mobile recorder — or does not.
Path | Best for | Time to cloud | Main constraint |
|---|---|---|---|
Cellular (4G/5G) | Event clips, footage requested on demand | Minutes, when there is signal | Uplink is slower than the recorder writes; data is billed per GB; nothing moves in a dead zone |
Depot Wi-Fi | Bulk and scheduled offload | Hours after the vehicle returns | Shared airtime, old vehicle radios, recorder shutdown timers |
Physical removal | Serious incidents; vehicles that cannot power up; very large pulls | Hours to days | Labour, access to the vehicle, and custody of the drive |
Stay on the vehicle | Everything nobody has asked for yet | Never — unless requested before it is overwritten | The recorder's buffer horizon |
The rest of this post is about matching footage to path. The underlying pipeline — cameras, recorder, uplink, platform, operator — is in the architecture between vehicle and command centre; here we zoom into the single hop from the recorder to the cloud.
Cellular: for events and requests, never for bulk
Cellular is the only path that works while the vehicle is on the road, which makes it the only path for anything time-sensitive. It is also the narrowest. At a 14 Mbps two-camera recording rate, an hour of footage is about 6.3 GB and takes nearly three hours to upload at 5 Mbps; the recorder outruns the link even on a good day.
So cellular carries two kinds of traffic well. Event clips, which are short by design: event-triggered systems typically keep 15–30 seconds before and 30–60 seconds after a trigger. And requested footage, where an operator or investigator asks the vehicle for a specific window and the recorder sends just that. How those are prioritised against each other on the road is the store-and-forward design question.
What cellular should not carry is the continuous recording. A fleet that configures "upload everything over 4G" either saturates the link, starving live view and event clips, or silently falls behind until the recorder overwrites what it never sent.
Depot Wi-Fi: for bulk, with limits
Depot Wi-Fi is where bulk footage is meant to go, and procurement documents say so. One municipal bus-surveillance tender asked for infrastructure to "wirelessly offload all required video daily for all buses while in the … fleet facility", with at least 13 months archived centrally.
The word that matters is required. At fleet scale the depot cannot move everything — shared airtime, recorders with older Wi-Fi radios and a shutdown timer after the ignition goes off all cap what each vehicle can send. The practical answer is to schedule the depot rather than hope it keeps up — drain vehicles in order of departure, and define "required" narrowly. The point for path choice is simpler: the depot path is fast per gigabyte but only open for a few hours a day, and only when the vehicle comes home.
Physical removal: the path for when everything else fails
Pulling the drive sounds archaic. It is the path that still works when the others do not, and three situations call for it.
- After a serious crash. The vehicle may not power up, the modem may be damaged, and the footage may be the most important the fleet ever records. Some recorders carry mirrored drives and power-loss protection so the drive survives even when the vehicle does not.
- When the request is very large. Days of multi-camera footage for an investigation can be faster to carry than to transmit.
- When the evidence will be contested. A drive removed, sealed and logged is a simple custody story to tell.
The cost is custody. A drive in someone's pocket is exactly the gap that a record button isn't a chain of custody warns about: who removed it, when, where it went, and whether what was uploaded afterwards is bit-identical to what came off the vehicle. Hash the footage at removal, log every hand-off, and the physical path becomes the strongest one rather than the weakest.
The fourth path: leave it where it is
Much of the footage a fleet records is never looked at. The cheapest place to keep it is the drive already in the vehicle, and the cheapest upload is the one that never happens.
Treating the recorder as the first tier of the archive — with a known horizon, and on-demand retrieval over cellular or at the depot when someone asks — is a legitimate design, not a failure to upload. Its one hard requirement is that the horizon outlasts the time it takes someone to ask. How long that needs to be is a retention question, not a bandwidth one.
What the recorder actually speaks
One more thing decides how MDVR cloud upload works in practice: the protocol. The protocol a recorder speaks is rarely one a web browser understands. Some recorders use their manufacturer's own protocol; others implement JT/T 1078, the Chinese Ministry of Transport's video communication protocol for vehicle terminals, which covers real-time video, historical playback, download and upload between the vehicle and a platform, and references RTP for transport.
The practical consequence is a gateway. Whatever receives footage from the vehicles has to speak the recorder's protocol on one side and whatever operators and storage use on the other — the fleet version of the problem that RTSP cameras still cannot talk to web browsers describes for fixed cameras. Check which protocol a recorder speaks before choosing the platform it will upload to, not after.
A routing policy, written down
Put together, a sound MDVR cloud upload design fits on one page:
- Events and requests: cellular, immediately, highest priority.
- Required bulk: depot Wi-Fi, scheduled by departure time.
- Serious incidents: drive removal under a logged custody procedure, in addition to whatever was already uploaded.
- Everything else: stays on the vehicle until its horizon expires, retrievable on request.
The hardware for all four paths is usually already in the vehicle. What is often missing is this page.
The Bottom Line
MDVR cloud upload is a routing policy across four paths: cellular for events and requests, depot Wi-Fi for required bulk, physical removal for serious incidents, and the vehicle's own drive for everything nobody has asked for yet.
Match footage to path, check the protocol before the platform, and treat custody as part of the upload, not an afterthought.
What's Next
Every path ends in a storage decision: how long to keep fleet footage, and who actually decides covers retention as policy and cost.
Frequently Asked Questions
How does MDVR cloud upload work?
A mobile DVR records continuously to its own drive and moves footage to a central platform by one of several paths: short event clips and requested windows over 4G, bulk footage over depot Wi-Fi when the vehicle returns, and occasionally a physically removed drive after a serious incident. Most footage is never uploaded and ages out on the vehicle.
Can an MDVR upload all its footage to the cloud over 4G?
Not continuously. A two-camera recorder at 14 Mbps writes about 6.3 GB an hour, which takes nearly three hours to upload at 5 Mbps. Cellular is for event clips and on-demand requests; bulk footage belongs on depot Wi-Fi or stays on the vehicle.
What protocol do MDVRs use to send video?
Some use their manufacturer's own protocol; others implement JT/T 1078, the Chinese Ministry of Transport's vehicle video communication protocol, which uses RTP for transport. Either way, a gateway usually translates between the recorder and the platform operators use. A WebRTC platform such as Samvyo, based on SFU architecture, sits on the browser side of that gateway, delivering the video to operators in browsers and apps.
When should an MDVR drive be physically removed?
After a serious crash, when the vehicle cannot power up, when a very large amount of footage is needed, or when the evidence is likely to be contested. Hash the footage at removal and log every hand-off so the drive's custody can be proven later.
Is it acceptable to leave fleet footage on the vehicle instead of uploading it?
Yes, if the recorder's buffer horizon is longer than the time it takes someone to request footage. Treating the vehicle's drive as the first tier of the archive avoids moving video nobody will watch, with on-demand retrieval over cellular or at the depot when it is needed.
Where should uploaded MDVR footage be stored?
Somewhere that preserves timestamps, vehicle identity and custody records, under a retention policy you set. Samvyo keeps recording processing and storage on infrastructure you control, so the location and lifetime of uploaded fleet footage are your decision rather than a provider default.
