If you arrived here from the business version, you’re in the right place. That piece covered the “what” and the “why” — where edge stops and why a transport layer has to exist. This is the companion “how”: the same story at the packet level, for the engineer who has to build or evaluate it. No re-run of the business case — we pick up exactly where it left off.
Here is the mental model most people start with: the dashcam streams video, the command-centre dashboard plays it, done. At the packet level, almost every word of that sentence is wrong. The camera doesn’t speak a protocol the browser understands. The vehicle’s uplink can’t serve more than one viewer. And “streams” quietly hides three separate network hops, each with its own failure mode. A working fleet video streaming architecture is precisely the set of components that make that naive sentence true anyway — despite the protocol mismatch, the constrained uplink, and the unreliable network of a vehicle doing 100 km/h.
This piece walks that media path leg by leg — the same discipline the RTMP vs SRT vs WebRTC framework applies to streaming generally: don’t pick a protocol, understand each leg of the pipeline and choose deliberately at each one.
Why the Edge Device Can’t Just Stream (At the Packet Level)
The business version framed edge’s limits as capabilities it lacks. At the network layer, those limits are more concrete — and more absolute.
Uplink asymmetry. Cellular connections are built for download, not upload. A moving vehicle’s usable uplink is a fraction of its downlink, and it fluctuates with signal, tower load, and speed. Continuous video upstream is already near the edge of what the radio can sustain.
One origin, no fan-out. The device has a single radio and a single uplink. To serve N viewers directly it would have to upload N copies of the same stream — multiplying the one thing that’s already scarce. The fan-out has to happen somewhere with real bandwidth, which is not on the vehicle.
Protocol mismatch. MDVRs and IP cameras emit RTSP/RTP, or a vendor-proprietary variant. No web browser can consume RTSP natively — there is no plugin era to fall back on anymore. The feed has to be translated before a browser can touch it.
NAT and mobility. The vehicle sits behind carrier-grade NAT, and its IP address changes as it hands off between towers. You cannot simply “connect to the camera” — there’s no stable, reachable address to connect to.
So before a single viewer sees anything, the feed has to be turned into something a browser speaks. That translation is the first real problem in the pipeline.
The RTSP-to-Browser Problem
Cameras speak RTSP/RTP. Browsers speak WebRTC (for real-time) or HLS/DASH (for buffered playback). There is no direct path between the two — RTSP assumes a persistent client that browsers don’t provide. Bridging the gap is unavoidable, and there are three ways to do it, each with a different latency cost.
1. Transcode and repackage to HLS / LL-HLS. A server ingests the RTSP feed and re-segments it into HLS. It plays everywhere with zero client work, but latency lands at 2–8 seconds (LL-HLS pushes toward ~2s). Fine for “glance at the feed,” wrong for reacting to an incident as it happens.
2. RTSP-to-WebRTC gateway. A gateway pulls the RTSP stream, unwraps the RTP media, and republishes it as WebRTC. Where the camera’s codec already matches (H.264 baseline is the common case), this is repackaging — not transcoding — so it stays sub-second. This is the right answer for live monitoring. The cost is running the gateway (per-stream or pooled) and handling codec alignment when a camera emits H.265 or something exotic, which forces a transcode.
3. Native WebRTC / WHIP from the device. If the device — or an on-vehicle agent — can originate WebRTC directly via WHIP, you skip RTSP bridging entirely. Architecturally the cleanest path, but it depends on device capability you usually don’t control, since the camera vendor does.
Bridging gets one stream into one browser. But fleet monitoring is never one viewer — a dispatcher, a safety lead, and an insurer may all need the same feed at once. That’s a different problem, and it’s the reason the SFU exists.
The SFU: How One Feed Reaches Many Viewers
There are three ways to get a live stream from one source to many viewers, and only one of them survives contact with a fleet.
Mesh (peer-to-peer). Every viewer connects directly to the source, so the source uploads one copy per viewer. It collapses past a handful of participants and is a non-starter on a vehicle uplink that can barely sustain one.
MCU (Multipoint Control Unit). A server decodes every stream, mixes them into a single composite, and re-encodes it. That re-encode is CPU-expensive, adds latency, and throws away per-stream control. For fleet monitoring — where you want each vehicle as its own independently controllable feed — it’s the wrong tool.
SFU (Selective Forwarding Unit). The server receives one upstream copy and selectively forwards the packets to each subscriber, with no re-encoding. Low added latency, far lighter CPU than an MCU, and it scales to many viewers. The vehicle uploads exactly once — to the SFU — and the SFU does the multiplication. mediasoup, Janus, LiveKit, and Jitsi Videobridge are all SFUs, and every serious real-time platform is built on this pattern.
One caveat worth stating plainly: an SFU is bandwidth-bound. Its egress is viewers × bitrate, so at fleet scale it needs horizontal scaling — multiple SFU nodes, routing, and sometimes cascading between them. In a fleet video streaming architecture this is the component that scales with your audience, not your fleet. It solves fan-out; it doesn’t make bandwidth free.
Fan-out solved. But “live” is a promise about time, and every component we’ve added spends some of it. So let’s account for the milliseconds.
The Latency Budget of a Fleet Video Streaming Architecture
“Live” isn’t a binary — it’s a budget. Every leg of the path spends a slice of it, and whether the result is genuinely real-time depends on how you spend. Here’s a realistic glass-to-glass breakdown for the WebRTC path.
| Leg | Typical budget | Where the time goes |
|---|---|---|
| Capture + encode (device) | 30–100 ms | Sensor readout and encoder settling |
| Vehicle → ingest (cellular) | 50–150 ms | First hop; jitter and tower handoff are the real risk |
| Bridge (RTSP → WebRTC) | 10–50 ms | Repackaging only; a transcode adds hundreds |
| SFU forward | 5–20 ms | Packet forwarding, no re-encode |
| SFU → viewer (last mile) | 20–80 ms | Depends on the viewer's own network |
| Jitter buffer + decode/render | 50–150 ms | Browser smooths jitter at the cost of delay |
| End-to-end (WebRTC path) | ≈300–700 ms | "Live" that is actually live |
| End-to-end (HLS path) | 2–8 s+ | Universal playback, but not real-time |
The takeaway isn’t the exact numbers — it’s the shape. The WebRTC path lands comfortably under a second. The moment you insert transcoding or HLS packaging into the live path, you blow the real-time budget by an order of magnitude. Protocol choice at the bridge is what decides whether “live” is a fact or a label.
But that budget assumes the network is there at all. On a moving vehicle, it frequently isn’t — and that’s where the honest hard problems live.
The Hard Part: Offline, Rewind, and Recovery
Everything above assumes a live path from vehicle to viewer. When the vehicle loses coverage — a tunnel, a dead zone, a gap between towers — the live feed is simply gone. No SFU can forward packets that never arrived. This produces two problems that the streaming layer cannot solve on its own, and it’s worth being honest about them.
Rewind. “Show me the last thirty seconds” assumes something stored those seconds. An SFU forwards packets in real time; it doesn’t keep a per-vehicle history. The frames you want to rewind to are on the device — which recorded them locally, exactly the thing edge is good at — not in the transport layer.
Offline recovery. Retrieving footage from a coverage gap requires two things the SFU doesn’t provide: the device must have held that footage, and it must expose a footage-request path — a device-level API or command channel — that the platform can call once connectivity returns.
Here is the limitation stated plainly: rewind and offline recovery cannot be solved at the SFU layer alone. They require cooperation from the camera or MDVR — device-level access or a footage-request API — and that access is often controlled by the camera vendor, not the platform builder. It is the one part of a fleet video streaming architecture the transport layer cannot supply by itself. When the device grants it, you can stitch live streaming and on-demand recovery into a single experience. When it doesn’t, live monitoring and archived-footage retrieval remain two separate systems bolted together. Knowing which situation you’re in is the difference between an architecture that demos well and one that holds up on a highway.
Which is why choosing how to build this layer is less a feature comparison than a question of how much of the pipeline you want to own.
How Teams Build a Fleet Video Streaming Architecture
The business version compared these three paths on cost and fit. Here they are on architectural control — how much of the media path you assemble and operate yourself.
Open-source media servers. mediasoup, Janus, or LiveKit give you the SFU; you assemble the bridge, signaling, TURN, recording, and scaling around it. mediasoup is a library you build an application on top of; LiveKit is closer to a batteries-included SFU with an SDK. Maximum control, maximum operational ownership. Right when the media path is core to your product and you have the specialists to run it.
Cloud video APIs. Agora, Daily, or Cloudflare give you a cloud SFU and SDKs — fan-out and (sometimes) bridging as a service. You trade away control over where media routes, and RTSP-ingest support varies, so check whether the provider bridges RTSP for you or expects the device to originate WebRTC. Right when speed to production outweighs owning the routing.
Commercial white-label platforms. Platforms in this category — Samvyo is one — deliver the SFU, the bridge, and recording as a deployable unit you run on-premise, or as a managed cloud deployment on AWS, DigitalOcean, or Hetzner, flat-licensed and embeddable under your brand. Right when the media path has to sit inside your own product and inside controlled infrastructure. Where it doesn’t fit: if you only need occasional clip pull, the edge upload you already have covers it — and if third-party cloud routing is acceptable, a full deployable stack is more than the problem requires.
Whichever path a team takes, the architecture underneath is the same shape — and that shape is the real takeaway.
The Bottom Line
Strip away the vendor names and a fleet video streaming architecture is four moving parts: a bridge that turns camera protocols into browser protocols, an SFU that turns one upstream into many downstreams, a latency budget spent carefully enough that “live” stays true, and a recovery path that admits the network won’t always be there. Edge owns the source. This layer owns everything between the source and the human watching. Get that division right, and each half does the job it’s actually built for.
What’s Next?
Want the decision-maker’s version — the “what” and the “why” without the packet-level detail? The companion business piece covers where edge stops, why this transport layer has to exist, and how to think about sourcing it — in language you can forward to a non-engineer stakeholder: link to business version.
Frequently Asked Questions
Can you stream an RTSP camera directly to a web browser?
No. Browsers don’t support RTSP natively, so a bridge is required — an RTSP-to-WebRTC gateway for sub-second latency, or a transcode-to-HLS path when you can tolerate several seconds of delay in exchange for universal playback.
What is an SFU in video streaming?
A Selective Forwarding Unit is a media server that receives one upstream copy of a stream and forwards its packets to many subscribers without re-encoding. That makes it low-latency and far lighter on CPU than an MCU (which mixes and re-encodes), and it scales where peer-to-peer mesh cannot.
How do you achieve sub-second latency in fleet video?
Keep a WebRTC path end-to-end: bridge RTSP to WebRTC by repackaging rather than transcoding, forward through an SFU, and keep HLS packaging out of the live path. Budgeted leg by leg, realistic glass-to-glass latency lands around 300–700 ms.
Why can’t the vehicle just send video to every viewer directly?
A vehicle has one radio and one constrained cellular uplink. Sending a separate copy to each viewer multiplies the scarcest resource in the system. An SFU accepts one upstream copy from the vehicle and fans it out from a well-connected server instead.
Can you rewind or recover offline footage through the streaming layer?
Not through the SFU alone. Live transport forwards packets in real time and keeps no per-vehicle history. Rewind and offline recovery depend on footage stored on the device and a device-level footage-request API to retrieve it once connectivity returns — access the camera vendor often controls.
RTSP to WebRTC or HLS — which for live fleet monitoring?
WebRTC for real-time incident response, where sub-second latency matters. HLS or LL-HLS only when a multi-second delay is acceptable and you want the simplest, most universal playback. For monitoring an unfolding situation, WebRTC is the one that keeps “live” honest.
