STANDARDwalkthrough
Adaptive Bitrate Streaming (ABR)
A viewer on a train enters a tunnel and bandwidth drops from 10 Mbps to 500 Kbps. With a fixed-resolution stream, the player stalls and buffers for 15 to 30 seconds until bandwidth recovers.
We chose Adaptive Bitrate Streaming (ABR) using HLS (HTTP Live Streaming) over DASH because HLS has native support on iOS and Safari, covering roughly 50% of mobile viewers without extra player code. DASH is codec-agnostic and technically more flexible, but requires a JavaScript player on every Apple device.
“The constraint: we cannot predict network conditions ahead of time, so we must adapt in real time.”
Trade-off: we accept vendor lock-in to Apple's HLS ecosystem in exchange for broader device compatibility out of the box. The mechanism works as follows: we encode each video at multiple quality levels called a bitrate ladder, and the client player measures available bandwidth every 2 to 4 seconds, then requests the next chunk at the highest quality it can sustain without rebuffering.
Netflix uses 8 to 10 bitrate ladder rungs per title, from 235 kbps for constrained mobile to 16 Mbps for 4K HDR. YouTube reports that ABR reduces buffering events by over 90% compared to fixed-bitrate delivery.
Implication: this 90% reduction means ABR is not an optimization but a requirement for any system serving viewers across variable networks. The storage trade-off is significant: encoding resolutions means storing copies of every chunk, so a 10-rung ladder multiplies origin storage by 10x.
What if the interviewer asks: why not let the server decide the quality instead of the client? Because the server cannot observe last-mile bandwidth.
Only the client knows its actual download speed, buffer fill level, and device capabilities. Server-side ABR would require constant bandwidth probing, adding latency and complexity without better accuracy.
Related concepts