Streaming is delivery in small pieces
Streaming means a viewer can start watching before the whole file has arrived. Instead of downloading one large video and then opening it, the player requests the video in a steady series of small chunks, decodes each one as it arrives and discards it shortly after playing it. The same basic idea applies whether the video is a film stored on a server (on demand) or a broadcast that is still being captured (live).
What follows is the usual streaming pipeline, from the camera to the screen. Services differ in the details, but most of the stages below exist in some form in nearly all of them.
Stage 1: Capture and production
Everything starts with a camera, screen recording or other source producing raw or lightly compressed video, along with audio. Raw video is enormous: even a short clip at high resolution and frame rate can run to many gigabytes uncompressed. For that reason almost no one sends it over the internet in that form.
For on-demand video, the creator typically edits the footage and exports a master file, often at high quality. For live video, a camera feed goes to an encoder, either dedicated hardware or software on a computer, which starts compressing immediately.
Stage 2: Encoding and compression
Encoding turns the large source into a much smaller stream using a codec. Most of the saving comes from lossy compression, which discards detail that viewers are least likely to notice and describes the rest efficiently. Which codec is used matters: the H.264 codec remains very widely supported, while newer options such as the HEVC codec, the VP9 codec and the AV1 codec can often deliver similar quality at a lower video bitrate, but may need more processing power or have different device support and licensing arrangements.
The encoder also makes choices about video resolution and frame rates, which affect both quality and file size. Whether this work runs on a graphics chip or a general processor (hardware encoding versus software) changes speed and efficiency, and is a practical concern more for live streams than for uploads that can be processed at leisure.
Stage 3: Transcoding into several versions
A single encoded file rarely fits every viewer. Someone on a large television with a fast connection can handle a high-quality version; someone on a phone with a weak signal cannot. So services typically create several versions of the same video at different resolutions and bitrates. This set of versions is often called an encoding ladder, and creating it is called transcoding.
Doing this at scale takes real computing resources, which is one reason running a video service can be expensive. The effect of that cost on business decisions is discussed under streaming costs.
Stage 4: Packaging and manifests
Each version is then cut into short segments, commonly a few seconds long, and wrapped in a container format. A text file called a manifest or playlist lists which versions exist and where every segment can be found. Two protocols dominate packaging: HLS and DASH. They are similar in spirit, differing in file formats and in which devices support them natively.
Packaging is also where protection and extras are attached. Encryption for rights management can be applied here, and information such as video metadata, chapters and caption files is stored or referenced alongside the video.
Stage 5: Origin storage and content delivery
The packaged files sit on an origin server or in cloud storage. Sending every viewer’s request to that one place would be slow and costly, so providers copy popular segments to servers spread across many locations. These content delivery networks place data physically and network-wise closer to viewers, which typically shortens the journey and reduces load on the origin.
Delivery is the stage where much of the real-world variation occurs. The viewer’s home network, mobile coverage (including, where available, 5G networks), and congestion along the route all affect how quickly segments arrive.
Stage 6: The player
The player is the software on the phone, browser, console or television. It does several jobs at once:
- downloads the manifest and chooses a starting version;
- requests segments ahead of the current playback position and stores them in a buffer;
- decodes video and audio and keeps them in sync;
- measures how quickly downloads are completing and switches versions if conditions change, a technique known as adaptive bitrate;
- negotiates a license and decrypts the content if it is protected.
Because the buffer holds a few seconds or more of upcoming video, brief network dips can often pass unnoticed. When the buffer runs dry, playback stalls; the buffering causes are explored separately.
Where delay comes from
Each stage adds some time. For on-demand viewing the delay mainly shows up as startup time. For live events, capture, encoding, segmenting, delivery and player buffering together mean that viewers commonly see the action some seconds after it happens, and on traditional setups it can be a good deal longer. Reducing that gap usually means trading away some safety margin, which is why stream latency involves compromise rather than a single fix.
Interactive uses such as video calls take a different route altogether, using technology like WebRTC calls to send media with minimal delay instead of fetching pre-cut segments.
What this means in practice
Seeing the pipeline as a chain helps explain common experiences. A blurry picture that sharpens after a few seconds is usually a player starting on a lower version and moving up. A video that works on one device but not another may come down to codec or protocol support. A live stream that trails the commentary on social media usually reflects accumulated delay in several stages.
Creators and publishers can only influence some of these stages. Export settings, upload quality and choice of platform are within their control; the delivery network and the viewer’s connection mostly are not. Looking at video analytics can reveal whether viewers are experiencing problems such as long starts or frequent quality drops, which helps separate content issues from delivery issues.