skip to content

In an adaptive-bitrate video player, how is the bitrate rung for the next segment chosen?

level: middleimportance: must knowfreq 55%

answer

  1. two signals: network and buffer
  2. time the recent segment downloads
  3. a margin below the estimate
  4. buffer level maps to rung
  5. down fast, up slow

basics

~20 s

The player estimates available throughput from recent segment downloads, checks how many seconds are buffered, and picks the highest rung it can sustain with a safety margin, stepping down quickly when the buffer drains and up cautiously to avoid oscillation.

solid answer

~50 s

Before each segment, an **ABR algorithm** in the player picks a rung from the ladder the manifest lists. **Throughput-based** logic times recent segment downloads, smooths the samples (a harmonic or moving mean resists outliers), and chooses the highest bitrate below that estimate times a safety factor such as `0.8`. **Buffer-based** logic maps buffer level to a rung: little buffer means a low rung, a comfortable buffer permits a high one. Many production players combine both, leaning on throughput at startup, when the buffer is empty, and on the buffer in steady state. The guardrails matter as much as the core rule: step down fast when the buffer falls toward empty, step up only after sustained headroom (hysteresis), and cap the rung at what the screen can show or the device can decode without dropping frames. The goal is the best quality that avoids stalls, because viewers notice a stall far more than a slightly softer picture.

code

pseudocode · 11 lines
pseudocode
// rungs are indexed 0..n-1 in ascending bitrate
function chooseNextRung(current, samples, bufferSeconds, screen):
    estimate = harmonicMean(last(samples, 5))
    budget = estimate * 0.8                      // safety margin
    candidate = highestRungAtOrBelow(budget)     // 0 if none fits
    if bufferSeconds < 8:
        candidate = min(candidate, current - 1)  // protect against a stall
    else if candidate > current and bufferSeconds < 20:
        candidate = current                      // not enough cushion to climb
    candidate = min(candidate, rungForScreen(screen))
    return max(candidate, 0)

go deeper

for a junior

Recall that the player, not the server, picks the quality of each next segment, using how fast recent segments downloaded and how much video is already buffered.

for a middle

Explain throughput-based and buffer-based selection, why estimates are smoothed and discounted by a safety margin, and why stepping down is fast while stepping up waits for sustained headroom.

for a senior

Diagnose oscillation, stalls and stuck-low quality from player metrics, and know the traps: cache-inflated samples, idle-period underestimates, and caps for screen size and dropped frames.

for a principal

Treat the rule as a trade-off among quality, stall time and switch frequency, and decide how ladder design and per-title encoding shift that balance across the catalogue.

## The ladder the player chooses from An **adaptive bitrate (ABR) ladder** is the set of renditions a stream offers, each a **rung** with a bitrate and a resolution. The manifest lists them; the player decides, one segment at a time, which rung to fetch next. An illustrative ladder: | Rung | Resolution | Bitrate (illustrative) | |---|---|---| | 0 | 240p | 0.4 Mbit/s | | 1 | 360p | 0.8 Mbit/s | | 2 | 480p | 1.4 Mbit/s | | 3 | 720p | 2.8 Mbit/s | | 4 | 1080p | 5.0 Mbit/s | Adjacent rungs sit roughly 1.5 to 2 times apart, so each step is noticeable but not jarring. The decision logic lives in the **client**: in HLS and MPEG-DASH the server simply serves whatever segment is requested. ## Throughput-based selection The player records how long each segment took to download and its size, giving a throughput sample. Because individual samples are noisy, it smooths several of them — a **harmonic mean** is popular because one unusually fast download cannot inflate it much. It then multiplies by a **safety factor** below 1 and picks the highest rung that fits. Worked example: an estimate of 4 Mbit/s times 0.8 gives a 3.2 Mbit/s budget; the highest rung at or below that is rung 3 at 2.8 Mbit/s. Throughput logic reacts well at startup, when there is no buffer to reason about, but it is jumpy: a burst of competing traffic can swing the estimate and the chosen rung. ## Buffer-based selection **Buffer-based** logic treats the buffer — seconds of video downloaded but not yet played — as the main signal: 1. Below a **reservoir** level, always pick the lowest rung to rebuild the cushion. 2. Between the reservoir and an upper threshold, map buffer level to rung, rising as the buffer grows. 3. Above the upper threshold, allow the top rung the device supports. The buffer changes slowly and directly measures stall risk, so steady-state decisions are calmer. Its weakness is startup: an empty buffer would keep a fast connection on the lowest rung for many seconds. ## Hybrids and guardrails Many players blend the two signals and add rules that matter as much as the core formula: - **Fast down, slow up**: drop immediately when the buffer is falling toward empty; climb only after headroom has lasted several segments. - **Hysteresis**: require a margin before switching so the player does not flap between two rungs. - **Screen cap**: never fetch a rung whose resolution far exceeds the display. - **Decoder cap**: step down if the device is dropping frames, even when bandwidth is plentiful. - **Startup rung**: begin on a modest rung so the first frame appears quickly, then correct. ## Pitfalls that skew the decision | Pitfall | Effect | Mitigation | |---|---|---| | Segment served from a nearby or local cache | near-instant download inflates the estimate | ignore implausibly fast samples, weight by size | | Very small segments | round-trip time dominates, estimate reads low | measure over larger transfers or longer windows | | Idle periods while the buffer is full | the connection's sending rate may reset, next samples read low | combine with buffer level before stepping down | | Several players sharing one link | estimates chase each other and oscillate | smoothing, hysteresis, buffer-led decisions | ## What the player optimises ABR is a trade-off among three things viewers feel: **average quality**, **stall time**, and **switch frequency**. Stalls hurt most, frequent visible switches are next, and a slightly lower but steady picture is usually the least bad. Every rule above is a way of trading a little average quality for fewer stalls and fewer switches.

  • How would you choose the rungs of the ladder itself?
    Span from a bottom rung low enough to play on a poor mobile link to a top rung matched to the content and target screens, with adjacent rungs roughly 1.5 to 2 times apart. Pair each bitrate with a sensible resolution. Consider per-title ladders: simple animation reaches high quality at far lower bitrates than grainy action footage, so one fixed ladder wastes bits on one and starves the other.
  • Why do buffer-based players still use throughput estimates at startup?
    At startup the buffer is empty, so a pure buffer rule would keep the lowest rung for many seconds and climb only as the buffer fills, giving a long stretch of poor quality even on a fast link. A throughput estimate from the first segments lets the player jump to a suitable rung quickly, then hand steady-state decisions to the buffer, which is a calmer signal than noisy throughput samples.
  • What can make a player's throughput estimate misleading?
    Segments served from a nearby or local cache arrive almost instantly and inflate it; very small segments are dominated by round-trip time and deflate it; and when a full buffer pauses downloading, the connection may lose its ramped-up sending rate, so the next samples read low. Smoothing, discarding outliers and weighing the buffer level all reduce these errors.

A buffer-based player manages its buffer like a water tank: when the tank is nearly full it can open a thirstier tap, and when the level drops it turns the tap down well before the tank runs dry.

saying these in an interview costs you the question

  • The server measures each viewer's bandwidth and tells the player which rung to use.
  • The player should take the highest rung its last download speed allows, with no margin.
  • Frequent up-and-down switching is harmless because every segment is independent.
  • A single throughput sample is a reliable estimate for the next segment.
  • Bandwidth is the only thing that should limit the chosen rung.