CBR, VBR and ABR – what do they mean?
Within the media industry, we often hear discussion of the bit rate of a file. There are several ways to encode (and therefore describe) the bit rate of a file, the most common being CBR, VBR and ABR. Their meaning and uses are quite different, though. In this post we’ll cover what each of the acronyms actually means, where that type of encoding is most advantageous, and what the relative disadvantages of each type of encoding are.
CBR – Constant Bit Rate
Constant Bit rate means that the number of bits used to encode some period of time remains constant throughout the file. Bit rate in general is specified over a period of 1 second (hence “3 Megabits per second”). So a constant bit rate file will always use the same number of bits to encode each second of media. This makes it very useful in systems which need random access to that media: if each second of media is 3 Megabits, and you want to jump to the start of the 3rd second of a file, then you know you have to jump 9 Megabits from the start of the file – it’s very easy to deal with. CBR is clearly well suited to non-linear editors, and even play out servers.
VBR – Variable Bit Rate
There is a disadvantage to CBR – if one specific second of media is very easy to compress, it may well be possible to encode it at a much lower bit rate without visible artifacts. In CBR, you would have to fill in the “gaps” with null packets that carry no data. This is very wasteful when storing the media. As its name implies, VBR allows you to vary the number of bits used to represent each segment of time (i.e. each second) – easy to compress sections of media can use less bits, and more difficult to compress sections of media can use more bits. The important things to know in this case are the average bit rate, the maximum bit rate and in some cases the minimum bit rate. The average will tell you roughly how much storage any file of a given duration will take on disk, the maximum lets you know how much bandwidth you absolutely must provide in order to transfer the material in real time, and the minimum can be useful in designing the receiving buffer’s status reporting (the so called “low water mark). VBR is especially useful in bulk storage of media, but the fact that any second of the media is of indeterminate size makes it computationally expensive to do random seeks into, and is therefore generally not used for true random access.
ABR – Adaptive Bit Rate
This technology is most commonly used in streaming files over the internet, and is designed to maximize the user’s quality of experience – particularly to remove that irritating “stop-start” type of experience which happens when the receiving application has to buffer content before it can play it out. The principle is simple: encode a piece of material at several bit rates, from high to low (with a corresponding decrease in image quality with every step), and chop the resultant files up into segments (“chunks”) of some number of seconds duration. Each segment has to start at exactly the same source time code number – that’s the major trick. The receiving application then watches its input buffer, and if the bandwidth on the link drops (so the buffer starts to empty), it will switch at the next chunk boundary to a lower bit rate. If the network bandwidth improves, the buffer will start to fill up, and the application will switch at the next boundary to a higher bit rate version.
If you have trouble visualizing this, think of a bucket with a hole at the bottom. The hole represents the playout video, which we want at some fixed rate. You turn on the hose, and the bucket starts to fill, and ultimately stabilizes at some level. Now you decrease the water flow from the hose (the network bandwidth drops). Water still exits at the same rate, so the bucket starts to empty. When you get low enough, you turn the hose on more (more water/second, or more frames/second), and the bucket starts to fill up again. Once you’ve reached a safe level, you can turn the tap down again. The idea is to make sure that water always leaves the bucket at the same rate – in video terms, no buffering delays.
Want to go deeper into the world of bit rates and encoding? Check out our Learning Center where you can find resources on video encoding, transcoding and file-based workflows.