Buffering
Buffering is the player downloading video ahead of the playback position and holding it in memory, so short dips in the network do not interrupt the picture. That stored stretch of video is the buffer. When people say a video is buffering, they usually mean a rebuffer, or stall: the buffer has run empty, playback stops and a spinner appears until enough video arrives to resume. Stalls happen when segments arrive more slowly than they are played, for network, CDN, encoding or player reasons.
How does video buffering work?
The player sets a target for how many seconds of video it wants downloaded ahead of the playhead. The open-source hls.js player, for example, aims for 30 seconds by default before it pauses segment downloads. While the buffer is below target, the player keeps fetching segments. Once it reaches target, it waits and tops up as video is played.
The buffer level also drives quality. A full buffer tells the ABR logic it can afford a higher rendition. A buffer that is shrinking tells it to step down before the buffer runs dry.
Live streams work with much smaller buffers. A live player can only buffer what the encoder has already produced, and holding more seconds means sitting further behind real time. That is why low-latency live streams are more sensitive to network dips than on-demand video.
What causes buffering?
A stall always has the same shape: video is played out more quickly than it arrives. The reasons vary, and many of them sit on the publisher's side, where they can be fixed. A device that decodes too slowly is a different problem: it drops frames rather than emptying the buffer.
- No lower rendition. A single progressive MP4 cannot step down, so a weak signal becomes a stall.
- A ladder whose lowest rung is still too high for mobile networks.
- A CDN edge that is slow or poorly connected to one internet provider, or frequent cache misses back to a distant origin.
- A player that starts or climbs too aggressively, choosing a rendition the connection cannot sustain.
- An unstable live encoder upload, which starves every viewer at once.
- Local conditions: busy home Wi-Fi, a congested cell or other downloads on the same line.
Buffering vs. startup delay
Not every wait for video is a stall. Before the first frame, the player has to fill an initial buffer, and that wait is counted as startup time. A rebuffer is a stall after playback has already begun. Waits after a seek are usually tracked separately again, as seek latency.
The split matters because the causes and fixes differ. Slow startup points at the page, the player script, the manifest chain, DRM license requests or a heavy first segment. Rebuffering points at sustained throughput, the ladder and the CDN. A viewer who leaves before the first frame never reaches a stall at all, so that case is counted as an exit before video start.
Mixing these into one buffering number hides the cause. A live stream with fast startup but frequent stalls needs a different fix from an on-demand library that plays smoothly once it starts but takes too long to begin.
How is buffering measured?
Four metrics describe rebuffering per view. Buffer count is how many stalls happened. Buffer fill, also called rebuffer duration, is the total time spent stalled. Buffer ratio is that time divided by watch time, which makes short and long views comparable. Buffer frequency is the count divided by watch time, which separates one long stall from many short ones.
Averages hide most of the story. Stalls cluster: on one mobile carrier, one device model, one CDN in one region, or one live event. Break the metrics down by ASN, CDN, country and device, and look at the share of views with any stall, not only the mean ratio.
These metrics must come from the player. Server logs can show that segments were sent, but only the player knows whether its buffer ran dry and for how long.
How do you reduce buffering?
Start with the ladder. Make sure there is a rendition low enough for the weakest network your audience uses, and that rungs are close enough together for the player to step down gently. Per-title encoding helps by keeping simple content small.
Then look at delivery. Serve segments from edges close to viewers, with good connections to the internet providers they use, and route around a CDN that slows down in a region. Keep cache hit ratios high so segments do not wait on the origin.
Tune the player last. A sensible buffer target, a conservative starting rendition and fast step-down on a draining buffer prevent many stalls. For live, balance latency against buffer depth. Finally, measure the result by network and device, because the fix that works on fiber may do nothing for viewers on a crowded mobile cell.
How does FastPix handle buffering?
FastPix works on buffering where it starts: what the player can choose from, how segments reach it, and what the player keeps ready. Every upload gets a per-title ladder in H.264 and HEVC (H.265) as standard, with AV1 available on request, delivered as HLS and DASH, so the player has lower renditions to step down to before its buffer runs dry. Segments come from 300+ points of presence, with routing chosen per viewer and per-region failover if one CDN degrades.
FastPix Player manages the buffer across four platform-native SDKs: web, Android built on Media3, iOS built on AVPlayer, and Flutter. On Android, fast start begins playback after 500 ms of buffered media instead of Media3's stock 1000 ms, with a 250 ms feed profile. Disk caching plays re-watches and scroll-backs from local storage, and preloading, pre-caching and pre-rendering fill the next entry before the viewer reaches it (preload and cache).
Video Data shows where buffering still happens. Every view records buffer count, buffer fill, buffer ratio and buffer frequency. The stability score is built from buffer count and buffer ratio and carries 0.395 of the QoE score. QoE breaks down by country, region, CDN and ASN, and alerts can go to PagerDuty, Slack or Opsgenie.
Video Data runs on 17 player surfaces and is free for the first 100,000 plays a month, every month. Delivery is billed per minute watched and storage per rendition-minute, with Standard encoding free up to 4K.
By the numbers
- The open source hls.js player's default maxBufferLength is 30 seconds, the buffer length it tries to reach before pausing segment downloads. (hls.js API documentation (GitHub))
