Two different kinds of waiting
People often use “buffering” for any wait, but there are two distinct problems.
- Startup delay is the time between pressing play and the first picture appearing.
- Rebuffering (a stall) is when playback stops mid-video because the player has run out of data to show.
They have overlapping causes but different fixes, and services measure them separately.
What the buffer is
A player does not display video the instant it arrives. It downloads ahead of the current position and keeps a reserve of upcoming video and audio in memory. This buffer smooths out irregularities: if one segment takes longer than expected to arrive, the reserve covers the gap and the viewer notices nothing.
A stall happens when playback consumes video faster than the player can fetch it for long enough to empty that reserve. Seeing the spinner means the safety margin has been used up.
Common buffering causes
Most stalls come down to one of a few categories. Often more than one applies at once.
The viewer’s connection is too slow or unstable. If the available throughput is lower than the video’s bitrate over a sustained period, the buffer drains. A short-lived dip is more likely to be absorbed than a long one. Wi-fi problems are a frequent culprit: a weak signal, interference, or many devices competing for the same connection can cause erratic speeds even when the home internet plan itself is adequate. Mobile connections add changes in signal strength as the user moves; the possible benefits of 5G networks depend on coverage and conditions rather than being automatic.
Congestion along the route. Performance can degrade somewhere between the viewer and the server, for example at busy times or on a congested link. This is outside the viewer’s control.
Server or delivery issues. A distant or overloaded server delays responses. Large services reduce this using content delivery networks, but a cache miss, in which the nearby server must fetch the file from the origin, can still add delay.
The video is too demanding for the device. An older phone or computer may struggle to decode a high-resolution stream, especially with newer codecs lacking hardware support. This can look like stuttering rather than waiting, and is a separate cause from network trouble. The effect of codec choice appears in the discussion of the AV1 codec and the HEVC codec.
Settings and limits. A player locked to a high quality, a data-saver restriction, a VPN adding overhead, or background downloads can all create trouble that looks like a service fault.
Why startup takes time
Before the first frame, the player must complete several steps in sequence:
- find the server and set up a connection, including encrypted web connections;
- download the manifest listing the available versions;
- choose a starting version;
- download enough initial segments to begin;
- for protected content, request a license from a server and set up decryption, as explained in DRM protection;
- decode the first frames and begin rendering.
Each step adds a round trip across the network, so distance and connection quality matter. Pages that load additional elements, such as ads, can add further waiting. Around the world, viewers with high-latency connections may notice startup delay more than throughput limits.
What services do about it
Reducing waiting is a major engineering priority, since viewers who wait too long often give up. Several techniques are common, though specifics vary between services.
- Start low, then climb. Beginning with a modest-quality version means the first segments are smaller and arrive sooner. The player then moves up as conditions allow, the behaviour described in adaptive bitrate.
- Shorter first segments or efficient packaging. Making early segments quick to fetch helps playback begin sooner.
- Caching close to viewers. Content delivery networks keep popular titles near the audience and shorten each round trip.
- Prefetching and preloading. Apps may fetch the beginning of a likely next video, such as the next episode or the next item in a feed, before the viewer chooses it. This relates to how a video series is designed for continuous viewing, though it has costs in data use.
- Well-chosen encoding ladders. If the lowest versions are genuinely light, weak connections have something they can carry. The design of the set of versions is covered in encoding ladders.
- Connection reuse and modern transport. Reusing connections and using newer network protocols can remove steps from the start of a request, though the benefit depends on support along the path.
- Monitoring. Services track startup time and stall rates, and review them through video analytics, to find which devices, regions or networks have trouble.
What viewers and publishers can try
For viewers, simple measures sometimes help: moving closer to the router or using a wired connection, pausing other downloads, lowering the quality setting, restarting the app, or trying another network. If many services stall at the same time, the cause is likely the local network rather than any one service.
For publishers, sensible export settings keep files from being heavier than needed, and a platform with a strong delivery network handles much of the rest. If hosting video on one’s own site, using a hosting service built for streaming, rather than serving a single large file, usually behaves better when many people watch together; the practical side of this is touched on in video embedding.
A realistic expectation
Some waiting is unavoidable, since physics and network distance impose limits, and buffering depends partly on factors that neither viewer nor service controls. The goal is to make delays short and rare, rather than to eliminate them.