bitvice.com

Scope
Bitrate is one of the most misunderstood concepts of MPEG-2 video. So, what does it really mean? You may have heard about average, low, high, max and peak bitrates. The confusion is building up.

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

Basics
Let’s first establish some very basic stuff, which even my 83-year-old father-in-law, who doesn’t even have his own computer, should be able to understand.

Average bitrate is the:

• File size (measured in number of bits)
• Divided by Duration of the clip (measured in seconds).

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
For BitVice this means that when you set the “Target” bitrate slider, you are also setting the maximum size of the MPEG-2 file that will be generated (since the duration of the movie does not change by setting a new bitrate for it, only the file size is changed). You can see what the file size will be, when dragging the “Target” bitrate slider. Under certain rare conditions, BitVice could produce a smaller .m2v file than indicated, but almost NEVER a bigger one.

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
VBR video means that the average bitrate of different segments of the movie may use higher and lower average bitrates compared to the movie as a whole.

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
From now on, things may start getting a bit more complicated, but not so very much. The following may need some fresh thinking though, since until now most of you have been kept in the dark, or led to believe in fairy tales, dressed up as scientific facts. I am going to explain what “max bitrate” really means, as for the 9.8 Mbps limit defined for Standard Definition DVD, and also why one cannot use a bitrate graph to determine if a particular file meets this criteria or not.

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.
For example, if you calculate bits/s on a frame-by-frame basis, i.e., every 40 ms for PAL, you would easily see a ten- to twenty-fold variation, or more. Actually, the bitrate of a single I-frame could be many times higher than the max bitrate. This effect is more or less the same for both CBR and VBR. In other words, even for CBR streams the difference in size (or bitrate) between I- P- and B-frames normally fluctuates much more than the average bitrate varies in different parts of a VBR encoded movie.

Ready for a surprise?
There exists no definition of any certain duration, at which an average, max, peak or momentary bitrate should be calculated and/or measured. This is why bitrate graphs are of very limited value, in particular for deciding the max bitrate of a certain MPEG-2 video stream. The actual peaks in such a graph will occur at different points in time, for the same MPEG-2 file, depending on the duration chosen for the bitrate calculation. And, again, there exists no such definition. The peaks could therefore be plotted at higher values than the max bitrate, while the file is still perfectly within the specifications.

How on earth does it work then? You may ask.
The MPEG-2 expert group very cleverly avoided his seemingly hopeless problem, by keeping completely silent about terms like peak and momentary bitrates, at all. In fact, it would have become a real nightmare if they had decided anything else.

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:
Filling – always occurs at a constant bitrate (or zero if already full), which means a variable frame rate.
Draining – always occurs at a constant frame rate and at one of two bitrates, or speeds. While no pictures are removed the speed is zero, but when a picture is removed the speed is infinite. The amount of data removed from the buffer changes for each picture.

Decoder buffer fullness graph
Instead of a bitrate graph a mathematical model of the decoder buffer fullness must be used. The buffer fullness graph is shaped like “saw-tooth wave” with irregular teeth, slowly building up over time and instantly falling down a little bit, or maybe rather much, depending on the picture size, at each frame interval. If the buffer gets full, then the reading just stops, preventing overflow. However, if the complete data for the next picture has not arrived in the buffer at the time when it is due for decoding, then the buffer is said to underflow, or running dry. This underflow situation is a hard indication that the stream used a higher bitrate than at which it could be read into the buffer.

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
DVD authors are familiar with the fact that the DVD specification limits the video bitrate to 9.8 Mbps and the total bitrate (including audio) to 10.08 Mbps.

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.

Example 1:
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)

Example 2:
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

Example 3:
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

DVD Media
The decoder buffer will never run dry, as long as the video data is read at the max bitrate, which equals the ceiling bitrate a particular stream was created to keep below. However, even with a perfectly legal stream a player may still have difficulties with keeping the reading speed up, especially when reading from lower quality and possibly scratched home burnt DVD +R, -R, +RW or -RW media. For the purpose of making such discs playable from more types of media and on more types of players, some people prefer lowering the ceiling to say 7 – 8 Mbps, even when the audio is compressed to only 192 kbps Dolby AC-3. Replicated/printed discs are always easier for a player to read correctly and in a timely manner.

Summary
Bad news – It is not possible to design a bitrate graph in such a way that its peaks can be used for validating whether a video stream meets a certain max bitrate criterion or not. To ensure this, you first need to establish what the max bitrate should be measured against, the ceiling in BitVice, before any measurements can begin. Only then you are able to validate compliance with the max bitrate limitation.

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.
If you set the “Ceiling” slider in BitVice correctly, you will not run into any “buffer empty” problem. Just set the ceiling bitrate so that, if added together with all your audio files etc the summed bitrate will not reach 10.08 Mbps.

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