What Is Adaptive Bitrate (ABR) Streaming and How It Works

Knowing that a player switches quality when a connection gets shaky is the easy part, every modern streaming service does that. What's actually interesting, and mostly invisible to viewers, is the decision logic underneath: what data the player is watching, and which of several genuinely different algorithm families it uses to decide when to step down, when to step back up, and how far to jump.

TL;DR:

• Adaptive bitrate (ABR) streaming works because a manifest file lists multiple pre-encoded quality renditions of the same video, and the player picks one per segment based on current conditions, not a fixed choice made once at the start.
• Three real algorithm families exist: throughput-based (estimates download speed from recent segments), buffer-based (watches how full the playback buffer is), and hybrid approaches like BOLA, which uses a mathematical optimization technique to balance both.
• BOLA, published by researchers at UMass Amherst and presented at IEEE INFOCOM 2016, is used in production today inside dash.js, one of the most widely deployed open-source DASH players.
• AIOZ Stream publishes a real, specific 8-rung bitrate ladder (240p through 4320p/8K) in its API docs, but doesn't disclose which switching algorithm family its player actually uses.
• Switching frequency isn't just a technical detail, it's literally one of the six terms in AIOZ Stream's own documented QoE formula, under "stability."

The building blocks: ladder and manifest

ABR starts with encoding the same video multiple times at different bitrates and resolutions, a bitrate ladder, then listing every rung in a manifest file the player reads before choosing what to request. In HLS, that's a Master Playlist using the EXT-X-STREAM-INF tag, one line per variant stream, each carrying a BANDWIDTH attribute. Per the IETF's own HLS specification, that value "MUST be the largest sum of peak segment bit rates that is produced by any playable combination of Renditions," and an inaccurate value risks playback stalls or a client skipping a variant it should have been able to use. The player reads the whole ladder up front, then requests one segment at a time from whichever rung its current decision logic points to, not a single fixed choice locked in at the start of playback. AIOZ Stream's own API docs publish a real ladder for exactly this purpose: 240p at roughly 700 Kbps, 360p at 1.2 Mbps, 480p at 2 Mbps, 720p at 4 Mbps, 1080p at 6 Mbps, 1440p at 12 Mbps, 2160p (4K) at 30 Mbps, and 4320p (8K) at 60 Mbps, eight rungs spanning a wide enough range that a viewer's connection has somewhere reasonable to land almost regardless of how good or bad it is.

How a player actually decides

Three real families of decision logic exist, and they don't all use the same signal. The earliest, throughput-based adaptation, estimates the viewer's available bandwidth from how fast recent segments downloaded and picks the highest rung that estimate can sustain. It's simple and it works reasonably well on a stable connection, but it reacts badly to short bursts of congestion, since a single slow segment can trigger a downshift the underlying connection didn't really need. Buffer-based adaptation (BBA) watches something different: how much already-downloaded video is sitting in the player's buffer, waiting to play. A simple version uses two thresholds, requesting the lowest rung when the buffer runs low and the highest once it's comfortably full, with some interpolation in between. A more sophisticated hybrid, BOLA (Buffer Occupancy based Lyapunov Algorithm), published by Kevin Spiteri, Rahul Urgaonkar, and Ramesh Sitaraman at IEEE INFOCOM 2016, uses a mathematical technique called Lyapunov optimization to pick, segment by segment, whichever rung maximizes a combined score for quality and rebuffer risk rather than reacting to a single threshold. BOLA isn't just an academic exercise, it's shipped in dash.js, one of the most widely used open-source DASH reference players on the web today, which means a meaningful share of real DASH playback online is already running something more sophisticated than simple throughput estimation.

Pure throughput-based logic has a specific, well-known failure mode worth naming: bufferbloat. A congested WiFi router or a shared upstream link can queue packets for a second or more before delivering them, which makes a connection look slower than it actually is for exactly as long as that queue takes to drain, then suddenly fast again once it clears. An algorithm reacting purely to measured download speed sees that as a real bandwidth drop and downshifts, then sees the recovery and jumps back up, oscillating on a connection that never actually changed its true capacity. Buffer-based approaches are naturally more resistant to this specific problem, since a temporarily queued connection still delivers the data eventually, keeping the buffer topped up even while the instantaneous throughput reading looks bad.

Why more rungs isn't automatically better

It's tempting to assume a denser ladder, more rungs, smaller gaps between them, is strictly an improvement, and it isn't, for two concrete reasons. First, every extra rung is another full encode to store and another line in the manifest, real storage and transcoding cost for marginal quality gain once neighboring rungs are close enough that a viewer can't perceive the difference. Second, a denser ladder gives a throughput- or buffer-based algorithm more opportunities to oscillate, switching quality more often than the viewer's connection actually requires, which is its own quality problem separate from resolution. The practical target, covered in more depth in the VMAF article, is picking the lowest bitrate at each rung that still clears a perceptual quality floor, rather than adding rungs for their own sake. AIOZ's own 8-rung ladder, roughly doubling bitrate at each step from 700 Kbps to 60 Mbps, reflects that kind of spacing rather than a dense, closely-packed one.

Tracing a concrete case through that ladder makes the mechanism less abstract. A viewer starts a video on a connection that comfortably supports 1080p, sitting on the 6 Mbps rung. Their connection degrades to roughly 2.5 Mbps, well under what 1080p needs; a buffer-based algorithm watching its playback buffer drain faster than it refills drops straight to the 480p rung at 2 Mbps rather than 720p at 4 Mbps, since 720p would keep draining the buffer at the new, lower throughput. If the connection recovers to 5 Mbps a few segments later, the algorithm doesn't necessarily jump straight back to 1080p, most real implementations climb one rung at a time as the buffer refills, landing on 720p first and only returning to 1080p once buffer occupancy confirms the higher rung is actually sustainable. That asymmetry, cautious on the way down, still cautious on the way back up rather than optimistic, is a deliberate design choice most ABR algorithms share, favoring a brief period of lower quality over a downshift-then-immediately-upshift oscillation that would itself hurt the stability metric described below.

What "stability" actually means

Switching itself has a cost, and AIOZ Stream's own documentation treats it as a first-class metric rather than an afterthought. The platform's QoE composite model, covered in full in the QoE article, includes a stability term defined by "fewer switches and longer time on the highest sustainable rung," alongside startup time, rebuffer ratio, and perceived quality. That's a direct acknowledgment that an algorithm which technically avoids rebuffering by switching aggressively, chasing every small bandwidth fluctuation up and down the ladder, is still producing a worse experience than one that settles on a slightly conservative rung and holds it. This is exactly the tradeoff buffer-based and BOLA-style algorithms are built to manage better than naive throughput estimation, favoring a stable, sustainable rung over a jumpy one that's technically optimal moment to moment.

What AIOZ Stream does, and doesn't, say

AIOZ Stream's player documentation confirms ABR support directly, describing it as automatically adjusting quality "based on the viewer's internet connection" for "a buffer-free experience," and, as the HLS vs MPEG-DASH article covers, both HLS and MPEG-DASH manifest formats are supported. What isn't documented anywhere in AIOZ's public materials is which of the three algorithm families above the player actually runs, throughput-based, buffer-based, BOLA, or some proprietary blend. That's a reasonable thing for a product to keep unpublished, the exact tuning of an ABR algorithm is often treated as a competitive detail rather than public API surface, but it's worth being direct about rather than assuming a specific implementation. Someone building latency- or quality-sensitive playback logic on top of AIOZ Stream shouldn't assume BOLA-style buffer awareness specifically; the honest starting point is that ABR works and adapts to real conditions, confirmed directly, with the internal decision logic itself being AIOZ's own unpublished implementation detail.

Frequently Asked Questions

What is adaptive bitrate (ABR) streaming, in one sentence?
A method where a video is pre-encoded at multiple bitrates, listed in a manifest, and a player requests whichever rendition currently fits the viewer's connection and buffer state, adjusting as conditions change.

What's the difference between throughput-based and buffer-based ABR?
Throughput-based estimates the viewer's bandwidth from recent download speed and picks a rung it can sustain. Buffer-based watches how full the playback buffer is instead, which tends to react more smoothly to short-lived network blips.

Is BOLA actually used in real products, or just academic research?
Both. It's a peer-reviewed algorithm from IEEE INFOCOM 2016, and it's also shipped in dash.js, a widely deployed open-source DASH player used in real production playback today.

Does AIOZ Stream disclose which ABR algorithm its player uses?
No. AIOZ Stream's docs confirm ABR support and describe the experience it produces, but don't specify whether the underlying logic is throughput-based, buffer-based, BOLA, or a proprietary approach.

Is a denser bitrate ladder (more rungs) always better?
No. Extra rungs add real encoding and storage cost, and can cause more frequent quality switching without a perceptible quality benefit once neighboring rungs are close enough together.

Why does switching frequency matter if the video never rebuffers?
Frequent quality changes are their own source of a worse viewing experience, distinct from rebuffering. AIOZ Stream's own QoE model tracks this directly as a "stability" metric alongside rebuffer ratio and startup time.

Related Reading

• Stream Health Metrics Explained: how ABR's rendition-switching decisions directly drive the rebuffering and stability outcomes covered here
• What Is Video on Demand (VOD) and How It Actually Works: the closed-GOP requirement behind clean rendition switching, explained from the encoding side
• How Video Segmentation and M3U8 Manifests Actually Work: the manifest file structure this article's BANDWIDTH/EXT-X-STREAM-INF mechanics live inside
• How to Build a Video Bitrate Ladder: A Practical Guide: where the ladder this article's player switches between actually comes from
• What Is QoE in Video Streaming, and Why It Matters: the full composite formula this article's stability discussion is drawn from
• VMAF Explained: How Perceived Video Quality Is Measured: how a bitrate ladder's rungs actually get chosen in practice
• HLS vs MPEG-DASH: How the AIOZ Stream Player Actually Adapts: the manifest formats that carry the bitrate ladder this article describes

References

• RFC 8216: HTTP Live Streaming: the EXT-X-STREAM-INF and BANDWIDTH mechanics quoted above
• BOLA: Near-Optimal Bitrate Adaptation for Online Videos (Spiteri, Urgaonkar, Sitaraman, IEEE INFOCOM 2016): the algorithm and its dash.js adoption, cited above
• AIOZ Stream Media Video API documentation: the 8-rung bitrate ladder cited above