How to Build a Video Bitrate Ladder: A Practical Guide

A video bitrate ladder is the set of resolution and bitrate pairs, or rungs, that you encode for adaptive streaming. To build a good one, run trial encodes of each title, plot quality against bitrate, and pick rungs from the best curve (the convex hull) instead of a fixed table.

The ABR article covered how a player picks a rung, and the VMAF article covered how to score a single encode. This post covers where the rungs come from in the first place.

TL;DR:

• Before 2015, most services used one fixed ladder for every title. Apple's reference ladder from that era had 9 rungs from 235 Kbps to 4,500 Kbps.
• Netflix's 2015 per-title encoding ran 30 to 100 trial encodes per title and picked rungs from the convex hull, with reported savings of 15-20% bandwidth at the same quality.
• Per-shot encoding (2018) applies the same idea scene by scene for another 10-15%, at 6 to 32 times the encoding cost of a fixed ladder.
• Every rung balances two failure modes: too few bits for the resolution causes blocking and ringing, while too much downscaling loses detail.
• AIOZ Stream documents 8 rungs from 240p to 8K with a maximum bitrate for each, and its 8K rung needs H.265 because H.264 stops at 4K.

Updated Oct 28, 2026: shorter sentences, a step-by-step path to your own ladder, a labelled chart of AIOZ Stream's ladder, and a quality request from the docs.

What is a fixed bitrate ladder?

For most of the early history of HLS and DASH, encoding meant picking one ladder and applying it to the whole catalog. Apple's reference ladder from that period is a clean example. It had 9 rungs from 235 Kbps up to 4,500 Kbps, and the same pairs applied to an animated sitcom with flat colors and to a handheld action scene full of motion.

A fixed ladder is simple to build and easy to reason about. It also wastes bits in both directions at once. Simple content gets more bits than it needs to look clean. Complex content gets starved, because it hits the same ceiling as everything else in your catalog.

What is per-title encoding?

Netflix's 2015 per-title work replaced the one-size ladder with a ladder computed for each title. The method is brute force by design. You encode the same source at 30 to 100 resolution and bitrate combinations and score every trial with a perceptual metric such as VMAF. Then you plot bitrate against quality for all of them.

The useful points sit on the outer edge of that plot, the convex hull. For each of those points, no other trial reaches equal or better quality at a lower bitrate. Picking rungs from the hull tailors the ladder to the title, so a low-motion talking-head video ends up with a lower top rung than a fast sports clip.

The hull works because, at a fixed resolution, quality rises with bitrate only up to a point. Past that point, extra bits buy little, and the better move is to switch up a resolution. A fixed ladder can't see that plateau, because it never runs the trial encodes that reveal where it sits for your title. Reported results put the savings at roughly 15-20% bandwidth for the same perceived quality. The cost is 2 to 4 times the encoder compute of a fixed ladder.

Per-shot encoding: going one level deeper

Netflix's 2018 follow-up, sometimes called the Dynamic Optimizer, applies the same convex-hull logic to individual shots instead of whole titles. A film mixes dialogue scenes, static wide shots and fast action, and each compresses differently. Per-title encoding still treats them as one unit, because it optimizes across the whole runtime.

Per-shot encoding detects scene cuts and runs the trial-and-hull process on each shot. It then solves for one consistent set of rungs across all shots and joins them into a single stream per rendition. The reported payoff is another 10-15% bandwidth savings on top of per-title. The cost climbs steeply, to somewhere between 6 and 32 times the compute of a fixed ladder. That math only works for titles with enough viewers to pay back the encoding bill, which is why per-shot usually stays on a catalog's most-watched titles and major live events.

The resolution-bitrate tradeoff each rung has to respect

You can't pick bitrates freely, because each resolution has a floor below which the picture breaks down. Push too few bits into too many pixels and the encoder can't represent the frame. You see blocking, ringing around edges and banding in gradients.

Go the other way and downscale to protect quality at a low bitrate, and the picture loses detail and can pick up aliasing instead. Codec choice moves the balance point. A more efficient codec can hold a higher resolution further down the ladder before it hits that wall. That is why modern ladders often use a newer codec for the upper rungs instead of one codec for the whole ladder.

How do you build 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 rarely makes sense at moderate catalog sizes. A practical path for you looks like this:

• Start from a proven reference ladder, such as AIOZ Stream's 8-rung table below or Apple's classic 9-rung one.
• Group your catalog by content type, for example talks and screen recordings versus sports and action.
• Run one fast probe encode per title and score it with VMAF, then nudge the top-rung bitrate up or down from the result.
• Keep the lower rungs fixed, since viewers on weak connections need a dependable floor more than a perfect curve.
• Check your playback analytics after launch and adjust the rung spacing if players switch rungs too often.

The probe-encode step captures a share of per-title's benefit without its full compute cost. It is a reasonable default for a catalog that doesn't have Netflix's scale to justify the brute-force version.

How AIOZ Stream handles it

AIOZ Stream's Media Video API documents the ladder directly, with a maximum bitrate for each rung: 240p (426x240) up to 700 Kbps, 360p (640x360) up to 1.2 Mbps, 480p (854x480) up to 2 Mbps, and 720p (1280x720) up to 4 Mbps. The upper rungs are 1080p (1920x1080) up to 6 Mbps, 1440p (2560x1440) up to 12 Mbps, 2160p/4K (3840x2160) up to 30 Mbps, and 4320p/8K (7680x4320) up to 60 Mbps.

The codec limits make the tradeoff above concrete. Only H.264 and H.265 are supported, and the docs give H.264's maximum resolution as 4K and H.265's as 8K. So your 4320p rung needs H.265; it isn't reachable with H.264 at all. The docs also note that on Apple platforms, HLS plays H.265 only from fMP4/CMAF segments, while H.264 works in both MPEG-TS and fMP4.

You define your own rungs in the qualities array when you create the video. Each entry sets a resolution, a format, a container, and a video bitrate under that rung's maximum. Here is the multi-quality example from the docs, sent to POST https://api.aiozstream.network/api/media/create:

{
  "title": "My Video",
  "type": "video",
  "qualities": [
    {
      "resolution": "1080p",
      "type": "hls",
      "container_type": "mpegts",
      "video_config": {
        "codec": "h264",
        "bitrate": 5000000,
        "index": 0
      },
      "audio_config": {
        "codec": "aac",
        "bitrate": 192000,
        "channels": "2",
        "sample_rate": 48000,
        "language": "en",
        "index": 0
      }
    },
    {
      "resolution": "720p",
      "type": "hls",
      "container_type": "mpegts",
      "video_config": {
        "codec": "h264",
        "bitrate": 3000000,
        "index": 0
      },
      "audio_config": {
        "codec": "aac",
        "bitrate": 128000,
        "channels": "2",
        "sample_rate": 44100,
        "language": "en",
        "index": 0
      }
    }
  ]
}

Note that this example sets 1080p at 5 Mbps and 720p at 3 Mbps, below the 6 and 4 Mbps ceilings, which leaves you room to tune each rung. The docs describe a fixed table of rungs with per-rung ceilings, not an automatic per-title or per-shot optimizer, so the probe-encode tuning above is yours to run. The field reference is in the AIOZ Stream Media Video API docs.

Frequently Asked Questions

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

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

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

Why can't a ladder use the highest resolution at every bitrate?
Because too little bitrate for a resolution causes visible artifacts such as blocking and ringing. Each rung has to balance resolution against the bits available to encode it cleanly.

Does AIOZ Stream support per-title or per-shot encoding?
Its docs describe a fixed 8-rung table with codec-based resolution limits and per-rung bitrate ceilings that you set within, not a per-title or per-shot optimization process.

Why does AIOZ Stream's 8K rung require H.265?
Because the docs give H.264's maximum resolution as 4K. Anything above that, including the 4320p rung, needs H.265.

Related Reading

• Best OBS Encoder Settings for 1080p and 720p Streaming (the live-ingest side of bitrate)
• 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 Works: how this ladder fits into the process-once-play-many model that defines VOD
• How Video Segmentation and M3U8 Manifests Work: how this ladder's rungs 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 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 consumes the ladder this article builds
• HLS vs MPEG-DASH: How the AIOZ Stream Player 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 and 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 and quality plateau mechanic and reported 20% savings figure cited above
• AIOZ Stream Media Video API documentation: the 8-rung bitrate ladder, H.264/H.265 resolution limits, the Apple HEVC note and the multi-quality example cited above (checked Oct 28, 2026)