The short version
A game stream is a live video broadcast with a game as its subject. Four things happen in order: the picture and sound are captured, they are compressed into a small enough stream, that stream is sent to a service that copies it for many viewers, and each viewer’s device unpacks and displays it. Everything else, such as overlays, chat and alerts, is built around that chain.
The chain runs continuously, so every stage has to keep up with real time. If one stage falls behind, the viewer sees stutter, drops in quality, or a growing delay.
Stage 1: capture
The broadcaster first needs a copy of what is on the screen. On a PC, the streaming software can usually grab the game window or the whole display directly from the computer, along with audio from the game, a microphone and any other sources. Many streamers also add a webcam image, text and graphics, which the software combines into a single “scene”.
Consoles do not run that software, so a separate route is needed. The console’s video output is sent to extra hardware that copies it to a computer, which is the job described in what a capture card does. Some consoles also have a built-in broadcast feature that sends the picture straight to a service without a computer.
Capture is not free. On a PC, the machine is running the game and the broadcast at the same time, which is one reason people use dedicated hardware or a second computer. The load falls mostly on the processor and the video hardware, so a weak spot in either can show up as a lower frame rate in the game or in the stream.
Stage 2: encoding
Raw video is enormous. An uncompressed picture at normal resolution and speed would need far more bandwidth than a typical home connection offers, so the software compresses it with a codec, a method for describing video in far less data. The program that does this is an encoder.
Encoding can run on the main processor in software, or on dedicated circuitry inside many graphics cards. Software encoding is often more flexible and can look better at a given size, but it takes processor time away from the game. Hardware encoding is usually lighter on the processor, though quality at a given size can differ between designs.
The broadcaster picks settings: the screen resolution of the stream, how many frames per second, and how much data per second the encoder may use. That last setting is the central trade-off, and it gets its own treatment in the discussion of stream bitrate. In short, a picture with a lot of fast motion needs more data to look clean than a calm one.
Stage 3: sending to the service
The encoded stream travels from the broadcaster to a streaming platform’s servers, usually called the ingest point. The upload leaves the broadcaster’s home on their internet connection, so the connection’s upload speed sets a ceiling on what is practical. Many home connections are faster at downloading than uploading, and wireless links can fluctuate, which is why many streamers prefer a wired connection.
If the upload cannot keep up, data queues. Depending on the software, it may drop frames, lower quality or disconnect. The same kinds of problem that affect online multiplayer, such as packet loss and unstable ping time, can also hurt an upload.
Stage 4: processing and delivery
Once the platform receives the stream, it rarely forwards it as it is. A viewer on a phone with a weak connection cannot watch the same stream as a viewer on a fast home network, so platforms typically make several lower-quality versions, and each viewer’s player picks one that suits their connection. Not every channel gets every version; the options available vary by platform and by channel.
The platform then spreads the stream across many servers so that large audiences do not all pull from one machine. The video is cut into short pieces, and the viewer’s player downloads the pieces one after another and plays them in order. Working in pieces keeps playback smooth, but it is also a main reason live streams lag behind real life. Players keep a small buffer of pieces to ride out network hiccups, and that buffer adds delay.
Stage 5: playback
On the viewer’s device, a player downloads the pieces, decodes them, and shows the picture. Decoding is much lighter work than encoding, which is why even modest devices can watch streams. The player also watches the viewer’s connection and may switch between quality versions mid-stream. A brief blurry patch followed by a sharper picture is usually this switching, not a fault in the broadcaster’s setup.
Why streams are delayed
Delay builds up at every stage: capture, encoding, upload, processing, the pieces and buffer at delivery, and decoding. Typical total delays for ordinary streams are a few seconds, though exact figures differ by platform, settings and mode. Some platforms offer lower-delay modes that trade a little stability for a shorter wait.
This delay matters for how chat works. Viewers react to something they saw seconds ago, so the broadcaster sees the reaction later still. It also matters for anyone playing along with a stream, since the stream is a record of the recent past, not the present. It is unrelated to the input latency the player feels in the game, which depends on the game’s own pipeline.
What the viewer adds
A stream is more than video. Alongside the picture there is a text conversation, and the audience takes part in it. The customs of that conversation are covered in the piece on stream chat, and the rules that keep it workable are covered under chat moderation. Platforms also run alerts and small interactive features around the video, and these are separate feeds layered on top, not part of the compressed picture.
Streaming games versus streaming from a distance
Do not confuse broadcasting a game with cloud gaming. In a broadcast, the player’s own machine runs the game and a copy goes out to an audience, who only watch. In cloud gaming, a remote machine runs the game and sends the video to the player, who controls it. The two use some of the same video techniques, but the direction of control is different.
Practical limits to keep in mind
- Quality depends on the weakest stage. A powerful computer cannot make up for an unstable upload.
- More quality is not always better. A stream that many viewers cannot play smoothly may serve them worse than a modest one.
- Exact limits, features and delay figures vary by platform and change over time, so check the current documentation of whichever service you use.