What A Buffer Is Actually Holding
The buffer is the reserve of video a player has received but not yet displayed. Its size determines how much disruption playback can absorb before the viewer notices.
Delivery is uneven and playback is not
Video must be shown at a constant rate, one frame every frame interval, without exception. Networks deliver in bursts with gaps and retransmissions.
The buffer reconciles the two. Data arrives irregularly, accumulates, and is consumed at a steady rate from the other end.
Playback continues normally as long as the reserve is not exhausted. A stall is the moment it empties.
Filling the buffer is why playback does not start instantly
A player waits until it holds enough video to survive a likely interruption before it begins. Starting immediately would risk stalling within seconds.
That wait is the pause after pressing play. Shortening it improves responsiveness and increases the chance of an early stall.
Most services start with a small reserve and build it during playback, which is why the first moments are the most fragile.
Larger buffers cost delay
Everything in the buffer is video that has been received but not shown, so the viewer is behind the newest available content by the buffer's duration.
For recorded video that does not matter. For live content it is the entire problem, since the viewer's experience is delayed by whatever resilience the buffer provides.
Low-latency live streaming therefore runs with a small reserve and accepts more frequent stalls in exchange for being closer to real time.
Stalls have a characteristic pattern
When the buffer empties, playback freezes while the player waits for enough data to resume. It typically waits for more than the minimum to avoid stalling again immediately.
That is why a stall lasts longer than the interruption that caused it. The player is rebuilding a margin, not just recovering the missing frame.
Adaptive players usually step down in quality after a stall, since the measured conditions no longer support what they were requesting.
Seeking discards the buffer
Jumping to a new position invalidates everything held, because the buffered content belongs to the part being skipped.
The player must request segments at the new position and rebuild from nothing, which is why scrubbing produces the same delay as starting fresh.
Some players prefetch around likely seek targets to soften this, which costs data that may never be used. It is a trade between responsiveness and consumption.
