Adaptive Bitrate Streaming Explained (ABR) With Examples

Your train goes into a tunnel and the video on your phone gets blurry for a few seconds, then sharpens again as the signal returns. It did not stop to buffer. That is adaptive bitrate streaming (ABR) doing its job. It is the single most important idea in modern video delivery, and it is the reason streaming works on everything from fibre connections to crowded mobile networks.

This guide explains how ABR works, what a bitrate ladder is, how players decide when to switch, and how to design a ladder for your own content.

The problem ABR solves

Early internet video offered a choice between a “low quality” and a “high quality” file. Pick high on a slow connection and the video would stall every few seconds. Pick low on a fast connection and it looked terrible. Worse, connection speed changes constantly, especially on mobile and Wi-Fi.

ABR fixes this by preparing the same video at several quality levels and letting the player switch between them mid-playback, without a pause, based on what the connection can handle at that moment.

How it works

ABR has three ingredients.

1. Multiple renditions

The video is encoded several times at different resolutions and bitrates. Each version is a rendition, and the full set is the bitrate ladder. For example:

2. Aligned segments

Each rendition is split into short segments, usually 2 to 6 seconds, and the segment boundaries line up exactly across all renditions. Every segment starts with a keyframe. That alignment is what lets the player finish segment 12 from the 1080p rendition and continue with segment 13 from 720p without a visible glitch.

3. A manifest and a smart player

A manifest (HLS .m3u8 or DASH .mpd) lists all renditions and their bitrates. The player reads it and decides, segment by segment, which rendition to download next.

How players decide when to switch

The logic that picks the next rendition is the ABR algorithm. There are two main families, and most real players combine them.

Throughput-based

The player measures how fast recent segments downloaded. If the last few segments came in at an average of 8 Mbps, it picks the highest rendition safely below that, often with a safety margin of 70 to 85 percent. So with 8 Mbps measured, it might choose the 5 Mbps rendition.

This reacts quickly to changes but can be fooled by short bursts or dips in speed.

Buffer-based

The player looks at how many seconds of video are sitting in its buffer. If the buffer is full and stable, it can afford to pick higher quality. If the buffer is draining, it switches down before it runs dry. A well-known academic approach, BOLA, formalises this and is used in dash.js.

This avoids stalls well but can be slow to climb to high quality at startup.

Hybrid

Most production players, including hls.js, Shaka Player, dash.js, ExoPlayer and AVPlayer, use a mix: throughput estimates to climb quickly at startup and buffer levels to stay stable during playback. Some large services use machine-learning models trained on millions of sessions.

You can watch an ABR algorithm at work with our HLS player: leave quality on Auto and read the log as it switches between levels.

Startup: speed vs quality

When a video starts, the player has no idea how fast the connection is. It has to choose:

• Start low for a fast start, then climb. This is the most common approach and explains the “blurry first few seconds” effect.
• Start high for immediate quality, at the risk of a slower start or an early stall.
• Start in the middle as a compromise.

Some services store a viewer’s last measured bandwidth and use it to start at a sensible level. Shorter segments at the start of a video also help, because the player gets a bandwidth sample sooner.

Designing a bitrate ladder

A good ladder gives every viewer the best quality their connection can sustain, without wasting bits.

Rules of thumb

• Top rendition: match the source resolution, or your maximum target. For most web content that is 1080p. Use 4K only if your audience and content benefit from it.
• Bottom rendition: low enough for poor mobile connections, usually 240p or 360p at 300 to 500 kbps.
• Spacing: each step roughly 1.5 to 2 times the bitrate of the one below. Steps that are too close waste storage. Steps that are too far apart cause noticeable jumps in quality.
• Resolution vs bitrate: at low bitrates, a smaller resolution looks better than a large, starved one. That is why the ladder lowers both together.
• Keep the aspect ratio of the source for every rung. Use our aspect ratio calculator to get even-numbered sizes.
• Frame rate: keep the source frame rate for upper rungs; you can halve 50 or 60 fps content on the lowest rungs.

Example ladders

H.264, 30 fps, general content

HEVC or AV1 can cut these by roughly 30 to 50 percent for similar quality, on devices that support them. Our best encoding settings for streaming guide lists complete settings for several scenarios.

Per-title and content-aware encoding

A fixed ladder treats a cartoon, a talking-head lecture and a football match the same way. They are not the same. A simple animation might look perfect at 1080p and 1.5 Mbps, while a fast sports scene needs 6 Mbps or more.

Per-title encoding, popularised by Netflix around 2015, analyses each video and builds a custom ladder for it. Per-scene or per-shot encoding goes further and adjusts bitrate inside the video. Many cloud encoders offer this as a “content-aware” or “per-title” option. The savings are often 20 to 50 percent in bandwidth for easy content, with no visible loss.

If you encode yourself, a practical middle ground is to use capped CRF encoding: set a quality target with CRF and a maximum bitrate for each rung. Easy content comes out smaller automatically, while hard content is capped at your ladder’s bitrate. The details are in what is video bitrate.

Audio in ABR

Audio is usually delivered as a separate track at one or two bitrates, often 96 to 128 kbps AAC stereo, and optionally a higher-bitrate surround track. Because audio is small compared with video, most players do not switch audio quality often. Keep audio in separate tracks when packaging CMAF, so each video rendition does not carry duplicate audio.

Common ABR problems

• Constant quality switching (“oscillation”): usually rungs too close together, or an algorithm that reacts to short bursts. Space rungs further apart or tune the player’s switching thresholds.
• Stuck on low quality: the manifest’s BANDWIDTH values may be much higher than the real bitrate, making the player too cautious. Make sure peak bandwidth values are accurate.
• Visible jumps at switches: keyframes not aligned across renditions, or different colour settings between encodes.
• Stalls despite ABR: segments too long, lowest rung too high for the audience, or the player’s buffer target too small.
• High CDN costs: the top rung may be higher than viewers can see. Many phone viewers never benefit from a 1080p 8 Mbps rendition.

ABR and your bandwidth bill

ABR does not just protect viewers; it shapes your costs. Your CDN bill depends on the average bitrate actually delivered, not your top rung. If most of your audience watches on phones, they may settle at 720p. Our streaming bandwidth calculator helps you estimate peak and total delivery, and video streaming bandwidth requirements explains the numbers behind it.

Measuring ABR quality: the metrics that matter

To know whether your ladder and player are working, track quality-of-experience metrics from real viewers:

• Video start time: seconds from pressing play to the first frame. Under 2 seconds is good.
• Rebuffering ratio: time spent stalled divided by total watch time. Well under 1 percent is a common goal.
• Average bitrate delivered: tells you what quality most viewers actually see.
• Rendition switches per minute: a very high number suggests oscillation.
• Playback failures: sessions that never started or ended in an error.

Player analytics services, and several open-source options, collect these automatically. Review them after changing a ladder to confirm the change helped.

A worked example: one viewer, one commute

Picture a viewer who starts a 20-minute lesson on home Wi-Fi, walks out of the door at minute six and finishes on a bus.

At home the player measures 40 Mbps and climbs to the 1080p rung within a few segments. Nothing interesting happens for six minutes. Then the phone drops off Wi-Fi and joins 4G. The first segment on mobile data takes three times longer than expected, the buffer shrinks from 30 seconds to 22, and the player steps down to 720p. On the bus the signal dips hard between stops. The buffer falls below ten seconds, so the player drops two rungs to 360p for about a minute, then climbs back to 720p once throughput steadies.

The viewer never sees a spinner. They notice, at most, that the picture went soft for a moment near a busy junction. That is ABR doing its job, and it only works because the ladder had a rung low enough for a weak signal. If the lowest rendition had been 720p, the same trip would have produced two or three stalls.

You can recreate this at your desk. Open the HLS player, start a stream, then use your browser’s network throttling to switch between “Fast 4G” and “Slow 3G” and watch the log report each switch.

Summary

Adaptive bitrate streaming prepares a video at several quality levels, splits them into aligned segments and lets the player choose the best one for each moment. Players use throughput and buffer measurements to decide when to switch. A well-designed ladder, with sensible spacing, a low enough bottom rung and content-aware bitrates, gives viewers smooth playback and keeps delivery costs under control.