I had a great question today about bitrate control in MegaPEG.X as opposed to other encoding tools, and this is what I wrote:

If you look at all the people having trouble encoding multi-angle DVDs to fit within the channel constraints of the DVD spec, you can see that the problem is the numbers they are using for the math. The math itself is simple: A+B=C

In all the documents for all the ISO MPEG specifications you see only one number for bitrate. In MPEG-1 and MPEG-2 video it is in the sequence header, that one number for bitrate, and that number can represent both VBR and CBR, as they are understood in MPEG parlance.

If you look at Program streams (DVD VOBs) and Transport streams, it's called the mux_rate. Simplistically, we arrive at the mux_rate as follows:

audio_bitrate + video_bitrate + padding_bitrate + mux_overhead = mux_rate

But there is only one number for each stream bitrate.

Those single bitrate numbers, and those numbers alone, exclusively govern the world of MPEG rate control, at least as it applies to ISO-11172 and ISO-13818 which are MPEG-1 and MPEG-2.

All this other terminology, average, peak maximum, minimum - these numbers can be derived from looking at the MPEG bitstream with a tool like MPressionist.X. But when it comes to bitrate control, there is only one number that counts - and that number relates directly to the rate control model which is outlined in the ISO documents.

In effect, average, peak, maximum and minimum bitrates can be seen as ways of looking backwards through the telescope and seeing what any particular MPEG encoder did with a particular piece of source footage. But those numbers have nothing to do with rate control. In fact, they are really a statistical description of the nature of the source material. Every encoder, CBR, VBR, ConstantQ, every encoder will generate a file with average, peak, minimum and maximum. These numbers are a byproduct of the encoding process.

That one number (sequence_header.bitrate) is the number that we use in MegaPEG.X; because that's the number that the muxer cares about, it's the number that the channel constraints refer to, and its the number that determines whether or not your movie is going to play on a hardware device, or in a multi-program satellite transmission or on some new box or application in the future that we don't know about yet. That's what standards are all about. If it's correct today, it will still be correct in 30 years. Using that number also means you can do the simple math of A+B=C (see above) and get the result you were expecting.

By extension, if you take two files and encode them with MegaPEG.X at 4 and 5 Mbs respectively, they will meet the channel requirements for multi-angle DVD or a multi-program satellite stream or any other medium that specifies a combined rate. If it turns out not to be true, then that person should be talking to tech support and I will help figure out what the problem is.

If an encoder does bitrate control with average/peak, it is impossible to 'do the math' as it were and simply add two different elementary stream bitrates together to determine a combined bitrate. The resulting number you get in that case will not represent anything related to the headers in the bitstream, or in the mux. The belief that two streams each with a 4Mbs average bitrate can be combined to meet the channel constraints of a 9.8 Mbs channel, well now that is the source of the problem, and as Yoda would say, the cause of much suffering. Even worse would be the case where the sequence_header.bitrate is actually a smaller number than the actual bitrate vis a vis the rate control model.

I refer the reader once again to my favorite Hollywood disc, "The Mask", which clocks in at an average bitrate of 4.104 Mbits/sec. However, the sequence_header.bitrate value is 7.5 Mbs. So you can see the cause of the confusion. If you took the average bitrate value of theMask.m2v as suitable for determining a combined channel bitrate, you'd end up with a value that is too low by almost half. No, the bitrate for "The Mask" is 7.5 Mbs, and after the encoder discarded all the unneeded bits at that rate and padded the bitstream up to what would appear to be 4 Mbs, then we get to the average. But the average has absolutely nothing to do with the bitrate control. In fact, in the case of the Mask, by looking at how the bitrate rises at the end of the movie during the credits, I would theorize that the encoder was given a bit-budget (ie. exact file size) to work from, and by the time the credits rolled around, there were extra bits to go round.

As a final note, I will say that 'minimum' bitrate has a specific meaning in MPEG, and that is, a true minimum number of bits-per-second that an encoder or muxer must emit in order to meet a channel (device) requirement. And if the encoder or muxer does not have any valid or useful video/audio bits to emit, then it shoves something called 'stuffing_bits' (aka padding) into the bitstream. And it shoves just enough of them to meet the minimum, and then it stops.

In my experience, I say it is very easy to let bitrate fluctuate around some average value and let it rise and fall to produce good looking video. And conversely, it is very, very difficult to produce good looking MPEG bitstreams that adhere to the MPEG specification for rate control. And the lower the bitrate and the more difficult the source material, the more impossible it becomes. Hence, in MegaPEG.X, a vast 'bag-of-tricks' to draw from - the harder the encoding challenge, the more deeply you can reach into the bag. And if it seems like the bag is empty, you can email us at tech support and see if we can't work together to add a new trick or extract and extra bit of juice from what's already there.