Bit rate spikes above 7.3-maximum setting?

Question

Hi
I have used a setting of 6.5 ave - 7.3 maximum-2 pass VBR with compressor 1.1 & AC3-192-audio. Burned a DVD-R of the DVDSP2 project and it plays fine in my set top player. However, I noticed when I watched the bit rate display (ave. & max. bit rates- which is an option on the set top player) while playing the DVD-R, the maximum bit rate spiked to 9.4 for a split second on one scene and would jump to 8 to 9 at other times for a split second on a few other scenes. Most of the time peaks were around 7. My question is will this present a problem for playback compatibility on some set top players? Or is this normal & not a problem for most set top DVD players as long as the bit rate spikes are very short in duration? I find it odd that the maximum bit rate setting of 7.3 that I used was over ridden that much to allow 9.4 as a peak-maybe the set top bit rate display is not totally accurate?
I have to burn 300 DVD-R's of this project for mail order distribution (will be burning at 1X using Taiyo Yuden media) so I need to make sure of playback compatibility with most DVD players. Can anyone shed some light on any issues that these sporadic high bit rates might present or is this not an issue for playback compatibility on most set top players?
Thanks in advance...
Della

Answer 1

Della,
Did you try the BitVice demo yet?
I'd be happy to help, so that your experiments with it will be fruitful. If you contact Innobits with any questions, I promise I will answer you personally. You are right in the assumption that bitrate graphs will not tell you any real truths. At least not those you were looking for:-(
Dear you all, Della included of course,
As one of the scientists behind the Bitvice MPEG-2 encoder, I am sad about the time we spend helping people clarify the crazy things they hear. Fortunately there are forums, such as this one, where hopefully clarifying the same things multiple times is not necessary. (Thus the invention of the FAQ)
At BitVice we treat our customers very well, and we are happy to help on this topic also.
There are so many misconceptions about maximum bitrate floating around on the Internet. Therefore, in a perhaps futile attempt, I decided that this might the time for putting my foot down. Hopefully, it may shed some light on the subject, at least to some of you.
No names, but I know that some of you are far better than me to explain technical things in a more "popular" form to members of this forum. If any of you wish to "translate" the essence of it into a more human readable format, please contact me off-line to get a "complete story".
I am not aware of any publically available diagnostic tool, for momentary (peak) bitrate graph calculation, that could be seriously used for MPEG-2 video stream evaluation against what is meant by "maximum bitrate", as defined in the DVD, or MPEG-2, specifications. Please, correct me if you think I'm wrong.
Bitrate graphs are generally created upon inspection of a .m2v file and based on some (non-standardized) time interval.
Depending on how (by which intervals) you are calculating a momentary bitrate of a .m2v file, it may very well vary between 1 to 40 Mbps, even for DVD compliant constant bitrate streams. The MPEG-2 group was obviously aware of this fact and therefore didn't even try to define what "momentary bitrate" is. And, INTERESTINGLY, there is absolutely no need for such a measure anyway, at least not where MPEG-2 is concerned. I hope the following will help to explain why that would be like weighing of a truck by measuring its length instead, regardless whether it was empty or fully loaded.
The DVD spec. has a 9.8 Mbps limit to the video bitrate, and 10.08 Mbps for the total bitrate. However, this has very little to do with what many bitrate graphing applications is trying to tell you. I'd say, unless they offer you to decide which maximum bitrate it is supposed to measure against, it is just pulling your leg. I think this is really sad. You didn't ask, or pay, to be falsely comforted, did you?
It really doesn't work the way you are led to believe. Actually, the MPEG-2 specification is completely silent about how to even calculate any "peak" bitrate (just because it is really beside the point). Instead, this rate problem is handled in a far more sofisticated and clever way, namely by looking at the decoder buffer fullness at all times. This seems to be completely ignored by most bitrate graphing utilities.
Don't get me wrong here, such utilities can still be rather useful for getting a general idea of which parts of a movie requires more bits than others, but that's about all they can do. For your own mental health, don't fall into the trap of thinking that the highest peak (momentary bitrate) is telling you what the max bitrate is. Sorry, if this sounds confusing at first.
The correct way of interpreting the term "maximum" bitrate is
NOT by comparing to any kind of bitrate graph. That is simply because MPEG-2 does not even define any way to calculate such a thing.
Instead, one needs to think of the "maximum" bitrate as the maximum CONSTANT sustained rate, at which a decoder is capable of reading (or pulling) the data from e.g., a DVD disk. Just think about it for a little while and you will understand that it is more a property of the decoder/player than of the MPEG stream (file) itself. Of course, the responsibility of meeting these requirements rests solely on the MPEG-2 encoder. However, and this is very IMPORTANT, the encoder is COMPLETELY FREE to chose ANY strategy or policy to ascertain that the buffer requirements are complied with. That alone, is enough to leave bitrate graphing utilities in the dark of what is really going on.
If the time it takes to display some already buffered frames (which could amount to say 50 to 300 ms, as counted in display time, depending on the situation) is too short for the next (big) frame to be pulled in its entirety from the disk, then the decoder buffer will underflow. Meaning; that no complete frame was received in the buffer by the time next frame was supposed to be decoded. This situation is where you can honestly say that the bitrate of the stream was higher than the decoder was capable of reading.
However, this is a very tricky thing to capture in a bitrate graph just by inspecting the stream, unless you know everything about the current state of the buffers in general (meaning that its recent history is important) AND more specifically knowing at which rate the decoder is supposed to be pulling picture data from the disk, including, of course, any imperfections in the DVD media.
Given this maximum sustained "pulling" rate, which actually corresponds to the "ceiling" setting in BitVice terminology, it is up to the MPEG-2 encoder to create a stream (.m2v file) that will never, neither overlow nor underflow the decoders' buffers. For those who think a step further on this matter, it means that there exists no common time (duration, measured along the display-time axis, or a number of frames) over which one can calculate a peak bitrate. So, however you choose to do; averaging number of bits over one second, over half a second, over a certain amount of frames or whatever, you will NOT find the correct answer to how the bitrate graph should look like, if you want to be able to interpret the peaks as reflecting what the max bitrate is.
Let's agree that an MPEG-2 stream NEVER has a constant frame rate, as seen by a decoder reading at a constant "maximum" bitrate. From this follows;
Assuming a duration, as counted in display time, by which you can divide the number of bits to get a bitrate, is rather pointless, and also wrong. However, that is generally what is assumed by a bitrate graphing utility.
An MPEG-2 video stream NEVER has a constant frame rate, as seen by the decoder. One frame may be swallowed 5 ms and the next may take several hundred milliseconds to completely enter the decoder buffer.
This is because every frame has an individual size, which may vary most considerably (even for CBR), but the decoder reads the stream of them at the same (normally maximum, see the PS below) bitrate. So, while the decoder is displaying one single frame on your TV monitor, it may be receiving and decoding several successive smaller frames. On the other hand, while receiving/decoding larger frames (e.g., I-frames) it will have time to display many previous frames on your monitor, before a single later, and bigger, frame has been completely read into the decoder buffer. I hope this explains why you should be careful about how you interpret any bitrate graphs, especially when maximum bitrate is concerned. (That's the primary reason why we have not designed such a tool for our customers yet).
Instead, and contrary to many other encoders, we have designed the bitrate control in BitVice in such a way that;
1) The target bitrate that you choose (the average over the whole movie) is enforced, extremely accurately, usually less than 0.1%. I have seen files generated by other encoders which have been 200% off the desired bitrate, though. (To get the true average bitrate of an m2v file; divide its number of bits by its duration expressed in seconds. Then you'll see what I mean. Extremely simple math for a 12 year old kid, although the numbers may be big and therefore tend to have many digits in them;-))
2) The "Ceiling" bitrate is NEVER exceeded, not even by one single bit/s. Now, frankly, if your bitrate graphing tool says something else, then it is telling you more about itself than about a file generated by BitVice.
There is sort of a contract between encoder and decoder, like this, where X is the maximum bitrate:
Decoder:
"I promise you that I am able to read your video stream at X Mbps, or less, for as long as you wish."
Encoder:
"OK, then I promise you that my video stream would never need to be read any faster than X Mbps, at any time, and your buffer will never overflow or run dry. However, if your buffer is less than THIS big (the needed buffer size is written at the beginning of the stream, normally 1835008 bits or 224 kB), then you can as well stop already.
I don't know how every other MPEG-2 encoder works in this respect, or if bitrate graphs could be of any help in evaluating them. The only thing I can promise is that with BitVice you can rely on its bitrate control to deliver what you asked for. You could use BitVice in your evaluation of different bitrate graphing utilities though, if you like.
I'll stop here, because I sense that even those of you who have read this far may want me to;-), but, this topic is enough to fill one whole chapter of a book that I may never find the time to write.
I realize that this post may seem controversial at first, so I'm prepared to follow up on any questions, suggestions or comments that you might have.
Kindest
Roger Andersson / Innobits AB, makers of BitVice MPEG-2 encoder for Mac
PS.
Of course, a decoder is assumed to completely stop reading (pulling) from disk whenever its buffer gets full, but then continues at full speed (maximum bitrate) again, whenever the buffer is NOT full.
So the true bitrate graph, according to the decoders' view, is be very easy to recongize, becaue it will just alternate between two values, 0 Mbps and the max bitrate.
Ds.