If you’re broadcasting to Twitch with a recent version of XSplit or OBS, you may have noticed the option to select between VBR (variable bitrate) and CBR (constant bitrate). We’re suggesting that all broadcasters use CBR for several reasons, all of which relate to the final quality of service (QoS) that your viewers will experience.
Twitch does not reencode your video after receiving it; whatever is sent to our servers is sent right back out to your viewers. If you’re a partner, we perform a “transcode” on the live stream which creates additional resolution options. These options are always encoded with CBR settings, but live will still remain untouched from the original broadcast.
The main problem with VBR is during lulls in the action: paused games, hero selection screens, even famous talking heads. During these sections of video, VBR streams produce a significantly lower bitrate, which can cause issues on pretty much any end-user connection when the bitrate spikes back up during the action (team fights, Protoss vs. Protoss battles, 2GD petting Victory Cat). This is due to interactions between multiple RTMP, other TCP streams, routers, buffers, and a whole complex morass of tech buzzwords.
VBR also leads to issues when sending data to the Twitch network over many ISPs. When connecting to Twitch, the route your ISP takes may not be stable enough to handle sudden increases in bandwidth, leading to “broadcast starvation.”
Broadcaster starvation is when you attempt to stream at a bitrate that is too high for your network/isp, causing frames to be dropped before entering the Twitch network. This leads to lag for everyone including people watching on your lower resolutions, if you have them. When using VBR, the needed bitrate for the video may hit these limits, causing the starvation.
TLDR: Variable bitrate is bad for video over the internet due to how TCP (the internet protocol most streaming video uses) works, and you should use CBR whenever possible.