Rebuffering Ratio: The Real Cost of a Stall

Why this matters

A stall is the failure a viewer feels most and forgives least. You can ship a flawless encode with a high VMAF score and still lose the audience to a spinner, because no picture metric can see a freeze that happens during delivery. This article is for the streaming engineer, player developer, QoE analyst, and product owner who own retention and need to measure stalls correctly — to compute the rebuffering ratio the way the standards define it, read it without fooling themselves, and understand why an adaptive player cannot simply raise the bitrate to make a stream look better. It is the deep dive behind the rebuffering line in the streaming QoE framing article: that article names the metric; this one takes it apart.

What a stall actually is

Start with the mechanism, because the metric only makes sense once you can see what it counts. A streaming player does not download the whole video before it plays. It fills a small holding tank — the buffer, a few seconds to a few tens of seconds of video decoded and waiting ahead of the playhead — and plays out of that tank while refilling it from the network. As long as the tank refills at least as fast as it drains, playback is smooth and the viewer never knows the buffer exists.

A rebuffering event — also called a stall, a freeze, or a buffer underrun — is what happens when the tank runs dry. The stream is arriving slower than the video wants to play, the buffer empties to zero, the playhead has nothing left to show, and playback halts until enough new video arrives to resume (RFC 9317, IETF, 2022). That is the spinner. The standards body that defines streaming experience metrics calls this the moment the buffer "starves," and the request-level flag a player raises for it is literally named buffer starvation (CTA-5004, CMCD, 2020).

One distinction decides whether your numbers mean anything: rebuffering is not startup. The wait before the very first frame — while the player fills the buffer for the first time — is startup time (or video start time), a separate metric with its own article on startup time and time-to-first-frame. Rebuffering counts only the stalls that happen after playback has begun. Folding startup into your rebuffering ratio double-counts the opening wait and inflates the number; the two are measured and acted on separately. A user-initiated seek that triggers a brief refill is usually excluded too, for the same reason: it is not the delivery failing, it is the viewer jumping.

Figure 1. A stall, defined. Startup (the first buffer fill) is excluded; the rebuffering ratio counts only the freezes during playback, divided by the time spent stalled plus playing.

The rebuffering ratio, computed

The rebuffering ratio is the fraction of a viewing session the viewer spent stalled instead of watching. Write it as a formula, then plug in numbers.

rebuffering ratio = total rebuffering time / (total rebuffering time + total play time)

The denominator is stall time plus play time — the time the session was actually engaged in video, not wall-clock time that might include pauses or the startup wait. This is the definition the recommended-practice standard settles on so that two analytics stacks reporting "rebuffering ratio" mean the same thing (CTA-2066, CTA, 2020). Express the result as a percentage.

Work a concrete session. A viewer watches a 45-minute episode — 2,700 seconds of content. The player takes 3 seconds to show the first frame; that is startup, and it does not count here. During playback the stream stalls three times: once for 5 seconds, once for 7 seconds, and once for 15 seconds.

total rebuffering time = 5 + 7 + 15 = 27 seconds
total play time        = 2,700 seconds
rebuffering ratio      = 27 / (27 + 2,700)
                       = 27 / 2,727
                       = 0.0099  =  0.99%

Just under 1% of the session was a spinner. That sounds small. The rest of this article is about why it is not.

One number is not enough: frequency and duration

The ratio answers "what share of the session was stalled?" — and on its own it can hide the thing that annoys viewers most. Two sessions can carry the same rebuffering ratio and feel completely different.

Take our 27 seconds of stall. Session A spends it as a single 27-second freeze. Session B spends it as nine separate 3-second freezes scattered through the episode. Both report a 0.99% rebuffering ratio. But Session B interrupted the viewer nine times; Session A interrupted them once. Research and practice agree that multiple interruptions are worse than one of the same total length — a stutter of frequent short stalls can be more frustrating than a single longer wait (Mux, 2023). The ratio alone cannot tell them apart.

So measure rebuffering as three numbers, not one:

• Rebuffering ratio — the share of session time spent stalled (the 0.99% above). The headline number.
• Rebuffering frequency — how often stalls happen, as events per hour of viewing (Session A: ~1.3/hr; Session B: ~12/hr). This catches the stutter the ratio hides.
• Rebuffering duration — how long each stall lasts, usually reported as a median and a 95th percentile so one catastrophic freeze does not vanish into an average.

A fourth refinement matters when you want to grade your own delivery rather than the viewer's whole environment: the connection-induced rebuffering ratio (CIRR) counts only the stalls caused by the network and delivery, excluding those a viewer caused by seeking (Conviva, 2026). CIRR is the number to watch when you are asking "is our pipeline stalling?" rather than "did this viewer ever see a spinner?"

The table puts the four numbers side by side, with the blind spot each one carries — because in this section a metric is only as honest as the place it lies.

Number	What it measures	Unit	Where it lies / blind spot
Rebuffering ratio	Share of engaged time spent stalled	% of (stall + play) time	Hides whether one long stall or many short ones caused it; a low ratio can still hold one painful freeze
Rebuffering frequency	How often stalls happen	stalls per hour	Says nothing about how long each lasts; a stutter of tiny stalls reads "fine" by duration
Rebuffering duration	How long each stall lasts	seconds (median, p95)	A median hides a rare catastrophic freeze — report the 95th percentile too
CIRR	Stalls caused by the network only	% (seeks excluded)	Excludes viewer-caused stalls, so it understates the total spinner the viewer actually saw

Table 1. Read the rebuffering ratio with its companions. No single number is the experience; each hides something the others reveal.

Figure 2. Same ratio, different pain. Both sessions stalled for 27 seconds total and report 0.99%, but nine short freezes interrupt the viewer far more often than one. Pair the ratio with frequency.

How the number is measured

You never compute a rebuffering ratio from the video file — there is nothing in the pixels about a stall. It comes from player events. The player knows when it started waiting for data and when it resumed, and it timestamps each transition: playing, stalled (waiting), resumed, ended. Summing the stalled intervals gives the numerator; summing the playing intervals gives the play time in the denominator. Where those events come from across players and analytics vendors — the instrumentation, the event taxonomy, the analytics stack — is the subject of player-side quality metrics.

Two standards keep the numbers comparable. CTA-2066 defines the streaming QoE events and metrics — including the rebuffering ratio and how to compute it — so a "rebuffering ratio" on one dashboard matches a "rebuffering ratio" on another (CTA-2066, 2020). CTA-5004 (Common Media Client Data, CMCD) standardizes the fields a player attaches to each media request — among them buffer length and a buffer-starvation flag — so the data that signals an imminent or actual stall reaches any backend in the same shape (CTA-5004, 2020; the CMCDv2 revision CTA-5004-A followed in 2026). If you take one operational rule from this section, take this: use the standard definitions, or two teams will optimize against quietly different numbers.

For session-level experience scoring, the parametric model ITU-T P.1203 folds stalling — the number of stalls, their lengths, and where they fall in the timeline — into a single 1-to-5 mean opinion score for an adaptive-streaming session, alongside the picture and the bitrate switches (ITU-T Rec. P.1203, 2017). That is the bridge from a raw rebuffering ratio to a predicted experience score, and it is one reason stalls are weighted so heavily: their position and count, not just their total length, move the model.

Why a stall costs you the viewer

The reason rebuffering earns its place at the top of every QoE dashboard is not intuition. It is measured, and in the strongest study it is causal.

The broad correlational finding came first: across short video-on-demand, long video-on-demand, and live content, the buffering ratio has the largest impact on engagement of any quality metric — more than bitrate, more than startup (Dobrian et al., SIGCOMM 2011). The effect is strongest for live content, where there is no catching up to a live edge after a stall: for a 90-minute live event, a 1% increase in buffering ratio cut viewing by more than three minutes (Dobrian et al., 2011).

The causal evidence came next, from a quasi-experimental study of a large Akamai dataset (Krishnan & Sitaraman, IMC 2012). Its rebuffering finding is the one to commit to memory: a viewer who experienced a rebuffer delay equal to just 1% of the video's length watched about 5% less of it than a comparable viewer with no stall. Because the study isolated cause from mere correlation, that 5% is not "stalls and low watch time go together" — it is "the stall made the viewer leave sooner."

Run it through our session. The 45-minute episode stalled for 27 seconds, a 0.99% rebuffering ratio — almost exactly the 1% the study describes. So the model predicts roughly 5% less watch time:

watch time lost ≈ 5% × 45 minutes
                ≈ 2.25 minutes per affected viewer

Two and a quarter minutes, erased by 27 seconds of spinner. Now scale it. Suppose 500,000 sessions that day hit that same ~1% ratio:

lost viewing = 500,000 sessions × 2.25 minutes
             = 1,125,000 viewer-minutes
             ≈ 18,750 hours of watching lost in one day

Those hours are ad impressions that never rendered, a live audience that drifted off before the finish, and subscribers one bad night closer to churning. The arithmetic is a linear reading of the study's slope, not a universal law — your audience, content, and catalogue differ — but the order of magnitude is the point. A stall of under half a minute, multiplied across an audience, is measured in tens of thousands of lost hours.

Figure 3. The cost of a stall, after Krishnan & Sitaraman (2012). A rebuffer delay of 1% of a video's length cost ~5% of watch time; the worked example's 0.99% ratio lands almost exactly there.

The trade-off an adaptive player makes every second

If stalls are so costly, why not simply hold a huge buffer and never run dry? Because the buffer is filled at whatever bitrate the player chooses, and bitrate is the very thing the viewer also wants high. This is the balancing act at the heart of adaptive bitrate (ABR) streaming: the player picks a quality level for each few-second segment, and that choice is a constant bet between picture and smoothness.

Pick a bitrate higher than the network can sustain and the buffer drains faster than it fills — eventually to zero, and the stream stalls. Pick a bitrate lower than the network could carry and playback is rock-steady but softer than it needed to be, wasting available bandwidth on a worse picture. The player is choosing, segment by segment, between the risk of a stall and the cost of a soft image. The standards literature frames the decision exactly this way: the bitrate choice optimizes for the highest achievable quality or the lowest chance of a rebuffering event (RFC 9317, 2022).

The buffer is the shock absorber that makes the bet survivable. A deeper buffer tolerates more network variation before it starves, which is why players fill a cushion before allowing an upswitch. That is also why the two main families of ABR logic split on what they watch: throughput-based algorithms estimate the network speed and pick the quality it can carry, which works well at startup when the buffer is empty; buffer-based algorithms (the approach Netflix described in its buffer-based rate-adaptation work) read the buffer occupancy itself — upshift when the cushion is deep, downshift before it runs dry — and reduce stalls in steady state (Huang et al., SIGCOMM 2014). Many production players run throughput-based logic during startup and hand off to buffer-based logic once the cushion is built.

The measurement takeaway is what belongs in this section: the rebuffering ratio is not an isolated number you minimize in a vacuum. Drive it to zero by pinning the lowest bitrate and you have traded a stall problem for a soft-picture problem; chase the highest bitrate and you invite the stall back. The picture metrics from choosing the right metric and the delivery metrics here have to be read together — the synthesis in connecting objective picture metrics to QoE — because the player is trading one against the other in real time. How the algorithm makes that decision is the Video Streaming section's territory; this section owns how you measure the result.

Figure 4. The trade-off, drawn. A bitrate the network can sustain keeps the buffer full; an over-ambitious bitrate drains the buffer to zero, where playback stalls. The buffer is the shock absorber ABR manages.

Common mistakes when measuring rebuffering

The same metric that is so predictive is easy to misread. Five traps recur.

The first is reporting the ratio alone and missing the stutter. A calm 0.5% ratio made of a dozen tiny freezes is a worse experience than the number suggests — always pair the ratio with frequency, as Figure 2 shows. The second is folding startup into the ratio: the opening buffer fill is its own metric, and counting it as rebuffering inflates the number and blurs two different problems with two different fixes. The third is the global average that hides the cliff — a healthy fleet-wide ratio can conceal one CDN, device, or region stalling badly, which is why monitoring quality in production insists on segmenting before you trust an aggregate.

The fourth is treating a picture metric as if it saw stalls. A full-reference score like VMAF grades the encode against its source; it has no view of the session and is blind to every freeze — a beautiful VMAF can sit on top of a miserable rebuffering ratio. The fifth is confusing the freeze the viewer sees with the metric that counts it: the visible frozen frame is a streaming artifact, covered in streaming-specific artifacts; the rebuffering ratio is the QoE measurement of how much of that happened. Keep the artifact and the metric distinct, and cross-reference them.

Where Fora Soft fits in

Fora Soft has built video streaming, OTT, conferencing, e-learning, telemedicine, and surveillance products since 2005, and in every live or on-demand product the rebuffering ratio is one of the first numbers we put on the dashboard. We instrument stalls from player events using the standardized definitions (CTA-2066) and client data (CMCD), so the ratio, frequency, and duration mean the same thing across web, mobile, and TV clients — and so a regression shows up as a moved number, not a support ticket. For live products such as conferencing and live OTT, where there is no pristine reference to score and a stall cannot be recovered by catching up, that telemetry is the primary quality signal. The job is not a tidier chart; it is catching the CDN or device whose buffer is starving before the audience drifts away.

What to read next

• Streaming QoE: The Metrics That Predict Whether a Viewer Stays — the framing for all of Block 6.
• Startup Time and Time-to-First-Frame — the other half of the first impression.
• Connecting Objective Picture Metrics to Perceived QoE — reading picture and delivery metrics together.

Call to action

• Talk to a video engineer — book a 30-minute scoping call to talk through your rebuffering plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.

References

1. CTA-2066. "Streaming Quality of Experience Events, Properties and Metrics." Consumer Technology Association, 2020. Tier 1 (recommended-practice standard). Defines the streaming QoE events and metrics — including the rebuffering ratio and how it is computed — for consistent cross-vendor reporting. Basis for the rebuffering-ratio definition and denominator. https://shop.cta.tech/products/streaming-quality-of-experience-events-properties-and-metrics-cta-2066
2. CTA-5004. "Web Application Video Ecosystem — Common Media Client Data (CMCD)." Consumer Technology Association, 2020 (CMCDv2 / CTA-5004-A, 2026). Tier 1 (standard). The key-value vocabulary a player attaches to each media request, including buffer length and a buffer-starvation flag. Basis for the measurement-source and buffer-starvation points. https://cdn.cta.tech/cta/media/media/resources/standards/pdfs/cta-5004-final.pdf
3. Recommendation ITU-T P.1203. "Parametric bitstream-based quality assessment of progressive download and adaptive audiovisual streaming services over reliable transport." International Telecommunication Union, 2017. Tier 1 (official standard). Predicts a 1–5 MOS for an adaptive-streaming session, integrating the number, length, and position of stalls with the picture and bitrate switches. Basis for the stall-weighting and session-MOS points. https://www.itu.int/rec/T-REC-P.1203
4. RFC 9317. "Operational Considerations for Streaming Media." J. Holland, A. Begen, S. Dawkins. IETF, 2022. Tier 3 (standards-body operational guidance). Describes the buffer model, buffer underrun as the cause of a playback stall, and the bitrate-versus-rebuffering optimization an ABR client makes. Basis for the stall-mechanism and ABR-trade-off framing. https://www.rfc-editor.org/rfc/rfc9317.html
5. S. S. Krishnan, R. K. Sitaraman. "Video Stream Quality Impacts Viewer Behavior: Inferring Causality Using Quasi-Experimental Designs." ACM Internet Measurement Conference (IMC), 2012. Tier 5 (peer-reviewed causal study, large Akamai dataset). A rebuffer delay equal to 1% of a video's length cut watch time by about 5%; a failed visit cut the chance of returning within a week by 2.32%. Basis for the watch-time-cost arithmetic. https://people.cs.umass.edu/~ramesh/Site/HOME_files/imc208-krishnan.pdf
6. F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. Joseph, A. Ganjam, J. Zhan, H. Zhang. "Understanding the Impact of Video Quality on User Engagement." ACM SIGCOMM, 2011. Tier 5 (peer-reviewed, large Conviva dataset). The buffering ratio has the largest impact on engagement of any quality metric across all content types; for a 90-minute live event a 1% increase in buffering ratio cut viewing by more than three minutes. Basis for the "rebuffering hurts most" and live-sensitivity claims. https://www.cs.cmu.edu/~hzhang/papers/sigcomm2011_QualityEngagement.pdf
7. T.-Y. Huang, R. Johari, N. McKeown, M. Trunnell, M. Watson. "A Buffer-Based Approach to Rate Adaptation: Evidence from a Large Video Streaming Service." ACM SIGCOMM, 2014. Tier 5 (peer-reviewed, Netflix deployment). Selecting bitrate from buffer occupancy reduces rebuffering in steady state versus pure throughput estimation. Basis for the buffer-based-versus-throughput-based ABR point. https://web.stanford.edu/class/cs244/papers/buffer-based-2014.pdf
8. Conviva. "What Is CIRR? — Connection Induced Rebuffering Ratio." Conviva, accessed 2026-06-25. Tier 4 (vendor, credible deployer at scale). Defines CIRR as the rebuffering attributable to the connection/delivery, excluding viewer-initiated seeks. Basis for the CIRR refinement. https://www.conviva.ai/glossary/what-is-connection-induced-rebuffering-ratio-cirr/
9. Mux. "Rebuffering Metrics to Help You Troubleshoot Your Video Pipeline." Mux, 2023. Tier 4 (vendor engineering, credible deployer). Distinguishes rebuffering percentage, frequency, and duration, and argues multiple short stalls can be worse than one long one of equal total length. Basis for the frequency-versus-ratio point. https://www.mux.com/blog/recover-from-rebuffering-mux-metrics-explained
10. Recommendation ITU-R BT.500-15. "Methodologies for the subjective assessment of the quality of television pictures." International Telecommunication Union, 2023. Tier 1 (official standard). The subjective ground truth every objective and QoE model is ultimately validated against; when a model and a careful viewing disagree, the viewing wins. Basis for the measurement-honest framing. https://www.itu.int/rec/R-REC-BT.500