Bitrate, what does that mean?
In the following we want to limit the scope to what’s relevant for both the MPEG-2 video and for the DVD specifications. MPEG-2 may be used for many other purposes than for just making DVDs. The DVD specification uses only a subset of what is specified by the MPEG-2 video specification, ISO/IEC 13318-2.
Throughout the article we use BitVice, a software MPEG2 encoder for the Apple Macintosh platform, designed by Innobits AB, as an example. While the terminology and behavior of different MPEG2 encoders may vary, the underlying principals are shared among all MPEG2-compliant devices
Average bitrate is the:
These calculations are as simple as speed and distance calculations for a trip on a highway. They tend to involve big numbers, but today everyone has access to an electronic calculator, which helps keeping on top of many digits.
Bitrate sliders in BitVice
The “Floor” bitrate slider is used for setting a recommended lowest bit rate. This is just a hint, not a hard limit. So, if some pictures are very easily encoded and need almost no bits at all (like a set of black or otherwise very simple frames) then BitVice will take advantage of such opportunities to save bits to be used in more complex parts of the movie. Still it can be a waste to set the floor slider to high, because low detailed and/or slowly moving pictures would then be much less compressed than other segments, i.e., using unfairly many bits compared to the most highly detailed action scenes, for the same average bitrate.
The “Ceiling” bitrate slider is used for setting the max bitrate. This is a hard limit. The Max bitrate is the hardest to describe, because people think they already have a reasonable understanding of it, although most people just don’t. For in depth explanations, please, read all the way to the end. I will try bringing it to you in the gentlest way I know how.
VBR and CBR
CBR video means that each segment of a movie use the same average bitrate as all other segments. Note that there is nothing else that is constant about CBR, than the average bitrate over time. (CBR, at least ten years ago, was mostly used because it was considered much less complicated to multiplex audio with video at CBR, than at VBR)
Beyond the basics
The size, in kilobytes, of each encoded frame, will very much fluctuate in a particular MPEG-2 video stream/file. Therefore, the shorter duration one uses for calculating the average bitrate, the wilder it will fluctuate. Remember that bitrate is measured in bits per second, so one has to decide a certain duration, expressed in seconds, under which the number of bits should be counted.
Ready for a surprise?
How on earth does it work then? You may ask.
Instead they defined the decoder in such a way that it has to have a RAM buffer of a certain size. This decoder buffer gets filled, by reading from the stream or file, at the receiving end, at a constant bitrate. It is also drained at the other end, one picture at the time. The filling and draining processes follows very different patterns.
Reading from a DVD for example, normally means filling the buffer at a steady bitrate, e.g., at 9.8 Mbps, until full, at which point the reading comes to a complete halt.
The decoder, though, is removing each picture from this buffer momentarily (at an infinite bitrate) at the regular picture intervals (every 40 ms for PAL). Since the picture sizes vary from frame to frame, this means that one frame may take several hundreds of milliseconds to read from disk into the buffer, but the next may take only 5ms, at the same reading bitrate.
Note that a big picture, e.g., an I-frame, could have an individual bitrate of 40 or 50 Mbps, without necessarily violating the specified bitrate criteria. It all depends on how small other adjacent pictures are. Since the pictures are read from disc at a constant bitrate, but never at a constant frame rate, it doesn’t matter much how big they are.
In other words:
Decoder buffer fullness graph
An MPEG-2 Encoder is responsible for keeping the decoder buffer from running dry. This is where the term max bitrate becomes of interest. In this context the notion of “peak bitrate” becomes irrelevant and useless for precise bitrate measurement and management. In BitVice terminology we call this limit the “ceiling bitrate”. It works as a hard limit and can be set by the using a separate slider. BitVice guarantees that buffers will never run dry, as long as the decoder/player is able to read at this speed. The ceiling setting in BitVice does not affect the average bitrate, or the final file size, at all. The limiting function only kicks in for the pictures, which have the highest encoding complexity, i.e., which are the most difficult to compress without introducing encoding artifacts, i.e., undesired picture distortions.
DVD and max bitrate
At least from an undamaged replicated disc a, DVD compliant player should be able to read MPEG-2 data at 10.08 Mbps /s. Out of that only 9.8 Mbps /s may be video.
If a video stream can be filled into the decoder buffer, from a DVD, at a sustained filling rate of 9.8 Mbps and if this rate is enough to keep the decoder buffer from ever running dry, then the video stream is said to have a max bitrate of less than 9.8 Mbps. So, the Max bitrate of a certain .m2v stream equals the Min bitrate at which video data is required to be read from the file, and put into the decoder buffer, in order to keep the buffer from ever running dry.
You need to consider the importance of whether the audio is compressed or not and how many audio tracks there should be bandwidth available for on a DVD. When DVD SP, for example, is complaining about too high bitrate it is most often due to the fact that uncompressed audio, or more than one audio track, was used. In such case you need to compensate (lower) the ceiling video bitrate to allow for the higher than normal audio bitrate. Audio and video, multiplexed together with anything else, always has to be lower than 10.08 Mbps.
One video stream at max 9.8 Mbps (average could be 4.5 or something)
One audio at a constant 0.192 Mbps (AC-3 compressed)
9.8 + 0.192 = 9.992 Mbps
This gives a small margin of only 0.088 Mbps (10.08 – 9.992)
One video stream at max 9.2 Mbps
One audio at a constant 1.54 Mbps (uncompressed)
9.2 + 1.54 = 10.74 Mbps
This will not fit into 10.08.
But, if we lower the ceiling bitrate for the video to 8.2 there will be a margin of around 0.3 Mbps
One video stream at max 8.5 Mbps
Five audio streams at a constant 0.192 Mbps (AC-3 compressed) 960 kbps total audio
8.5 + 0.960)= 9.46 Mbps
This gives a margin of 0.62 Mbps
Good news – BitVice already has a stream analyzer built in, which automatically and reliably takes care of this problem. So, using BitVice, you don’t have any use for a bitrate graph, even if it would have been possible to design a reliable one.
BitVice prevents any buffer violations from occurring, by constantly analyzing, frame by frame, the internally generated stream against the ceiling value set by the user. At the same time it maintains a mathematical model of the buffer fullness graph. Therefore, it knows in advance exactly how many bits there would be left in the decoder buffer, at any point in time. Each movie segment will get re-encoded whenever the previous try failed the ceiling bitrate test. So, not a single picture is committed to file unless meeting the max bitrate criterion can be guaranteed.
Text: R. Andersson, Innobits AB