It's NOT VBR or CBR that's 'keeping up', it's the player trying to handle the variation in bitrate. Changing the minimum bitrate of a VBR encode to 1/4 the maximum will cure the problem with the player trying to keep up.

Media plays no part in this.

Bob.

Sorry Bob, I realise that . .what I'm trying, TRYING to get across is that it is the process of being encoded that doesn't keep up - the encode method. This results in a wide variation and consequently the READING device can't keep up. What I'm inelegantly trying to communicate is that the encode doesn't give the player a chance. Where as the CBR has ended up WITH a nice almost flat-lined file to read. That's what I was trying to get across to you .. yeah? Sorry.

Maybe I should henceforth decide NOT to have certain templates for this player and be done?

Well no, not quite. The encoder can keep up, it's got all the time in the world to crunch it's numbers, nothing will choke no matter how long it takes, well apart from that causing a fair amount of whining here and elsewhere :)

See you've told the encoder what it's allowed to do. No matter what the bitrate must not go below 192Kb, it must not go over 8Mb and it must all average out at say 6Mb else it will not fit on the disk.

So when the encoder hits say 5 seconds of black or some totally static scene it needs very few bits of data to describe the frame, after all it's primarily looking at interframe differences. Now you've told it 'hey buddy no less than 192Kb'. No problemo, it can pad the data and meet the target bitrate. So a few seconds later you hit the encoder with say massive amounts of noise, the intraframe differences are huge. Now the encoder would really need maybe 20Mb/sec but you've told it, sorry, no more than 8Mb. So it has to ditch data, it's not able to accurately describe the frame because you've constrained the bitrate and you've done that because the player will not be able to read more than 8Mb/sec. If you were encoding for playback from HDD you could set the max bitrate much higher.
You can also see the affect of this in the Q figures, I think higher Q means better quality, note how when the bitrate is low the Q is high, hit longish periods of high bitrate and the Q falls. Short periods of high bitrate might relate to a cut, the encoder might be able to encode with little loss so the Q stays high.

The whole idea of VBR is to make the best possible use of the total number of bytes available, if you don't need a lot of data to describe the frames, let the bitrate drop, keep the byte budget for later on.

Yes, I have many templates as I encode a large range of material and do both 16:9 and 4:3. At peak periods we'd do 5 to 10 DVDs per day, 5 days per week. As I use MultiRenderer each encode might use a different template during a batch encode. None of my template let the minimum bitrate go under 1/4 the max.

Bob.

EXCELLENT explanation Bob - many thanks!

. .and your, obviously hard won experience, "None of my template let the minimum bit-rate go under 1/4 the max." speaks to me very, very well indeed.

Now, here I go again . . .

Wouldn't it be nice IF the encoder came back at me and said,

"Hey Guy, you know you COULD pick up the minimum - 'cos at the moment you're gonna have troubles with it being set so low that the ratio is greater than the FARSS 1/4 magic RATIO. How about you leave it to me and I'll pick up the min for you? Shall I?"

I do understand that 2-Pass makes the best use of still and repeated material, how about if this sequence ALSO worked out an optimum MIN?

So your: "None of my template let the minimum bitrate go under 1/4 the max." - would mean for me, working on the basis of a MAX of 8MB, a Min of 2mb - not 0.192 - yeah?

"would mean for me, working on the basis of a MAX of 8MB, a Min of 2mb - not 0.192 - yeah?"

Yes!

In all fairness to the encoder it doesn't know what you're encoding for. Just guessing here but in many instances there'd be no reason not to set the min value at 192Kb. I think from memory there's a template for encoding for ATSC, i.e. you go just encode to mpeg-2 and a TV staation sends your encoded video straight to the transmitter.

mpeg-2 is not just one thing, there's a number of different profiles as well that were defined for difference purposes, all the way up to a studio profile at 100Mb/sec that 4:2:2, so to expect an encoder to 'know' what your intent is is probably a bit much to ask.
All that said however one would think Vegas could ship with a few more templates that were a bit more goof proof.

Still if it was made too easy we'd be out of a job :)

Grazie,

Great data. Very informative. I'm not sure, however, in reading your post a few times, whether you have identified, for sure that the player loses its place exactly (plus or minus a few seconds) at the place where you have the big min/max excursion or not.

I still differ with Bob on what I think is going on, although he is correct about the player stopping the disk from spinning during long pauses. I was being sloppy when I said the disk just keeps spinning. I was really trying to say that it just stands by or doesn't do anything. Actually, I am not sure whether every player or computer drive does the same thing in the same way when there is a short pause or slowdown in the data requested. I simply don't know.

However, I'm still trying to figure out why going from min to max bitrate would make any difference to anything. The encoder, by specification, has to be able to continuously decode 9.8 Mbit/sec (see mpeg.org), so 8 (max) should not be stressing anything (assuming AC-3 192 or 224 audio).

However, if what you are saying in your post is that the quick min/max changes DO correlate exactly with the places where the players are choking, then one possible explanation may be that when these players stop the disc, they lose their place. I don't feel very comfortable with that explanation because, as Bob pointed out, the data is recorded in an outward spiral, and even if the laser drifted by a few tracks in or out on the spiral while the disk spun down (waiting for the bitrate to increase), it should still be able to reacquire the data stream when the disk starts spinning again (which is done with the servo feedback) and should then resume playback. Of course, if it drifted backwards during the stoppage, it would then hit the same point where it had to stop again, and it would get into an infinite loop.

None of this makes me comfortable, meaning that I don't really think we've gotten to the bottom of your problem.

I have noticed one thing on my computer that is worth noting, and may be causing your problem. I burn with Nero, and sometimes I do other things on my computer when Nero is burning. However, when I switch to Nero, sometimes I see the buffers spiraling downwards and going to zero. I have also observed the drive light on the burner turn off when this happens. Thus, the burn has been interrupted. With older burners, this meant I just made a coaster. However, with my modern burner this doesn't happen, and these discs still play. However, I wonder if they have the same compatibility? Is there a "glitch" at the point where the burner resumes? Thus, one thing I would recommend is that you check that your burner is able to burn in one continuous operation, without the light turning off.

I have just been doing quite a bit of searching on Google to see if I can find some more scientific support for Bob's theory that quick changes from min to max (or the other way) might decrease compatibility with certain players. I am in no way saying that he is wrong; I am only saying that I am not comfortable with the explanation because I just don't see why -- given how a DVD player is designed -- that it should matter. The mechanical speed variations simply cannot change quickly enough to track even the normal variations in bitrate, and the design doesn't require it to do so. Therefore, I am still looking for another explanation.

I'll let you know if I find something.

John?

"None of this makes me comfortable, meaning that I don't really think we've gotten to the bottom of your problem."

Bob too specifically uses a higher MIN - Bob's-Law of 1:4. He found that from experience.

And, just for you, John, I just repeated the original encode BUT this time just went to CBR and retained the 8mb rate. Guess what? Player, played perfectly.

So what is the problem you now think I have? I'm applying "sloppy" science? Well, spit it out and make what you say transparent. What is still sticking in your craw?

Johnmeyer,

I have seen this happen several times, but I have no data as to why. When it happens, it always happens when going from a very low bitrate to a high bitrate, but never vice versa.

Dave T2

So what is the problem you now think I have? I'm applying "sloppy" science? Well, spit it out and make what you say transparent. What is still sticking in your craw?

Golly, I have not been trying to be critical of you at all. Quite the opposite. I am totally in awe that you took the time to track this down scientifically, and your results have been really useful.

I have seen this happen several times, but I have no data as to why. When it happens, it always happens when going from a very low bitrate to a high bitrate, but never vice versa.

I guess if anything is "sticking in my craw," it is that without understanding the mechanism of what causes the problems to occur when the data goes from low to high, we may not be doing the right thing to ensure compatibility. In particular, Bob's solution is to increase the minimum bitrate so that the magnitude of the bitrate variations are reduced. This in turn seems to reduce or eliminate the compatibility problems. Fair enough. There are all sorts of things we do based on practice (such as making sure we print photos at greater than 150 dpi in order to get a decent looking print) and therefore this is useful. However, my "concern" is that it may simply be masking the real cause of the problem.

What do I mean?

Well, if you search the Internet for DVD compatibility issues, you will find that many commercial disks will not play on certain players, and a few of them can actually cause those players to cease to function (I got involved in one of these cases four years ago, and it required a factory reset to the player to get it to play again). Most of these compatibility problems have nothing to do with bitrate, and instead are tied to navigation logic, and they happen during the navigation process. However, I think some of them happen when the player transfers from one VOB to another.

Increasing the minimum bitrate is probably not going to make a huge difference in overall encode quality, but it will degrade quality to some degree (because fewer bits will be available for the fast motion parts of the encode). Thus, I really don't want to do this as a "standard practice" unless I understand why it is necessary. Otherwise, I am needlessly reducing the quality of my work.

As I said in my last post, I'll keep looking ...

It is possible that it is related to

1) A burned DVD as opposed to a commercially created DVd

2) The DVD player (maybe some models more prone than others)
and
3) The encoded file as well. How the bitrate change occurs
.

Dave T2

Here's a really good thread over in the doom9 forum, from just a few days ago:

Minimum bit rate for standards compliant DVD?

You'll see posts by a user named "dragongodz" that sounds like things that I would say. It's not me. I post under my own name in all forums.

This forum is populated by some pretty knowledgeable people, as you'll see if you read the posts. I certainly don't take any of the posts, or the thread as a whole, as conclusive, but it certainly continues to make me question the wisdom of using a minimum of 2000 kbs. One of the most telling points is the fact that commercial DVDs have bitrates that go all over the place and have low to high transitions that are just as abrupt as what we've been talking about here.

In searching, I just found this old thread:

Vegas 5 MC MPEG encoder

which brings up the fact that the Vegas 6.0d help file says:

"Write sequence display extension." Select this check box to write a sequence display extension for every GOP (group of pictures). This setting must be turned on to create valid SVCD and DVD MPEG files.

yet the default in the DVD Architect templates for this option is .

This may have absolutely nothing to do with the subject of this thread, or perhaps it does. It appears that this setting is not used by most players during decoding, but may be used by others. My point is that there may be other settings, which are not being set correctly by the default template, and which may only come into play under certain circumstances and with certain players.

That is why I mentioned the BURNED DVD vs. Commercially Created. As we all know, there is a lot of difference in burned vs. commercial, so I would expect that some of these anomalies would not appear on both formats.

Dave T2

Now John, I can understand this:

"Thus, I really don't want to do this as a "standard practice" unless I understand why it is necessary. Otherwise, I am needlessly reducing the quality of my work."

I suppose what is needed is a check list of things to do to gain the best for the least.

Keep it up John! I'm reading - still!

I guess one other piece of evidence that I should have mentioned.
The widely used and free Bitrate Calculator follows my recommendations, it suggests minimum bitrates of around 1/2 the max, well actually that's stricter than my suggestions.
Associates of mine using DVDSP have had what sounds like very similar issues and they were replicating.
Hollywood DVDs are very unlikely to unearth this kind of problem, their average bitrates are low, their content is very clean.
The Sequence Display Extension thing could well be something to investigate.

OK, well here's some info on it: http://www.geocities.com/eby_vdo/

Reading that I doubt it has any relevance.


I'm not so certain about John's concerns that setting the minimum bitrate will have an impact on overall quality either. One would certainly initialy think it would as you'd think you're wasting the byte budget, more so when doing 2 pass.

However tests Grazie and I did some time ago indicate the encoders are not that smart, even with 2 pass they only use a short sliding window to keep to the Average bitrate, they certainly don't create a file where the average is the OVERALL average. For example encode say 20 seconds of 100% black, 5 seconds of 100% noise and 20 seconds 100% black. You'll find that the black gets encoded at the minimum, the noise at the max for a brief period that ramps back to the average. Now decreasing the noise to black ratio should leave more room for the noise but not so, the file size decreases i.e. the average bitrate over the length of the file has decreased.
I'd suspect that high end encoders doing 100s of passes manage to get a better fit of average bitrate than MC at 2 pass.

Bob.