Adaptive bitrate streaming and bitrate ladders explained

Adaptive bitrate (ABR) streaming encodes a video at several quality levels and lets the player switch between them every few seconds as the viewer's connection changes. The set of quality levels is called the bitrate ladder. Get the ladder and the player's switching rules right, and a lecture starts quickly and rarely stops to buffer, even on a phone whose 4G swings between 2 Mbps and 300 kbps during a bus ride.

What adaptive bitrate means

Without ABR, a player downloads one file at one quality. If the network can't sustain that bitrate, playback stalls; if the network is fast, the viewer gets less quality than they could have had. ABR solves both by preparing several renditions of the video and cutting each into short segments that line up in time across renditions.

The player starts by downloading a manifest that lists the renditions. In HLS this is the multivariant playlist, and each entry declares a peak bitrate (BANDWIDTH), an average bitrate (AVERAGE-BANDWIDTH), a resolution and codecs, as defined in RFC 8216:

#EXTM3U
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=190000,AVERAGE-BANDWIDTH=150000,RESOLUTION=426x240,FRAME-RATE=30,CODECS="avc1.64001e,mp4a.40.2"
240p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=620000,AVERAGE-BANDWIDTH=446000,RESOLUTION=640x360,FRAME-RATE=30,CODECS="avc1.64001e,mp4a.40.2"
360p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1900000,AVERAGE-BANDWIDTH=1296000,RESOLUTION=1280x720,FRAME-RATE=30,CODECS="avc1.64001f,mp4a.40.2"
720p/index.m3u8

The declared bitrates include audio. Before every segment request, the player decides which rendition to fetch next. Because each segment starts with a keyframe at the same timestamp in every rendition, it can switch at any segment boundary without a visible glitch. DASH works the same way with an XML manifest; our comparison of HLS vs DASH covers the differences.

Renditions and the ladder

Each rung of the ladder is a resolution and bitrate pair, sometimes with its own codec or frame rate. Designing a ladder comes down to four decisions:

• The bottom rung decides who can watch at all. For iOS devices, Apple's HLS authoring specification requires playlists delivered over cellular networks to include a variant whose peak bitrate, audio included, is 192 kbps or less.
  
  
• The top rung should stop where extra bits stop showing. A high-bitrate 1080p rung is mostly wasted on a six-inch phone showing a slide.
  
  
• The spacing sets how big each jump looks. Rungs very close together cost storage and encoding for little benefit. Rungs far apart make switches obvious and leave students stuck on a low rung when their connection could handle more.
  
  
• Segment and keyframe timing must match across rungs. Apple recommends six-second segments with a keyframe every two seconds.
  
  

Apple's specification also publishes an example H.264 ladder for general content. Lectures are different: a teacher, a board and a voice involve far less motion than sport or film, so they usually need fewer bits at each resolution. The right-hand column below is an illustrative starting point for lecture content, to test rather than copy:

How players choose a rendition

ABR algorithms fall into three broad families:

Real players show these ideas clearly. hls.js estimates bandwidth with exponentially weighted moving averages over recent downloads, and assumes 500 kbps before it has any samples. Its documented defaults only switch up to a rung when 0.7 times the estimate exceeds that rung's bitrate, but stay on or drop to a rung when 0.95 times the estimate exceeds it. dash.js enables both a throughput rule and BOLA, a buffer-based algorithm, by default, using the throughput rule at first and handing over to BOLA once the buffer reaches 12 seconds. Players add further rules on top: dropping down when the buffer runs critically low, avoiding rungs that recently caused dropped frames, and optionally capping quality to the size of the video element.

Per-title and content-aware encoding

A fixed ladder assumes every video needs the same bits. It doesn't: slides with a voice-over compress far better than a teacher pacing in front of a crowded whiteboard, filmed on a handheld phone. Per-title encoding gives each video its own ladder. The usual method is:

1. Encode short samples of the video at several resolutions and bitrates.
   
   
2. Score each sample with an objective quality metric such as VMAF, Netflix's open-source perceptual quality metric.
   
   
3. At each bitrate, keep the resolution that scores best, and drop rungs that add bits without adding visible quality.
   
   
4. Store the chosen ladder with the video, so a later re-encode reproduces it.
   
   

A lighter option is capped constant-quality encoding: ask the encoder for a quality level (a CRF value in x264) with a maximum bitrate for each rung. Easy content comes out smaller automatically, while the cap keeps every rung within its bandwidth budget. Either way, check legibility by eye. No metric knows whether a student can read the formula on the board at 360p, and that is the test that matters. Our guide to transcoding pipelines shows where these encodes run.

Ladders for lecture video on patchy 4G

Many students watch on budget Android phones over mobile data that changes minute to minute. A few settings make a large difference:

• Start low on mobile. For iOS, Apple suggests starting cellular viewers on its 730 kbps rung and Wi-Fi viewers on its 2,000 kbps rung. A fast first frame on a modest rung beats a sharp picture that takes eight seconds to appear.
  
  
• Cap quality to the screen. hls.js can limit rungs to the size of the video element; it's off by default. There's no point downloading 1080p into a thumbnail-sized player.
  
  
• Keep the natural frame rate. Lectures don't need 60 fps; encode at the source's rate, and spend the bits on sharper text.
  
  
• Offer something below 360p. A capped 240p rung, or an audio-only rendition for the worst moments, keeps a student listening through a weak patch instead of staring at a spinner.
  
  

A worked example

Here is what hls.js's two default factors mean for the illustrative lecture ladder of 110, 350, 600, 1,200 and 2,000 kbps. For simplicity it compares against video bitrates and ignores audio, and real players add buffer checks on top, so treat it as the skeleton of the decision:

Two lessons follow. First, headroom: a student needs roughly 2.9 Mbps of measured throughput before the player climbs to a 2,000 kbps rung, so a top rung set too high is rarely reached on mobile. Second, the gap between the factors is deliberate: a student already on 360p rides out a dip to 400 kbps, but one on 240p won't climb back until throughput passes about 500 kbps. That prevents flapping between rungs, and it's why a well-placed 360p rung matters so much for students on weak connections.

Measuring quality of experience

Server metrics can't tell you whether a lecture played well. Measure from the player:

• Startup time: from pressing play to the first frame.
  
  
• Rebuffering ratio: the share of watch time spent stalled, plus how often stalls happen.
  
  
• Delivered quality: average bitrate or resolution, and how often the rendition changes.
  
  
• Failures: playback errors per session, by type.
  
  

Break every metric down by device, operating system, network type, city and internet provider; national averages hide the district where one ISP is struggling. Common Media Client Data (CMCD, published as CTA-5004) lets players attach values such as buffer length, measured throughput and a session ID to each segment request, so CDN logs show what the player was experiencing. These measures also make good service level indicators; see our guide to monitoring vs observability. For the wider picture of CDNs, live classes and exam-day load, read our guide to scaling a video learning platform.

Key takeaways

• ABR streams a ladder of renditions in short, aligned segments, and the player picks a rung before each segment.
  
  
• The bottom rung decides who can watch on a weak connection; the top rung should stop where quality stops showing on real screens.
  
  
• Throughput-based, buffer-based and hybrid algorithms trade speed of reaction against stability; know your player's defaults.
  
  
• Lectures usually need fewer bits than general content, but test legibility of board work and slides at every rung.
  
  
• Judge the ladder by startup time, rebuffering and delivered quality, measured from the player.
  
  

Frequently asked questions

What is adaptive bitrate streaming?

Adaptive bitrate streaming is a way of delivering video in which the same content is encoded at several quality levels and split into short segments. The player measures the viewer's connection and buffer, and fetches each segment at the highest quality it can play without stalling. HLS and MPEG-DASH are the two main formats that work this way.

What is adaptive bitrate?

Adaptive bitrate is the behaviour behind a player's "Auto" quality setting: instead of locking to one resolution, the player moves up or down the available renditions as network conditions change. If a student picks 720p manually, adaptation stops and the video may buffer on a weak connection. Leaving it on Auto usually gives the best balance of picture quality and smooth playback.

What is variable bitrate?

Variable bitrate (VBR) is an encoding choice: the encoder spends more bits on complex scenes and fewer on simple ones, instead of a constant rate throughout. It happens inside each rendition, while adaptive bitrate switches between renditions during playback. Streaming usually uses capped VBR, so peaks stay within what a rung promises; Apple suggests peaks no higher than twice the average for on-demand video.

What is a bitrate ladder?

A bitrate ladder is the list of renditions a video is encoded into, each a resolution and bitrate pair, such as 240p at 110 kbps up to 1080p at 2,000 kbps. The player climbs or descends the ladder as conditions change. A good ladder has a low enough bottom rung for weak networks, sensible spacing between rungs, and no rung that costs bits without visible improvement.