How streaming video actually reaches your TV

Streaming is often described as though the video simply travels down the internet to your television. It does not. What actually happens is closer to a small manufacturing process: the same programme is produced in several different qualities, cut into short pieces, indexed, distributed to servers near you, and then reassembled on the fly by a player that is continuously deciding which version you should be watching.

Knowing the shape of that chain is useful for one practical reason. When playback goes wrong, the symptom rarely tells you which link failed — but the link determines the fix.

Stage one: encoding

A finished programme arrives as a very large file — far too large to send over a domestic connection in real time. Compressing it is the job of a codec, the algorithm pair that squeezes video down for transmission and expands it again for playback.

Three codecs cover most of what reaches televisions today:

The decisive constraint is not which codec is best. It is which codec the device at the other end can decode in hardware, which is the subject of AV1, HEVC and the codec transition. A television with a dedicated AV1 decoder plays AV1 without effort; one without it must fall back to software decoding, which on a low-power streaming stick often means dropped frames or no playback at all. This is why services keep publishing in more than one codec long after a newer one exists, and why codec support is one of the more consequential differences between streaming platforms.

The output of this stage is not one file. It is a ladder — the same programme encoded several times over, at different resolutions and bitrates, from something that survives a weak mobile connection up to full-quality 4K.

Stage two: packaging and the manifest

Each rung of that ladder is then cut into short segments, typically two to ten seconds long. Alongside them sits a small text file — the manifest — that lists what exists: which quality levels are available, what bitrate and resolution each one is, where its segments can be found, and what audio and subtitle tracks accompany them.

Manifest

The index file a player reads before it plays anything. It describes every available quality level, audio track and subtitle track, and where the segments live. Called a playlist in HLS and an MPD in DASH.

Two formats dominate. HLS, originally Apple's, is the most widely deployed on the open internet. DASH is the equivalent standard from MPEG. They differ in file format and syntax rather than in concept, and most large services publish both. CMAF, a common container developed to end the duplication, allows the same underlying segments to be referenced by both an HLS playlist and a DASH manifest — halving storage and improving cache efficiency.

If the content is licensed, this is also where DRM is applied: the segments are encrypted, and the player must obtain a licence from a separate server before it can decrypt them. DRM is worth understanding because it produces a distinctive and otherwise baffling symptom — a stream that plays perfectly but refuses to go above 540p or 720p on a particular device, because the service requires a level of hardware-backed protection that device cannot provide.

Stage three: the CDN

Segments are then pushed out to a content delivery network — a large set of servers distributed geographically, each holding cached copies. When your player requests a segment, it is answered by a nearby server rather than by the publisher's origin.

The reason is not only speed. It is that video is requested in enormous volume, and serving every request from one origin would be both slow and ruinous. Caching also means that a popular programme is effectively free to serve repeatedly — the first request in a region pulls it into the local cache, and everyone after that is served from there.

The practical consequence for a viewer: two services can behave very differently on the same connection, because they are being served from different places by different networks. "My internet is fine, it is just this one service" is a real and common situation, not a misdiagnosis.

Stage four: the player and adaptive bitrate

This is where the interesting decisions happen. The player on your device reads the manifest, picks a starting quality, requests segments, and then keeps re-deciding.

Adaptive bitrate streaming is the name for that loop. After each segment the player has new information: how long the download took, how full its buffer is, whether throughput is trending up or down. If segments are arriving faster than they are being played, it can step up the ladder. If the buffer is draining, it steps down — quickly, because running out entirely means visible stalling.

Buffer

The stretch of video already downloaded but not yet shown. It absorbs short-term network variation. Playback stalls only when it empties completely.

This explains the two symptoms viewers most often report, and why they are different problems:

• A picture that goes soft for a few seconds, then recovers. The adaptive logic working correctly. It chose to protect continuity over detail. Nothing is broken.
• Playback that stops with a spinner. The buffer emptied. The player could not fetch even the lowest rung fast enough, or a request failed outright.

The first is a design feature and is usually not worth chasing. The second is a genuine fault, and the useful question is which link caused it — the connection, the local network, the device's capacity to decode, or the service itself. Diagnosing buffering works through that, and how much internet speed streaming actually needs covers whether bandwidth is even a plausible cause.

Why the first few seconds look worse

At the moment you press play the player has no measurements. It has to guess a starting quality, and guessing high risks an immediate stall — the worst possible first impression. So most players start conservatively and climb once they have data. A brief soft opening that sharpens within a few seconds is the system working as intended.

Stage five: decoding and display

Finally the device decodes the segments and puts frames on screen. Two things can still change what you see at this last stage.

Decoding capacity. If the device lacks a hardware decoder for the codec in use, it may drop frames or refuse the higher rungs entirely — regardless of how good your connection is.

Display processing. The television then applies its own scaling, motion handling and tone mapping. Two sets showing the identical stream can look noticeably different, and neither is misrepresenting what arrived.

Reading a fault backwards

Because the chain is ordered, a symptom narrows the candidates:

Where this differs for live

Everything above applies to live streaming too, with one addition: time. A live stream must be encoded, packaged, distributed and buffered while the event is still happening, and each of those steps costs seconds. That is why a streamed match can run visibly behind a broadcast of the same match, and it is a separate subject with its own trade-offs — covered in why live streams run behind broadcast television.

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