streaming stored media

When you press play on a recorded movie or song, you are not downloading the whole thing first and then watching it — that would mean a long wait. Instead the file already exists on a server, and your player starts showing the beginning while the rest keeps arriving in the background, like sipping from a glass that someone is still filling. This is streaming stored media: pre-recorded audio or video delivered piece by piece and played as it arrives. The key advantage over a live event is that the content is already complete, so the player can pull ahead and stockpile a cushion.

Mechanically, the client starts playback after a short startup delay during which it fills a playout buffer with the first few seconds of media. From then on it plays from the buffer at a constant rate while continuing to fetch ahead. Because the whole file exists, the player can request future chunks as fast as the network allows, building a reserve of several seconds or more. If the network briefly slows or a packet is delayed, playback drains the cushion instead of stalling; the viewer never notices. Modern systems also switch quality on the fly — fetching a lower-bitrate version when bandwidth drops — but the underlying idea is the buffered, fetch-ahead stream.

Why it matters: this is the most forgiving class of media traffic, which is exactly why so much of the Internet's bytes are streaming video. Because it can buffer generously, it tolerates a lot of delay and jitter and even survives over plain TCP, which retransmits lost packets. Two honest boundaries: this entry is about the timing model of stored streaming, not about the delivery infrastructure (content delivery networks) or the adaptive-bitrate logic, which live in the web-and-CDN side of networking; and 'streaming' does not mean nothing is stored — it means it is played progressively rather than downloaded all at once.