Live View Without Paying For It

In one line: almost no camera is being watched at any moment, so the live path should exist only while someone is looking.

Where the latency goes

Glass-to-glass latency is a sum, and naming the terms is what lets you argue about a budget instead of guessing.

capture + encode        ~50-100 ms   camera hardware
segmentation            = segment duration, because a segment
                          cannot be published until it is closed
upload to origin        ~20-100 ms
CDN / distribution      ~20-100 ms
player buffer           usually 2-3 segments before playback starts
decode + render         ~50 ms

One term dominates and it is not the network. Segmentation plus the player's buffer means latency scales with segment duration, multiplied by however many segments the player insists on holding.

That is why classic HLS is slow. With six-second segments and a three-segment buffer, you are 18 seconds behind before adding anything else, and real deployments land in the 20–30 second range. No amount of network tuning fixes it, because the delay is structural.

The three protocol families

For a 1–2 second requirement, this table does the work. Classic HLS is out by an order of magnitude. Low-latency HLS sits just above the target at its typical range and can reach it with tight configuration. WebRTC clears it comfortably and costs far more.

How low-latency HLS gets there is worth knowing mechanically, because "use LL-HLS" without the mechanism is a name-drop. Three additions do the work:

• Partial segments. A segment is published in pieces of roughly 200 ms as they are encoded, so a player can begin consuming a segment that is still being written. Latency decouples from segment duration.
• Preload hints. The playlist advertises the URL of the next part before it exists, so the player's request is already in flight when the bytes appear.
• Blocking playlist reload. The player asks for a playlist version that does not exist yet and the server holds the request open until it does, replacing a polling loop with a push.

The recommended configuration pairs one-second segments with 200 ms parts. It runs over ordinary HTTP and ordinary CDNs, which is the entire reason to prefer it: you get near-real-time delivery while keeping the cost curve of cached HTTP.

When WebRTC is the right answer is narrower than enthusiasm suggests. It genuinely delivers sub-second, and it is the only option if an operator is driving a pan-tilt-zoom camera, where the feedback loop makes anything above a second unusable. But a single media server process handles on the order of a hundred to a few hundred concurrent viewers, scaling is linear in connections, and there is no CDN to absorb the load. Reported cost differences against HLS run ten to a hundred times per viewer.

The asymmetry that makes it affordable

Here is the observation that resolves the cost question, and it comes straight from the opening lesson.

A thousand cameras does not mean a thousand live streams. It means a thousand cameras of which perhaps twenty or fifty are on someone's screen right now, and usually far fewer at three in the morning.

So the live path is created on demand, and destroyed when the last viewer leaves. Nothing packages a camera for live delivery unless a person is watching it. The archive path runs continuously for all thousand; the live path runs transiently for the few.

Combine that with the camera's substream and the numbers become small. Fifty concurrent live views of a 512 Kbps substream is 25 Mbps of egress — trivial next to 4 Gbps of ingest. The expensive-sounding requirement turns out to be the cheap part of the system, and only because it was scoped to actual viewers rather than to camera count.

The wall display exception

One case does break the assumption: a security operations room with a video wall showing sixty-four cameras continuously, twenty-four hours a day. Those cameras genuinely always have a viewer.

It is still a small, bounded, known set, and it is a good argument for a persistent packaging path for a configured subset while the rest stay on-demand. The design principle survives — you pay for cameras being watched — but the configuration acknowledges that some are always watched.

Next: finding one specific minute inside six hundred million objects.