Understanding Adaptive Bitrate (ABR) Streaming

Adaptive Bitrate (ABR) streaming is the reason video "just works" across a phone on spotty LTE and a TV on gigabit fiber. The same content is encoded at multiple quality levels, and the player continuously picks the highest one the network can sustain without stalling. Simple in principle — but the quality of the experience comes down to two things: the ladder you encode and the algorithm that climbs it.

The bitrate ladder

A bitrate ladder (or rendition ladder) is the set of encodes a player can switch between. A conventional H.264 VOD ladder might look like:

• 1920x1080 @ 5.0 Mbps — Wi-Fi / fiber.
• 1280x720 @ 2.4 Mbps — good mobile.
• 854x480 @ 1.2 Mbps — average mobile.
• 640x360 @ 700 Kbps — constrained connections.
• 416x234 @ 300 Kbps — the floor / startup rung.

Two design rules matter:

1. Adjacent rungs should be ~1.5–2x apart in bitrate. Too close and you waste storage and CDN cost for switches no one notices; too far apart and every switch is a jarring quality jump.
2. The bottom rung must be reliably deliverable. It is the rung that keeps a struggling connection playing instead of buffering, and it is usually what a player starts on before it has measured throughput.

How ABR algorithms pick a rendition

The player's adaptation logic generally blends two signals:

Throughput-based (rate-based)

Estimate available bandwidth from how fast recent segments downloaded, then pick the highest rendition whose bitrate fits under that estimate (with a safety margin). It reacts quickly but is noisy — a single slow segment can trigger an unnecessary downswitch, and throughput estimates lie on shared/variable networks.

Buffer-based

Drive decisions from how many seconds of media are buffered. BBA and Netflix-style approaches map buffer occupancy to a target rendition: low buffer → conservative rung, healthy buffer → climb. This is robust to throughput noise because the buffer is the integral of past throughput.

Hybrid

Production players (hls.js, dash.js, Shaka) use hybrids — e.g. MPC and the well-known BOLA algorithm — that combine a throughput estimate with buffer level and switching penalties to avoid oscillation. The goal is a single objective: maximize bitrate, minimize rebuffering, minimize switches.

You can watch these decisions happen live — startup time, switches, and throughput — in the play metrics tool.

Encoding the ladder well

A fixed ladder treats Planet Earth and a flat news desk identically, which is wrong: a low-complexity talking-head can look perfect at 1080p/1.5 Mbps, while a high-motion sports clip needs far more.

Per-title encoding

Instead of one ladder for all content, per-title encoding analyzes each asset's complexity and produces a custom ladder. The classic result: the "convex hull" of quality-vs-bitrate points, where each rung sits at the resolution that gives the best quality for its bitrate. This is what Netflix popularized and what most modern encoding pipelines now do.

CRF, capping, and VMAF

• Encode rungs at a quality target (CRF) with a maximum bitrate cap, so simple content gets smaller files at the same quality.
• Measure quality with VMAF rather than raw PSNR — VMAF correlates far better with what humans perceive, so you can trim bitrate until VMAF, not your eyes, tells you to stop.

Codecs move the whole curve

Switching from H.264 to HEVC, AV1, or VVC shifts the entire quality-bitrate curve down — roughly 30–50% bitrate savings at equal quality — letting you offer the same rungs more cheaply or add higher ones.

Putting it together

ABR quality is a system property. A beautifully tuned BOLA configuration cannot rescue a ladder with a 4 Mbps gap between rungs, and a perfectly built per-title ladder still buffers if the player's throughput estimator panics. Design the ladder for your content and audience, pick a hybrid adaptation algorithm, and measure the QoE you actually deliver — then iterate on whichever side the data points to.