Low-latency live streaming

Ordinary HLS delivers a live stream 15 to 30 seconds behind reality. For a film that is irrelevant; for a sports match where the neighbours cheer first, or an auction, or anything interactive, it is fatal. Getting that number down means understanding where it goes, because most of it is not network delay.

Where the latency actually is

Segmentation is the big one. Classic HLS cuts the stream into segments of 6 to 10 seconds. A segment cannot be published until it is complete, so the newest available media is already one segment old before anyone can request it. That alone is most of your budget.

Player buffering multiplies it. Players traditionally hold three segments before starting, to survive network hiccups. Three 6-second segments is 18 seconds of deliberate delay.

Encoding adds its share. Lookahead and B-frames both require the encoder to see the future before emitting the present. Low-latency encoders disable both and pay in file size.

The network and CDN are the small part, typically a few hundred milliseconds. This is why “get a faster CDN” does not fix live latency.

CMAF chunks: the enabling trick

The Common Media Application Format lets a segment be split into much smaller chunks, on the order of 200 to 400 milliseconds, that can be delivered while the segment they belong to is still being written, using HTTP chunked transfer.

That single change breaks the rule that latency is bounded by segment duration. You keep long segments (good for caching and playlist size) and still publish media a fraction of a second after it is captured. Every HTTP-based low-latency scheme below is built on it.

The three options

LL-HLS is Apple’s low-latency extension to HLS: CMAF chunks published as partial segments, plus preload hints so the player can request a part that does not exist yet and have the server hold the request until it does. It reaches roughly 2 to 5 seconds glass-to-glass in practice, and the player’s tuning matters enormously; a stock configuration pointed at an LL-HLS feed will sit noticeably higher than a tuned one. LL-DASH is the equivalent on the DASH side and behaves comparably.

The great advantage is that it remains HTTP. Ordinary CDNs, ordinary caching, ordinary scale to millions of viewers, and it degrades to normal HLS on players that do not understand the extensions.

WebRTC is the different animal: a real-time protocol, usually over UDP, designed for conversation rather than broadcast. It reaches sub-second, typically 200 to 500 milliseconds, and it is the only option that consistently does.

The cost is architecture. WebRTC does not ride a normal CDN; scaling it to a large audience means media servers and a fan-out topology, which is more infrastructure and more money per viewer. It also has to survive NAT traversal, and its congestion control is prepared to drop quality hard to preserve timeliness, because that is the correct trade for a conversation and sometimes the wrong one for a broadcast.

Plain HLS/DASH remains right for anything that is not truly live.

Choosing

Match the protocol to the actual requirement, which is usually softer than the first ask suggests:

• Under a second, two-way: WebRTC. Video calls, auctions, betting, telepresence, remote control. Nothing else qualifies.
• Two to five seconds, one-to-many: LL-HLS or LL-DASH. Sports, live events, anything where “before the tweet arrives” is the real requirement. This covers most of what people mean by low latency, at a fraction of WebRTC’s operational cost.
• Ten seconds or more: standard HLS/DASH, and spend the effort on the bitrate ladder instead.

What it costs you

Low latency is not free, and the bill comes in three parts. Quality per bit drops, because the encoder cannot look ahead. Resilience drops, because the player’s buffer was what absorbed network variation; a shorter buffer means rebuffering where there used to be none. And operational complexity rises, particularly for WebRTC.

The question worth asking before any of this is how much latency the product genuinely needs. Going from 30 seconds to 5 is usually cheap and often enough. Going from 5 to under 1 changes your architecture. Those are very different projects, and a surprising number of teams commission the second when they needed the first.