Why live streams run behind broadcast television

There is a familiar experience during a big match: a noise goes up from a neighbouring flat, or a phone buzzes with a notification, and only afterwards does the goal appear on your screen. The delay is real, it is usually measured in tens of seconds, and it is almost never caused by your connection.

It is the accumulated cost of the steps that make streaming work at all. Each one buys something — reliability, scale, quality — and pays for it in time.

The short answer

Conventional streaming typically runs somewhere between roughly 20 and 45 seconds behind the live event, against a handful of seconds for terrestrial broadcast. The bulk of that gap comes from two places: video is cut into segments that must be finished before they can be sent, and players deliberately hold several seconds in reserve so that a moment of network trouble does not stop playback.

Both are deliberate. Neither is a fault.

The latency budget, stage by stage

The delivery chain itself — encoding, packaging, CDN, player — is described in how streaming video actually reaches your TV. What follows is only what each stage costs in time.

Capture and contribution

Before anything reaches a streaming platform, the pictures have to get from the venue to the broadcaster: cameras, vision mixing, commentary, and a contribution link back to base. Broadcast pays this cost too, which is why even terrestrial television is not instantaneous.

Encoding

Live encoding has to happen in real time, in several qualities at once. Modern encoders are fast, but compression works partly by looking at how frames relate to one another, which means holding a short window of video before emitting it.

Segmenting — the big one

This is the largest single contributor in conventional streaming, and the least obvious.

Streaming delivers video as a series of discrete files. A six-second segment cannot be published until all six seconds of it have happened — the encoder must wait for the event to occur before it can finish the file. Players then typically want two or three complete segments in hand before starting.

With six-second segments and a three-segment target, that alone is around eighteen seconds, before any network time is counted.

Distribution

Segments propagate through the CDN to the edge server that will answer your request. For popular live content this is fast, because the first viewer in a region pulls the segment into cache for everyone behind them. It is rarely the dominant cost.

Player buffering — the other big one

Finally, the player holds a reserve. This is the same buffer that protects on-demand playback, and for live it is doing something specific: absorbing variation so that a brief slow patch produces a quality change rather than a stall.

There is an unavoidable trade here. A player that holds less is closer to live and stalls more often. A player that holds more is further behind and far more stable. Services generally choose stability, because for most viewers a stall is more annoying than a delay they cannot directly perceive.

Why broadcast is quicker

Terrestrial broadcast avoids most of this by not having the same problem to solve. It transmits one continuous signal to everyone simultaneously. There are no per-viewer requests, no segment files, no cache hierarchy, and no adaptive negotiation — so there is nothing to buffer against beyond a small fixed decode delay.

That is the enduring structural advantage of one-to-many transmission, and it is one of the arguments behind ATSC 3.0 and the recurring interest in broadcast delivery to mobile devices.

The trade runs the other way too. Broadcast cannot offer a different quality to each viewer, cannot let you pause, and cannot reach a device outside its transmitter's coverage. Streaming's latency is the price of the flexibility broadcast does not have.

What low-latency streaming changes

Low-latency modes exist and are widely deployed for sport. They attack the two largest costs — segmenting and buffering — without abandoning the CDN model that makes mass scale affordable.

Chunked transfer

The key idea is to stop waiting for whole segments. With chunked CMAF, a segment is subdivided into much smaller chunks, and the server begins sending each chunk as soon as it is written rather than holding the complete segment. The player can start decoding almost immediately.

This is what LL-HLS and LL-DASH are built on. The segment structure that makes caching work is preserved; what changes is that delivery begins before the segment is finished.

What it achieves

In practice these approaches bring live streaming down into the low single-digit seconds — comparable to, and sometimes better than, traditional broadcast — at the cost of tighter operational requirements throughout the chain. Every element, including the CDN, has to support the mode correctly, and the reduced buffer leaves less room for error on a poor connection.

WebRTC is included because it is often raised as the obvious answer. It is genuinely sub-second, and it is the right tool for two-way communication and small interactive audiences. It is a poor fit for a large live broadcast, because it does not benefit from CDN caching in the same way — which is precisely the mechanism that makes streaming to millions economically possible.

What a viewer can and cannot do about it

Mostly this is not yours to fix, and it is worth knowing that before spending an evening on it.

• A faster connection will not help much. The dominant costs are segmenting and buffering, neither of which is bandwidth-limited. Going from 100 Mbps to 1 Gbps changes essentially nothing here.
• A wired connection helps stability, not latency. Ethernet reduces the variability that causes stalls and quality drops. It does not move you closer to live.
• Check for a low-latency setting. Some services and devices expose one. If offered, it is doing real work — and may be slightly more prone to buffering.
• Different services will differ, legitimately. Two services covering the same event can be many seconds apart because they chose different segment lengths and buffer targets.
• Mute the notifications. If being spoiled is the actual problem, the alerts are the thing you control.

Terms used here are defined in the glossary. More delivery coverage is in the Streaming hub.