What bitrate is
Bitrate is the amount of data used for each second of video, usually written in kilobits or megabits per second. A higher bitrate gives the encoder more room to describe each moment, and a lower one forces it to throw more detail away. For a given stream, bitrate is the single setting that connects picture quality to the bandwidth available.
Two details cause confusion. First, bitrate is about data, not speed of delivery: a stream set to a certain bitrate needs at least that much upload capacity, sustained, to be sent without trouble. Second, bits are not bytes. Connection speeds are normally quoted in bits per second, and file sizes in bytes, so the two are easy to mix up.
Why compression is needed
A video is a rapid series of still pictures. Stored without compression, each picture holds a value for every pixel, and a stream shows many pictures every second. The total is far beyond what ordinary home connections can upload, and beyond what most viewers could download without a long wait. Compression is what makes live video practical at all.
How compression works, in broad terms
Encoders use several ideas that build on each other.
- Spatial compression. Within one picture, nearby pixels are often similar, such as a patch of sky or a wall. The encoder describes such areas compactly instead of listing every pixel.
- Temporal compression. Between pictures, much of the image stays the same. Instead of storing each frame in full, the encoder stores some complete frames and describes the others as changes from earlier ones, including how blocks of the image moved.
- Discarding detail people notice less. Encoders remove fine detail and subtle colour differences first, because the eye tends to miss them. This is called lossy compression: the original cannot be perfectly recovered.
The set of rules for how video is described is called a codec, and the program that applies it is an encoder. Several codecs exist, and newer ones can often achieve similar quality in less data, but they typically need more processing power to encode or decode, and not every device or platform supports every codec. Which ones a platform accepts is something to check in its current documentation.
Why games are hard to compress
Games are demanding material. Fast camera turns change nearly every pixel at once, so the encoder cannot reuse much from the previous picture. Particle effects, rain, foliage and smoke add fine moving detail. Menus and calm scenes, by contrast, compress very well.
That is why a stream can look sharp while standing still and turn blocky or smeared during action. The encoder is running out of data to spend. The same bitrate looks very different depending on the game and the moment. A slow puzzle game and a fast shooter, for example, usually need different amounts of data for a similar-looking result, which is related to how different game genres move on screen.
Resolution, frame rate and bitrate pull against each other
A broadcaster chooses three linked settings:
- Resolution, the number of pixels in each picture.
- Frame rate, how many pictures are shown per second.
- Bitrate, how much data the encoder may use.
If bitrate is fixed, raising resolution or frame rate spreads the same data thinner. A very high-resolution stream at a small bitrate can look worse than a lower resolution stream at the same bitrate, because the encoder has too little data to describe so many pixels. Many broadcasters therefore choose a modest screen resolution and a smooth frame rate that suits the bitrate they can send, instead of simply picking the biggest numbers.
Constant and variable bitrate
Encoders can handle bitrate in different ways:
- Constant bitrate keeps the data rate steady. It is predictable for live streaming, because the connection always carries about the same load, and platforms often recommend it.
- Variable bitrate lets the rate rise in complex scenes and fall in simple ones. It can use data efficiently, but spikes may overwhelm a limited connection.
For a live broadcast, predictability usually matters more than efficiency, since a spike that the connection cannot carry causes dropped frames or buffering.
Software and hardware encoding
Encoding runs either on the processor, in software, or on dedicated circuits inside many graphics cards. Software encoding can offer finer control and, at a given bitrate, often better-looking results, but it uses processor time that the game also needs. Hardware encoding costs the game less, and its quality at a given size varies between hardware designs and generations.
If a game and a stream together overload the machine, the symptoms can include lower frame rate in the game, “encoder overloaded” warnings, or dropped frames in the stream. Which part is the limit is a question of hardware bottlenecks. The relationship between a graphics card and gaming performance matters here too, since the card may be doing both the game’s drawing and the encoding.
Why the viewer’s bandwidth matters as well
The broadcaster’s bitrate is only half the story. A viewer needs a connection that can receive that much data continuously. Platforms therefore usually create lower-bitrate copies of a stream, and the viewer’s player chooses among them based on its connection. A viewer with a slow or unstable link may see a lower-quality copy than the broadcaster intended, and the picture can shift in quality while watching. Where a platform does not produce extra copies for a channel, viewers with weaker connections may buffer instead.
Reading the settings sensibly
There is no single correct bitrate. The practical limit is the smaller of three things: what the upload connection can carry reliably, what the platform allows, and what the encoder needs for the content. A sensible approach is to leave headroom below the upload capacity, because real connections fluctuate, and to test with a short private recording or a test stream before going live.
Platform recommendations change over time and differ between services, so current figures are best taken from the platform’s own guidance and not from memory. Treat any number you see quoted elsewhere as a starting point to test, not a guarantee of good quality.