How live video streaming works
The four stages a live stream passes through between the camera and the viewer
Live video looks like one continuous pipe from the camera to the viewer. It is really four stages — capture and ingest, processing, distribution, and playback — each solving a different problem and each failing in its own way. Knowing which stage you are looking at is most of what makes a streaming problem tractable: a feed that never arrives from the venue and a viewer whose picture keeps stalling are the same complaint about two different stages, and they have nothing in common to fix.
Stage 1: Broadcast
Everything downstream depends on what leaves the venue, and this is the only stage you cannot redo — there is no second take on a live event.
Capture
Recording the video and audio. A large event typically means several cameras placed for different angles, and microphones chosen deliberately: audio problems are harder to disguise than video problems, and viewers tolerate them less.
Ingest
Getting the captured video and audio to a streaming server. A globally distributed event usually needs more than one ingest point, so that a camera's data does not cross the planet before encoding starts. Ingest has to absorb high-bitrate feeds from several cameras at once, because the alternative to absorbing them is dropping frames that no later stage can restore.
Stage 2: Processing
A camera's output is not something you can send to a phone on a train. This stage turns one large, pristine feed into several streams that real networks and real devices can play.
Encoding
Compressing the raw feed into a manageable size while holding quality. Raw high-definition video is far too large to distribute as captured, so every live pipeline encodes.
Transcoding
Producing several versions of the stream at different qualities from the encoded feed, so a player can pick one that matches the connection and screen it has:
| Rendition | Who it is for |
|---|---|
| 1080p or 4K | Viewers on fast connections and large screens. |
| 720p | Average connections and most mobile devices. |
| 480p or 360p | Viewers on slow or congested connections. |
A player that can only be handed one quality has to either stall or look wrong on every connection except the one it was built for. Producing the ladder here is what lets playback adapt later.
Stage 3: Distribution
The stream now exists in several qualities in one place, and the viewers are everywhere else.
Packaging
Preparing the encoded video for delivery in a streaming protocol — RTMP, WebRTC, or HLS. The choice sets the latency and reach you can achieve, and it is not easily changed later; see Streaming protocols for the comparison.
Content delivery network (CDN)
A geographically distributed set of servers that each serve viewers near them, so the stream crosses the long distance once rather than once per viewer. This is what holds startup time and stalling down as an audience grows, and it is the difference between an audience you can serve and an audience that overwhelms the origin.
Stage 4: Playback
Where the four stages either add up to something watchable or do not.
Video player
The player is the whole of the experience for the viewer, and the only stage they can see. It selects a rendition from the ladder produced in stage 2 and switches between them as the connection changes, which is why that ladder has to exist.
Device compatibility
The same stream has to play across screen sizes, resolutions and codec support. Devices differ in which protocols they can play at all, which is the constraint that usually decides the packaging choice back in stage 3 rather than the other way round.