A 256 GB card in a current two-camera fleet dashcam holds 36 hours and 40 minutes of footage at its Normal quality setting. At the highest setting, 14 hours and 40 minutes. After that, the oldest video is overwritten, silently, whether anyone has looked at it or not.
That is the part of store and forward video most fleets never think about. Storing is easy — every recorder does it by default. Forwarding is the hard part, and the buffer that makes store-and-forward possible is also a countdown.
When the truck drops into a dead zone — the symptom most fleets see first — the recorder keeps writing. Whether that footage ever reaches the command centre depends on three decisions: how much the vehicle can hold, what it sends first when the link returns, and how the gap is stitched back afterwards.
What store and forward video actually means in a fleet
The pattern is old and simple. Record everything locally. When a connection is available, forward what matters. When it is not, keep recording and try again later.
In a fleet it runs alongside the live path rather than replacing it. The live stream is a small, separate feed that is never buffered: a second of live view missed in a tunnel is gone as live view. What store-and-forward recovers is the recording — the full-quality video the recorder was writing the whole time. The pipeline between vehicle and command centre carries both; this post is about the second.
That distinction answers the most common misunderstanding. Store-and-forward keeps the record. It does not give you back the moment. If someone needed to act while the truck was in the dead zone, no amount of buffering helps them — which is why the forwarding strategy matters so much.
Sizing the buffer: horizon, not capacity
Recorder spec sheets quote storage in terabytes. The number that matters is hours of horizon: how long footage survives on the vehicle before it is overwritten. That is storage divided by the combined bitrate of every channel being recorded, and the bitrate is set by whoever configures the recorder, not by the hardware.
The documented figures for one current two-camera unit show how quickly the horizon moves. Its quality settings run from 8 + 6 Mbps to 25 + 10 Mbps for the front and rear cameras. On the same 256 GB card, that is the difference between about a day and a half and about fourteen hours.
Vehicle recorders built for heavier fleets carry far more. One current mobile NVR, for example, takes up to 2 TB of hard disk or 4 TB of SSD, with two drives that can mirror each other. At the same 14 Mbps two-camera load, 2 TB is roughly 13 days. Add more cameras or raise the bitrate and it shrinks proportionally.
Buyers write this down when they know to. A municipal bus-surveillance tender specified that each vehicle's recorder "must be capable of retaining a minimum of 240 hours of video". At 14 Mbps that is about 1.5 TB per vehicle — before counting a single additional camera.
The rule that falls out: size the horizon to your longest realistic gap before offload, not to your average day. A vehicle that spends a long weekend at an outstation, or a week on a rural contract, needs a horizon measured in days. A vehicle that returns to the depot every night needs much less — provided the depot can actually drain it, which is not a safe assumption.
Why forwarding can never keep up over cellular
Here is the arithmetic that shapes every store-and-forward design. At 14 Mbps, one hour of two-camera recording is about 6.3 GB. TRAI's drive tests measured 4G-only upload speeds of roughly 5 to 9 Mbps across the major operators, and that was at hotspots with a flagship handset, not from inside a moving cab.
Take 5 Mbps: uploading one hour of footage takes about 2.8 hours. The recorder produces video faster than the cellular link can carry it away, even when the link is good. A backlog that builds in a dead zone never clears on the road; it only grows.
So a fleet store-and-forward design is never "upload everything when the signal comes back". It is a priority scheme, and the question is what goes first. How many feeds fit down a moving link covers the capacity side; the design choices look like this.
Tier | What it is | How it travels |
|---|---|---|
1 · Event clips | Short clips around a trigger: harsh braking, collision, panic button, ADAS alert | Over cellular, as soon as any usable link exists. Small enough to get through a patchy signal |
2 · Requested footage | A specific window an operator or investigator asks for after the fact | Over cellular on demand, if the vehicle still holds it |
3 · Everything else | The full continuous recording | At the depot, over Wi-Fi or wired offload, or never — it ages out on the vehicle |
The event tier is what makes the whole scheme work, because clips are small. Event-triggered recording typically keeps 15–30 seconds before and 30–60 seconds after the trigger, according to the NTSB. At 14 Mbps a 90-second clip is about 160 MB — roughly four minutes of upload at 5 Mbps. That fits through a signal that could never carry an hour of continuous video.
What store-and-forward still loses
This is the honest part, and it is where most vendor diagrams stop. Store-and-forward is a strong pattern. It is not a guarantee. Four things still get lost.
- The live moment. Covered above, and worth repeating because it is the one people forget: buffering recovers evidence, not response time.
- Footage that ages out before anyone asks for it. If the horizon is shorter than the time between an incident and someone noticing it, the footage is gone. Complaints and claims can surface days after the event.
- The last seconds before a crash. The NTSB documented a motorcoach crash in which the onboard system "recorded critical precrash information but … stopped recording immediately before impact". Power loss and physical damage are exactly what a crash causes. Some recorders ship with super-capacitors for power-loss protection — worth checking for on any spec sheet.
- The recorder itself. Footage stored only on the vehicle leaves with the vehicle. Theft, fire or a write-off takes the evidence with it, which is the strongest argument for pushing event clips off the truck immediately rather than at the depot.
Every one of those losses is shaped by the same two numbers: how long the vehicle can hold footage, and how quickly it can hand the important part off.
Backfill: stitching the gap back into the record
When forwarded footage finally arrives, it has to land in the right place on the timeline. That sounds trivial and is not, because the footage was timestamped by the vehicle's clock, not the server's.
Three things make backfill trustworthy. The recorder's clock should be disciplined by GPS time rather than left to drift. Each uploaded file should carry its own start time, channel and vehicle identity, so it can be placed without guesswork — the same discipline timestamps that hold up later depend on. And the gap itself should be visible: a command centre timeline that shows "live lost 14:02–14:19, recording backfilled 21:40" is more useful, and more defensible, than one that silently looks complete.
The design choice most often skipped is the last one. A backfilled record that hides where it was backfilled is easier to look at and harder to trust.
The Bottom Line
Store-and-forward keeps the record through a dead zone, but the on-vehicle buffer is a countdown and the cellular uplink cannot keep pace with the recorder. That forces a priority scheme: event clips over cellular straight away, requested footage on demand, and the full recording at the depot or not at all.
Size the horizon to your longest gap, push event clips off the truck immediately, and make backfilled gaps visible rather than seamless.
What's Next
For the routes footage can take off the vehicle — cellular, depot Wi-Fi, a pulled drive, or staying on the recorder — and when each one fits, see getting in-vehicle recorder footage off the truck.
Frequently Asked Questions
What is store and forward video?
A recording pattern in which video is saved locally first and uploaded later, when a connection is available. In a fleet, the recorder writes continuously to its own drive or card, and footage is forwarded to the command centre when the vehicle has signal or reaches the depot. It preserves the recording through dead zones; it does not preserve live viewing.
How long does a fleet dashcam store footage before overwriting it?
It depends on storage size and the combined bitrate of every camera. One current two-camera dashcam documents about 36 hours on a 256 GB card at Normal quality, and about 14 hours at its highest setting. Heavier vehicle recorders with 2 TB drives hold roughly 13 days at a similar load.
Why can't a fleet dashcam just upload everything when signal returns?
Because the recorder produces video faster than a cellular uplink can carry it. At 14 Mbps, one hour of two-camera footage is about 6.3 GB, which takes roughly 2.8 hours to upload at 5 Mbps. Fleets therefore upload short event clips over cellular and move the full recording at the depot.
What gets uploaded first in a store-and-forward fleet system?
Event clips — short windows around a harsh-braking alert, collision or panic button, typically 15–30 seconds before and 30–60 seconds after. They are small enough to get through a weak signal. Requested footage comes next, and the full continuous recording is usually left for depot offload.
Can store-and-forward lose footage?
Yes, in four ways: footage that is overwritten before anyone asks for it, the final seconds before a crash if power or storage is damaged, footage lost with a stolen or destroyed vehicle, and anything that needed live action. Longer buffer horizons, power-loss protection and immediate event-clip upload reduce each one.
Where should forwarded fleet footage be stored?
Somewhere its timestamps, vehicle identity and gaps are preserved, so backfilled video can be placed and trusted later. Samvyo, based on SFU architecture, keeps recording processing and storage on infrastructure you control, which means where backfilled fleet footage lands and how long it stays is your policy decision rather than a provider default.
Is store-and-forward the same as event-based recording?
No. Event-based recording decides what gets saved as a clip; store-and-forward decides when saved footage is moved. Most fleet systems combine them: record continuously, flag events, forward the events immediately and the rest later. The NTSB notes continuous systems capture pre-crash context that event-only systems miss.
