An operator clicks the one suspicious camera and waits three to five seconds for it to fill the screen. That wait is live view latency, and it lands at the worst possible instant. Here's what opens the gap, why almost nobody measures it, and how a system built for live video shuts it.
A monitoring operator watches a hundred cameras on one wall. Most of a shift, nothing on it needs a second look. Then something does — a figure along a fence line that should be empty. The operator clicks that tile to bring it full-screen, leans in, and waits. On a lot of systems that wait runs three to five seconds, and for those seconds the one camera that matters is the one they cannot see. The gap has a name — live view latency — and unlike most latency, it opens at the exact instant someone decided to look.
What you actually lose
First, the correction that matters to anyone evaluating this seriously. You do not lose the recording. In a normal VMS or NVR deployment, every camera records continuously on the server the moment it connects, no matter what any operator has on screen. Those five seconds sit in the archive, and you can scrub back to them later.
What you lose is live attention at the moment you chose to spend it. The operator flagged that tile because something looked wrong now. Going blind for five seconds starting now is the expensive kind of blind. If the response you're trying to run is an intervention — a talk-down over a speaker, a call to a patrol, a dispatch — live eyes are the whole mechanism, and a clip pulled from the archive an hour later does none of that work.
So the honest framing isn't “lost footage.” It's a live view gap that opens at the least convenient second on the clock.
Which raises the obvious question: why does clicking a camera cost seconds at all?
Where live view latency comes from
Showing a hundred live feeds on one wall is expensive, so systems economize, sensibly. Each tile in the grid usually renders a low-resolution, low-framerate substream — sometimes only a few frames a second. A hundred of those is survivable. A hundred full-resolution main streams decoded at once would melt most workstations.
When the operator expands a tile, the client switches from that thin substream to the camera's high-resolution main stream. Three things have to happen before a single sharp frame appears, and they stack:
| Step | What happens | Typical cost |
|---|---|---|
| Stream switch | Client subscribes to the high-res main stream | a round trip or two |
| Keyframe wait | Decoder can't draw until an I-frame (IDR) arrives | 0–4 s, set by the keyframe interval |
| Buffer | Player buffers briefly before playback starts | a few hundred ms |
The middle row is the one that hurts. Video isn't a sequence of full images; it's an occasional full frame — the keyframe, or IDR — followed by a run of delta frames that only describe what changed. A decoder can't render anything until it receives a keyframe to build from. If the camera emits one every two to four seconds and the operator clicked one second after the last, the player sits idle until the next one arrives. Add the switch and the buffer, and five seconds isn't an outlier. On HLS-based viewers, where segments are several seconds long by design, it's worse.
The strangest part is that a gap this real never shows up anywhere you'd look for it.
Why almost nobody measures it
The gap is invisible in every channel that normally catches defects. It doesn't show up in the recording, because the recording is fine. It doesn't trip an alert. It doesn't dent uptime or frame-loss stats — the camera never went down and no packets dropped. The only person who experiences it is the operator, in the moment, and operators rarely have a way to file “the screen made me wait” as a bug.
So it survives, unmeasured, in systems that look healthy on every dashboard. The first time it costs someone the moment they were watching for, it stops being invisible.
Closing it is an architecture decision, with trade-offs worth naming out loud.
What closes the live view latency gap
Keep the stream warm. If the expanded view is already flowing to the client at full quality, or can be upgraded in place, there's no fresh subscription to negotiate. Simulcast — several quality layers from one camera and layered (SVC) encoding let a client hold a low layer for the grid tile and step up to a high layer on click, without tearing a stream down and rebuilding it.
Don't wait for the camera's next natural keyframe. In a WebRTC path, a receiver can send a Picture Loss Indication or Full Intra Request to demand a keyframe immediately, instead of waiting out the interval. A media server in the path can also cache the most recent keyframe per stream and hand it to the client the instant it subscribes, so decoding starts on the first frame rather than the next scheduled one.
Use a transport built for sub-second delivery. WebRTC targets sub-second glass-to-glass latency; segment-based delivery like HLS trades latency for simplicity and lands in the multi-second range. For a wall whose job is to react, that trade runs the wrong way.
None of this is free, and pretending otherwise is how you end up with a surprise bill. Keeping streams warm and running simulcast layers costs bandwidth and server resources; forcing keyframes more often raises bitrate. A system that closes the gap is spending compute and network to do it. For a passive review archive, that spend isn't worth it. For a control room whose job is to intervene while something is still happening, it usually is.
So the real question at purchase time isn't “does it stream” — it's how you source a live path that doesn't blink.
Build, Buy, or Deploy
- Build on open source. Media servers like go2rtc and MediaMTX handle RTSP-to-WebRTC conversion, H.264 passthrough, and keyframe handling — run and scaled by you. Maximum control over the live path and its costs. Right when live video is core to your product and you have the team to operate a media pipeline.
- Use a managed cloud relay. Fastest to a working browser view, nothing to run — but your camera feeds route through a third party, and you pay per stream as you scale. Right when speed matters more than owning the path.
- Deploy a commercial platform. A full media stack — ingest, passthrough, low-latency fan-out, recording — delivered as something you run on-premise or as a managed cloud deployment under a flat license. Samvyo is one such option: it's based on SFU architecture, keeps the media path, TURN, and recording under your control, and is designed to switch and scale streams without the click-to-fullscreen blink — resilient by design. It ships the same embeddable SDKs a CPaaS gives you, plus on-prem/managed deployment and white-label depth. Where it doesn't fit: a handful of cameras or a hobby project, where open source or a relay is plenty.
Put it together and the gap stops being a mystery.
The Bottom Line
The five seconds you lose when you expand a camera aren't lost from the archive — they're lost from live view, at the one moment an operator was actually watching. The cause is mechanical: a substream-to-mainstream switch, a wait for the next keyframe, and a playback buffer, stacked on a transport that was never built to react. Close it by keeping streams warm, forcing keyframes on demand, and carrying the live view over sub-second transport — and measure it with the one number nobody takes: time from click to first sharp frame.
What's Next?
Curious why that live view matters so much in the first place? The companion piece on proactive vs reactive surveillance explains why intervention lives or dies on the live path, and what “proactive” actually buys.
→ Proactive vs Reactive Surveillance: What “Proactive” Actually Means
→ What Is an SFU — and Why Does Every Video Platform Use One?
Frequently Asked Questions
Why does a live camera feed take several seconds to load when I click it?
Because the viewer switches from a low-res grid substream to the high-res main stream, and the decoder can't render until the next keyframe (IDR) arrives. With a two-to-four-second keyframe interval plus a stream switch and a buffer, that's often three to five seconds. WebRTC with on-demand keyframes and simulcast collapses it to under a second.
Is the footage actually lost during that gap?
No — server-side recording runs continuously regardless of what's on screen, so the archive keeps those seconds. What's lost is live view: the operator can't see the high-res feed in real time at the moment they expanded it, which matters when the point is to intervene rather than review.
What causes live view latency on a video wall?
Three stacked costs: subscribing to the high-res stream, waiting for a keyframe before decoding can start, and a short playback buffer. Long camera keyframe intervals and segment-based transports like HLS make it worse; sub-second transports and keyframe caching make it nearly disappear.
How do I measure the gap?
Time from click to first sharp frame. Click a grid tile, start a stopwatch, stop it when the full-resolution image is actually live and moving. Repeat a few times, because where you land relative to the keyframe interval changes the result. Under a second is healthy; drifting toward five means a blind window is built into your wall.
Does WebRTC remove the delay completely?
It removes most of it. Sub-second transport, on-demand keyframe requests (PLI/FIR), and simulcast layer-switching kill the two big causes — the keyframe wait and the slow transport. Some setup cost remains, but the visible gap drops from seconds to well under one.
Can Samvyo avoid the click-to-fullscreen gap?
Yes. Samvyo is based on SFU architecture with low-latency switching, so it can step a client between stream layers and serve a cached keyframe on subscribe rather than waiting for the camera's next one. Continuous recording still runs underneath, and the media path, TURN, and recording can stay under your control while the platform remains resilient by design.
