How to Build an Adaptive Bitrate Ladder
Choosing the resolution and bitrate rungs for an ABR encode, spacing, the mobile bottom rung, and why per-title encoding beats a fixed ladder.
An adaptive bitrate ladder is the set of quality levels you encode a video into. The player picks one rung at a time based on measured throughput, stepping up when the connection allows and down when it does not. Get the ladder right and playback is smooth and sharp. Get it wrong and you either burn storage and bandwidth on rungs nobody selects, or you leave viewers stuck on a soft picture when their connection could carry more.
What a Rung Consists Of
Each rung is a complete encode of the source, defined by at minimum a resolution, a bitrate target, and a codec profile. Everything else (framerate, keyframe interval, audio pairing) is usually held constant across the ladder for reasons covered below.
A conventional H.264 ladder for general-purpose content looks roughly like this:
Two things about that table are worth pulling out. There are two 1080p rungs at different bitrates, and the bottom rung is at a resolution that looks almost unusable on paper. Both are deliberate.
The Spacing Rule
The gap between adjacent rungs is the single most important parameter, and the usual guidance is that each rung should be roughly 1.5 to 2 times the bitrate of the one below it.
Space them too tightly and the player oscillates. If two rungs differ by 10 percent, normal throughput noise will push the player back and forth between them constantly, and every switch is a visible change in sharpness. Viewers notice flickering quality far more than they notice a consistently lower quality.
Space them too widely and adaptation becomes coarse. A player dropping from 6 Mbps straight to 1.4 Mbps because there is nothing in between produces a dramatic quality collapse when a modest step down would have sufficed.
The ratio also has a practical consequence: a ladder covering 200 Kbps to 6.5 Mbps at a 1.7× ratio needs about seven rungs. That is why most ladders land between six and eight. Fewer and the range does not cover real-world conditions; more and you are paying to encode and store levels the adaptation logic will rarely settle on.
Why the Bottom Rung Is So Low
The 200 Kbps rung is not there for people who want to watch at 200 Kbps. It is there for two specific moments.
The first is startup. A player has no throughput measurement before it has downloaded anything, so most implementations begin at or near the bottom rung to get a picture on screen quickly, then step up once they have data. A low, fast-loading bottom rung directly reduces time-to-first-frame, which is one of the metrics that most strongly correlates with viewers abandoning a stream.
The second is genuine congestion. When a connection collapses, the choice is a soft picture or a spinner. A soft picture is always the better outcome, and the bottom rung exists to make that choice available.
Why Two Rungs at the Same Resolution
The 1080p pair looks redundant but is not. Encoding 1080p at 4.5 Mbps and at 6.5 Mbps produces meaningfully different quality on demanding content, fast motion, film grain, high-detail scenes. A viewer whose connection supports 7 Mbps should get the better encode.
You could instead make the top rung 1440p or 4K, but that only helps if the display can show it. For a 1080p television, a higher-bitrate 1080p encode delivers more visible improvement than a downscaled 4K one, and it decodes with less power draw.
Constraints to Hold Constant
Several parameters must match across every rung, or switching breaks:
Keyframe interval and alignment. Every rung must place an IDR frame at the same timestamps, and segment boundaries must land on those keyframes. This is what makes a switch seamless, the player can begin decoding the next rung's segment without reference to anything it has already discarded. Misaligned keyframes produce visible glitches or outright decode failures at switch points. Set an explicit fixed GOP length and disable scene-cut keyframe insertion.
Segment duration. All rungs use the same segment length so their timelines are interchangeable. Four to six seconds is standard; shorter segments adapt faster but add request overhead and, in the case of enumerated HLS playlists, manifest bloat.
Codec profile compatibility. A rung using a profile or level the device cannot decode is a rung that device must never select. Declaring accurate CODECS attributes in the manifest lets players filter correctly before they attempt playback.
Audio. Usually encoded once and referenced by every video rung rather than duplicated per rung. Audio bitrates are small enough that adapting them rarely pays for the complexity.
Per-Title Encoding
A fixed ladder applies the same bitrates to every asset, which is straightforwardly wasteful. A static animated short and a handheld action sequence have wildly different compression characteristics. Encoding both at 4.5 Mbps for 1080p means the animation is allocated far more bits than it needs while the action footage is starved.
Per-title encoding runs a complexity analysis on each asset and derives a ladder for it specifically. In practice this means test-encoding at several bitrates, measuring quality with a perceptual metric, and finding the point where additional bitrate stops producing meaningful improvement.
VMAF is the metric most commonly used for this, a model trained on human quality ratings that outputs a 0-100 score. The usual approach is to plot quality against bitrate for a given resolution, identify where the curve flattens, and place the rung there. Simpler metrics like PSNR and SSIM are cheaper to compute but correlate less well with what viewers actually perceive.
The savings are substantial. Reported reductions of 20 to 30 percent in average bitrate at equivalent perceived quality are typical across a mixed catalogue. The cost is the analysis pass, which for a large library is a real compute expense, though far smaller than the ongoing CDN bill it reduces.
There is also a resolution dimension. At a low enough bitrate, encoding at 720p and letting the player upscale looks better than encoding at 1080p with visible compression artifacts. The crossover point varies by content, and per-title analysis can find it rather than guessing.
Validating a Ladder
Once deployed, the ladder should be checked against real playback data rather than assumed correct:
• Rung selection distribution. If a rung is selected for less than a percent or two of playback time, it is not earning its storage. If the top rung is never reached, it may be set too high, or your CDN may be the bottleneck rather than viewer connections.
• Switch frequency. Frequent switching between two adjacent rungs indicates they are spaced too closely.
• Rebuffer rate by rung. Rebuffering while on the bottom rung means the bottom rung is still too high for some portion of your audience.
• Startup time. If time-to-first-frame is poor, the bottom rung or the initial segment size is the first place to look.
These interact with player-side behaviour too, buffer targets, the throughput estimator, and how aggressively the player is willing to step up. A ladder is only half of the adaptation system; the codec choice underneath it and the delivery path in front of it shape the outcome just as much.