How to Build a Video Bitrate Ladder: A Practical Guide

The ABR article covered how a player picks a rung from an existing ladder, and the VMAF article covered how to score a single encode's quality. Neither answers the question that actually has to happen first: where do the rungs themselves come from. That's a real methodology with a documented history, not a fixed table everyone quietly agrees on.

TL;DR:

• Before 2015, the industry standard was one fixed ladder for every title. Apple's reference ladder from that era used 9 rungs from 235 Kbps to 4,500 Kbps, applied identically to a static talking-head video and a fast-motion action scene.
• Netflix's 2015 per-title encoding replaced that with brute-force trial encodes (30-100 per title), scored with a perceptual metric, plotted as a convex hull to find each title's actual optimal rungs, reported at 15-20% bandwidth savings for the same quality.
• Netflix's 2018 per-shot encoding pushed the same idea down to individual scenes, another 10-15% savings on top, at 6-32x the total encoding cost, only worth it for high-viewership content.
• Every rung has to balance two opposing problems: too little bitrate for a resolution causes blocking and ringing artifacts, too much downscaling loses real detail, and codec choice changes where that line falls.
• AIOZ Stream's own documented 8-rung ladder (240p to 4320p/8K) is a real, usable example of exactly this tradeoff: its 8K rung is only reachable with H.265, since H.264 is capped at 4K on the platform.

Where the fixed ladder came from

For most of HLS and DASH's early history, encoding meant picking one ladder and applying it to everything in the catalog. Apple's own reference ladder from that period is a clean example: 9 rungs running from 235 Kbps up to 4,500 Kbps, the same set of resolution and bitrate pairs whether the source was an animated sitcom with large flat color areas or a handheld action sequence full of motion and fine detail. That's simple to implement and easy to reason about, and it's also wasteful in both directions at once: simple content gets more bits than it needs to look clean, while complex content gets starved of bits it actually needs, capped at the same ceiling as everything else in the catalog.

Per-title encoding: trial and convex hull

Netflix's 2015 per-title encoding work replaced the one-size ladder with a unique ladder computed per title. The method is brute-force by design: encode the same source at somewhere between 30 and 100 different resolution and bitrate combinations, score every single trial encode with a perceptual quality metric (the same VMAF this series already covered), then plot bitrate against quality for all those trials. The useful points are the ones sitting on the outer edge of that plot, the convex hull, meaning no other trial reaches equal or better quality at a lower bitrate. Sampling rungs from that hull instead of from a fixed table is what actually tailors the ladder to the title, a simple, low-motion talking-head video ends up with a noticeably lower top-rung bitrate than a high-motion sports clip, because the hull for each one lands in a different place. The underlying pattern the hull is exploiting is straightforward once stated: quality keeps rising as bitrate increases at a fixed resolution, but only up to a point, past a certain bitrate for that resolution, more bits stop buying meaningfully better quality and the correct move is switching up a resolution tier instead of continuing to spend bits on the same one. A fixed ladder can't see that plateau because it never runs the trial encodes that would reveal where it sits for a specific title. Reported industry results put the savings at roughly 15-20% bandwidth for the same perceived quality across a catalog, at a real cost: running 30-100 trial encodes per title instead of one means 2-4 times the encoder compute of a fixed ladder.

Per-shot encoding: going one level deeper

Netflix's 2018 follow-up work, sometimes called the Dynamic Optimizer, applies the identical convex-hull logic to individual shots inside a title rather than to the whole title at once. A single film has a dialogue scene, a static wide shot, and a fast action sequence, each with genuinely different compression complexity, and per-title encoding still treats all three the same way because it optimizes across the whole runtime as one unit. Per-shot detection finds scene cuts, runs the trial-and-hull process on each segment independently, then solves for a globally consistent set of rungs across all the segments before concatenating them into one encoded stream per rendition. The reported payoff is another 10-15% bandwidth savings on top of per-title, but the cost scales far more steeply, somewhere in the range of 6-32 times a fixed ladder's total compute once every shot in a title gets its own trial-and-hull pass. That math only closes for content with enough viewership to amortize the extra encoding cost, which is why per-shot tends to stay reserved for a catalog's most-watched titles and major live events rather than applied catalog-wide.

The resolution-bitrate tradeoff each rung has to respect

A ladder isn't just picking bitrates freely, each rung's resolution has a real ceiling on how low its bitrate can go before the picture actively breaks down. Push too little bitrate into too high a resolution and the encoder can't represent the frame accurately, producing visible blocking, ringing around edges, and banding in gradients, spreading too few bits across too many pixels. Go the other direction, downscaling to a lower resolution to protect quality at a low bitrate, and the picture loses real detail and can pick up aliasing instead, a different failure mode rather than a fix. Codec choice shifts where that balance point sits: a more efficient codec can hold a higher resolution further down the ladder before hitting the artifact wall a less efficient codec would hit sooner, which is exactly why modern ladders lean on newer codecs specifically for the upper rungs rather than using one codec across the whole ladder.

A concrete ladder: AIOZ Stream's own

AIOZ Stream's API documentation publishes exactly this kind of ladder directly: 240p (426x240) at up to 700 Kbps, 360p (640x360) at up to 1.2 Mbps, 480p (854x480) at up to 2 Mbps, 720p (1280x720) at up to 4 Mbps, 1080p (1920x1080) at up to 6 Mbps, 1440p (2560x1440) at up to 12 Mbps, 2160p/4K (3840x2160) at up to 30 Mbps, and 4320p/8K (7680x4320) at up to 60 Mbps. The platform's own codec limits make the resolution-bitrate tradeoff above concrete rather than theoretical: AIOZ Stream documents H.264's maximum resolution as 4K and H.265's as 8K, which means the 4320p rung on this exact ladder isn't reachable with H.264 at all, encoding that top rung requires H.265 specifically, not a free choice between codecs the way the lower rungs might be. That's the general principle from the section above showing up as a real, documented platform constraint rather than an abstract rule.

Building your own ladder without Netflix's budget

Full per-title optimization assumes an encoding budget most teams don't have, running dozens of trial encodes per upload doesn't make sense at moderate catalog sizes. A more realistic starting point is adapting a proven reference ladder, AIOZ's own 8-rung table or Apple's classic 9-rung one, then adjusting a small number of rungs based on actual content type rather than re-deriving the whole structure per title. A lighter-weight middle ground, a single fast probe encode per title used to nudge the top-rung bitrate up or down rather than a full 30-100-trial search, captures a meaningful share of per-title's benefit without its full compute cost, and is a reasonable default for a catalog that doesn't have Netflix's per-title scale to justify the brute-force version.

Frequently Asked Questions

What's the difference between a fixed ladder and per-title encoding?
A fixed ladder uses the same resolution/bitrate pairs for every piece of content. Per-title encoding runs trial encodes specific to each title and picks that title's own optimal rungs from a convex-hull analysis, typically saving 15-20% bandwidth at equal quality.

How many trial encodes does per-title encoding actually require?
Reported industry practice runs somewhere between 30 and 100 trial encodes per title across different resolution and bitrate combinations before selecting the convex-hull points.

Is per-shot encoding worth it for a small catalog?
Usually not. It adds 10-15% more savings on top of per-title, but at 6-32 times the total encoding cost, which only pays back economically for high-viewership titles and live events.

Why can't a ladder just use the highest resolution at every bitrate?
Because too little bitrate for a given resolution causes visible compression artifacts, blocking and ringing specifically. Each rung has to balance resolution against the bitrate actually available to encode it cleanly.

Does AIOZ Stream support per-title or per-shot encoding?
AIOZ Stream's public documentation describes a fixed 8-rung ladder with codec-based resolution limits, not a per-title or per-shot optimization process; this article's ladder methodology is general practice, not a claim about AIOZ's own encoding pipeline internals.

Why does AIOZ Stream's 8K rung require H.265 specifically?
Because the platform documents H.264's maximum resolution as 4K. Anything above that, including the 4320p/8K rung, necessarily requires H.265 given that documented ceiling.

Related Reading

• Stream Health Metrics Explained: how ladder rung spacing affects how often stability-eroding rendition switches happen
• What Is AV1 and Should You Use It: the encoding-cost trade-off worth weighing before adding a codec to a bitrate ladder
• TVOD vs SVOD vs AVOD vs W2E: Monetization Models Compared: why an SSAI-inserted ad has to match this exact ladder to splice in cleanly
• What Is Video on Demand (VOD) and How It Actually Works: how this ladder fits into the process-once-play-many model that defines VOD
• How Video Segmentation and M3U8 Manifests Actually Work: how this ladder's rungs actually get listed and segmented in the manifest a player reads
• Podcast and Audio Hosting with the AIOZ Stream API: the same multi-quality-tier logic applied to audio instead of video
• Video Transcoding Basics: H.264 vs H.265 vs VP9: the codec history and licensing background behind this ladder's format choices
• How to Encode 4K/8K Video via the API: H.264 vs H.265: the actual API call that requests a specific rung on this ladder
• VMAF Explained: How Perceived Video Quality Is Measured: the perceptual metric per-title and per-shot encoding both use to build the convex hull
• What Is Adaptive Bitrate (ABR) Streaming and How It Works: how a player actually consumes the ladder this article builds
• HLS vs MPEG-DASH: How the AIOZ Stream Player Actually Adapts: the manifest formats that carry a bitrate ladder to the player

References

• Fora Soft: Building a Bitrate Ladder, Classic, Per-Title, Per-Shot: the fixed/per-title/per-shot methodology, savings figures, and Apple reference-ladder detail cited above
• Streaming Media: How Netflix Pioneered Per-Title Video Encoding Optimization: the convex-hull bitrate/quality plateau mechanic and reported 20% savings figure cited above
• AIOZ Stream Media Video API documentation: the 8-rung bitrate ladder and H.264/H.265 resolution limits cited above