Streaming Video: DASH and Adaptive Bitrate

The problem: one video, many viewers, every network different

You have spent this whole rung making the web feel close: caching so you do not refetch what you already have, a content delivery network of edge servers so the bits start their journey from a warehouse near you, anycast and load balancing so your request lands on a healthy machine nearby. Now we point all of that at the single hardest thing to deliver well: video. A movie is not a 50 KB web page. It is gigabytes, it must arrive in order, and it must keep playing smoothly for hours over a connection whose speed you do not control and that can change minute to minute.

And here is the cruel part. Your network is not one fixed speed. You watch on the train and the signal fades through a tunnel; someone else in the house starts a huge download; you walk from strong Wi-Fi into a weak corner. If the video were sent at one fixed quality, you would be stuck choosing between two bad options: pick a quality so low it looks awful even when your link is great, or pick a high quality that stalls and spins the moment your link dips. The whole craft of modern streaming is escaping that trap — and the trick, surprisingly, is to stop treating video as one long download at all.

The key idea: chop the movie into tiny chunks

Modern HTTP streaming, whose two big standards are DASH (Dynamic Adaptive Streaming over HTTP) and Apple's HLS (HTTP Live Streaming), begins by cutting the video into many short segments — usually two to ten seconds each. Crucially, the server encodes the whole movie several times over, once at each of several qualities: maybe a tiny 240p version, a 480p, a 720p, a crisp 1080p, and a 4K. Every quality is cut at the same time boundaries, so segment number 37 of the 240p copy covers exactly the same moment of the film as segment 37 of the 1080p copy. They are interchangeable slices of the same instant, just heavier or lighter.

The server also writes a small text file — DASH calls it the MPD, the manifest — that is essentially a menu. It lists every quality available, the resolution and bitrate of each, and where to fetch each segment. When you press play, the player downloads the manifest first. It does not download a video; it downloads the table of contents and the list of qualities, and from that moment on the player is the one making every decision. The server's job shrinks to something it is already brilliant at: handing out small files over HTTP when asked. There is no special video protocol, no streaming session held open on the server. Each segment is just another HTTP GET, like fetching an image.

Adaptive bitrate: the player chooses, segment by segment

Now the heart of it. Because every segment exists at every quality, the player can choose a different quality for each segment as it goes. This is adaptive bitrate streaming, often shortened to ABR. After it downloads one segment, the player measures how that fetch went — chiefly, how much throughput it actually got. If the segment arrived quickly with bandwidth to spare, the player reaches for a higher quality next time. If it arrived slowly and only barely in time, the player drops to a lighter quality so the next chunk surely arrives before it is needed. The video quality steps up and down to track your real, changing connection, instead of betting everything on one guess up front.

But throughput alone is jumpy and easy to misread, so a good ABR player leans on a second, steadier signal: the playout buffer. As segments arrive, the player does not show them instantly; it stockpiles a few seconds of decoded video ahead of where you are watching. That buffer is your shock absorber. If your link briefly vanishes in a tunnel, the player keeps playing from the buffer while it waits, and you never notice. So a smart player watches its buffer level like a fuel gauge: when the buffer is comfortably full, it can afford to gamble on higher quality; when the buffer is draining toward empty, it grabs the lowest quality it must to refill — because a slightly soft picture is always better than a frozen one with a spinner.

1. Press play. The player fetches the manifest and learns the list of qualities and where each segment lives.
2. To start fast, it requests the first segment at a cautious, low quality — better to begin in seconds than to wait for a heavy 4K chunk.
3. It times that download and notes the throughput it actually got, while filling the playout buffer ahead of the playhead.
4. For the next segment it picks a quality the measured throughput can comfortably sustain — stepping up if the buffer is healthy, down if it is draining.
5. It repeats this every segment for the whole movie, so quality continuously tracks your changing link without you ever touching a setting.

Why HTTP, why segments, and how the CDN makes it cheap

Step back and admire how the pieces lock together. Each segment is a normal HTTP GET, which means the colossal popularity problem solves itself with caching. When a hit show drops, millions request segment 1 of the 1080p version within minutes — but the first request to each edge fetches it from the origin, and every request after that is a cache hit served straight from the edge server near each viewer. A handful of distinct files (a few qualities times the number of segments) cover an entire audience. The origin sees a trickle; the CDN absorbs the flood. This is the local-warehouse idea from earlier guides, now doing its heaviest lifting.

Pushing the decision out to the player is the second half of the design, and it follows the same end-to-end spirit you have seen all through this ladder: keep the middle of the network dumb and simple, and put the cleverness in the host at the edge. The server does not track your link speed or babysit your session — it cannot even see where the congestion is. But your player feels every stall and surge directly, segment by segment, so it is exactly the right place to make the quality decision. The network stays a simple file server; the intelligence lives where the experience lives.

  manifest (MPD) lists the same movie at several bitrates:

  time:     seg 1     seg 2     seg 3     seg 4     ...
  1080p  [  6 Mbps |  6 Mbps |  6 Mbps |  6 Mbps ]
   720p  [  3 Mbps |  3 Mbps |  3 Mbps |  3 Mbps ]
   480p  [  1 Mbps |  1 Mbps |  1 Mbps |  1 Mbps ]
   240p  [  0.3M   |  0.3M   |  0.3M   |  0.3M   ]

  player path (measured link wobbles):  720p -> 1080p -> 480p -> 720p
              (good)   (great)   (dip!)   (recovered)

Honest limits: latency, fairness, and what live video really wants

ABR is brilliant, but be honest about what it does and does not buy. First, a misconception worth killing: adaptive streaming does not make your connection faster. It cannot beat physics or conjure bandwidth you do not have. On a truly weak link you simply get a lower-resolution picture — gracefully, without stalls, which is the real win. ABR trades resolution for smoothness; it does not create capacity. And buffering ahead means there is always a delay between what is happening and what you see, which is fine for a film but a genuine problem for anything live.

That buffer-versus-latency tension is the core trade-off. A bigger playout buffer survives nastier dips but pushes you further behind real time; a small buffer keeps you near-live but stalls the moment your link hiccups. For a sports broadcast you want low latency so you do not hear the neighbours cheer a goal before you see it, so live streaming uses short segments and small buffers — and pays for it with more frequent quality changes. For a movie nobody minds being twenty seconds behind 'real' time, so the player can hoard a fat buffer and ride out almost anything. Different goals, same machinery tuned differently.

There are two final honesties. Because each segment is a separate fetch over TCP, a slow start at the beginning of every chunk and a player that mis-estimates throughput can fight each other — and several ABR players sharing one home link can behave unfairly, each grabbing or yielding bandwidth in ways that make all their estimates wobble. This is one reason streaming increasingly runs over HTTP/3 and QUIC: QUIC runs over UDP, removes TCP's head-of-line blocking, and its faster connection setup suits the steady drip of short segment requests. And conversational, real-time media — a video call where two people talk live — is a different beast entirely: it cannot tolerate a buffer of seconds, so it favors low delay over reliability and is built on different foundations, not on the buffer-and-adapt model that makes stored video so smooth.