Authored DVD exceeds DVD spec bitrate - advice needed.

[outerspacerace]

Apologies in advance for not being able to post specifics, I'm at work and will endeavor to later if required.

My problem is that two DVD's I authored some time ago (when I was less knowledgeable on such issues) show bitrates that exceed the maximum for the DVD spec when checked with Teco bitrate viewer.

I tested them becuase I had a feeling I may have pushed the limit.

From memory I rendered from Vegas 7 using a variable video bitrate of either 9,200kbps or 9,800kps as the maximum value, in both cases the audio bitrate is definately 256kbps. Two pass rendering was done.

The spikes when I checked the VOB's from the video_ts folder on my pc vary from just over 10,000kbps to around 12,000kbps and even one around 14,000kbps *gulp*.

I'm wanting opinions on what I can do to correct this so the DVD's are within spec and still look great?

Normally I'd just re-render but the source tapes/files don't even exist anymore.

Should I be looking at ripping & transcoding the streams somehow? Something else, what would you suggest?

One of the DVD's has been handed around to relatives/friends and I can count at least 9 set top players and 4 pc's that played it without so much as a hiccup.

The other (with the larger spikes) works fine also on a few different players, only exhibiting slight artifacts (like macro blocking/screen tearing) on a Yamaha player just after some chapter changes.

Any advice is appreciated as I haven't been able to find anything to help me out so far.

Cheers.

[manono]

Hi-

My advice is to forget about it. Bitrate viewer can't be trusted anyway. Whatever you used to author it should have at least warned you, if not actually aborted, if you had gone over the limit. Your settings (even 9800 video max with 256 audio) are OK, and if your encoder respects the max bitrates set, then I don't see what's the problem.

The artifacts you describe have nothing to do with exceeding the max allowable bitrates. If you really do have some parts that go over the limit, you'll see definite stutters at those places while playing the DVD.

If you'd like to do a test reauthor with an authoring program that will warn you if you go over the limit, then demux, followed by a reauthor using Muxman.

[outerspacerace]

Hi manono,

Thanks for your swift and reassuring reply

Forgot to say I used DVD Lab Pro 1.53 to author & I'm sure it would have warned me (or aborted) as you suggested.

It's big on DVD compliance & presents those pop up warnings for most other things like open GOP's etc. Not only that it shows the average bitrate in the assets area too, which I'm sure I would have noticed. Even though I knew less then, I had a basic idea about 9,800kbps video plus audio being the absolute maximum to use...

Whilst we're on it, I just tried to render some DV files over the limits mentioned to test DVD Lab warnings with but here's the thing - Vegas itself won't let me change the settings to any higher than what I mentioned! I tried a few other rendering templates to check and yup, it automatically changes the figures back to the limit once you click onto another tab in the template. That's a pretty cool feature in itself as far as DVD creation is concerned.

I also remembered making one DVD well before the two I mentioned with what would be the same settings (a wedding for a friend) and it was sent all over the world, playing in countless players without a problem from what I understand.

Though i doubt I'd need it now, I will have to try Muxman, sounds like a handy tool to have and a good final word on the subject.

So thanks again, though for the sake of knowing... If someone did want to reduce a spike, or even lower the bitrate of an authored DVD (maybe to re-author and fit more on) what would be the best method to do so?

[tinker]

If you want to use VBR setting, set your encoder to between 6-8000 kbs.
There will be always some spikes in video using variable bit rate.
If you want to be sure, use CBR (constant bit rate), but resulting file will be larger, no spikes thou.
DVD Lab will not give you any warning, it just state average bit rate, that is all.

[pepegot1]

ReAuthor with VideoRedo and change bitrate to 6000-8000. Could even modify audio, if needs be.

[jman98]

The Teco bitrate viewer seems reliable to me, but perhaps manono has some evidence to share above just not liking it.

Anway, I know for a fact that many DVD authoring programs will not fully implement the DVD specs. For example, some refuse to allow you to make a DVD from MPEG-1 video although such is possible according to the spec. DVD Lab goes the other way in letting you do things that violate the spec, such as using SVCD resolution video. That's not necessarily a bad thing. Perhaps the source video does spike above 10000 for a few frames but DVD Lab allowed it. Some encoders are better than others at staying within the boundaries you set for VBR encoding.

Anyway, you gain nothing by using such high bit rates. Whether your maximum is 9200 or 9800 I am sure you won't be able to tell the difference.

[outerspacerace]

jman98 - you're quite right about the minimal difference, I know that now but not over 12 months ago when I made the discs in question is all.

pepegot1 - I don't have VideoRedo but that's an MPEG-2 cutter mainly isn't it? If I simply change the bitrate, would it encode it again (surely bad) or transcode code it similar to say, DVDShrink? I've always used Womble to edit MPEG-2 thus far.

[jman98]

pepegot1 - I don't have VideoRedo but that's an MPEG-2 cutter mainly isn't it? If I simply change the bitrate, would it encode it again (surely bad) or transcode code it similar to say, DVDShrink? I've always used Womble to edit MPEG-2 thus far.

Yes, if you change the bit rate in VideoReDo it will encode it again. I'm not sure why that was suggested.

Anyway, I (hopefully) politely suggest that you not say that you are using "Womble", which is not a product but the name of a company that now has multiple products. If you are using MPEGVCR, then you can stick to that. I have both MPEGVCR and VideoReDo and I prefer MPEGVCR for dealing with standard definition video, but VideoReDo is superior for editing high def MPEG-2.

[manono]

The Teco bitrate viewer seems reliable to me, but perhaps manono has some evidence to share above just not liking it.

I didn't say I don't like it. I use it every day, use it for a number of purposes, and like it quite a bit. I said it was unreliable. Here's a screen from Bitrate Viewer showing a bitrate spike which, if it was true, would show a bitrate outside the DVD spec. But it authored just fine in Muxman, and is a false reading:

[SLK001]

I discussed this inaccuracy of BRV with the TECO people years ago. They were going to address it in their "next" release. They have yet to release their "next" release. The latest release is 1.5.054 and it was released back in 2002.

They also have problems with video streams that are encoded at 23.976fps, but pulled down to 29.97fps.

Since I only encode using CCE, I use that program to assess the bitrate.

Also, your DVD authoring program should throw an ERROR when the bitrate exceeds 9,800Kbps, since it is a true error.

[outerspacerace]

I use Womble MPEG Video Wizard & understand they make a few products, it was just late in the land down under when I posted is all

Forgot to say folks, one of the DVD's mentioned originally is a compilation put together over time. I found an early version with about half the content which I authored using TMPG DVD Author.

That disc played fine on the few players I checked on & it was those very streams I ripped & used in DVD Lab for the final author.

Basically, I'm still curious to do a test re-author with muxman (manono convinced me of it's usefulness!) though I tend to think manono's right & that the discs are fine, Vegas served me well & bitrate viewer's results should be taken with a grain of salt.

Still wondering about what the best method is to slightly lower the bitrate of an MPEG-2 stream whilst retaining good quality is though... hopefully won't have to do it however!

Any ideas?

[manono]

Still wondering about what the best method is to slightly lower the bitrate of an MPEG-2 stream whilst retaining good quality is though... hopefully won't have to do it however!

Any ideas?

You said you no longer have the source videos, so anything else you do will be inferior to reencoding from the source.

Unless I'm missing something, the obvious answer is that you reencode.

[outerspacerace]

Yeah, I don't have the source files & would have to re-encode. This is almost hypothetical now & for the sake of my curiosity more than anything else.

The idea of MPEG-2 getting further compressed is a turn off in itself agreed, was just wondering what method would get the best results.

I'm guessing 2nd time around the key would be to do a CBR render rather than VBR two pass at somewhere around 8,800kpbs?

I don't mind that it's not as good as if I could render from the source, am interested more so whether ugly MPEG-2 artifacts begin to appear. There's next to none in the original streams I have... maybe I'll have to give it a whirl on the weekend and find out first hand.

I guess it's not much different from people who use DVD based camcorders and don't know about smart rendering products like Womble MPEG Video Wizard. They would be going through the MPEG-2 wringer twice also.

[RickA]

Greets,

quote "I'm guessing 2nd time around the key would be to do a CBR render rather than VBR two pass at somewhere around 8,800kpbs?"

You really do not have to go CBR just in an attempt to avoid this. Simply lower your VBR from around 8,800kb/s where you had it about to 8,000kb/s or so. That should give you plenty of bitrate for your video along with ample headroom for audio and authoring.

I have backed up a few commercial discs that were slightly beyond DVD spec in bitrate as reported by TDA. Forget by how much over it said they were, not a whole lot. I clicked Ignore and things went fine. This happened while splitting a dvd9 in half to two dvd5's. A couple of M*A*S*H series discs if I recall. Backed them up for my Dad. Could have been an error on their production end. Or even been mixed high on purpose to prevent dubbing, who knows. He has the source and the backups so I cannot readily recheck the numbers.

Cheers,
Rick

[outerspacerace]

BTW Manono,

MuxMan had no problem whatsoever with my files.

I didn't know where/how to read the log files like it suggested after the successful output though... anyway the point is my files must all be A-OK

Cheers again for the suggestion!

[manono]

There's a load off your mind, eh? The Muxman log is found in the root of the C drive. There's lots of information in one of them.

[tomlee59]

Yeah, I don't have the source files & would have to re-encode. This is almost hypothetical now & for the sake of my curiosity more than anything else.

The idea of MPEG-2 getting further compressed is a turn off in itself agreed, was just wondering what method would get the best results.

I'm guessing 2nd time around the key would be to do a CBR render rather than VBR two pass at somewhere around 8,800kpbs?

I don't mind that it's not as good as if I could render from the source, am interested more so whether ugly MPEG-2 artifacts begin to appear. There's next to none in the original streams I have... maybe I'll have to give it a whirl on the weekend and find out first hand.

I guess it's not much different from people who use DVD based camcorders and don't know about smart rendering products like Womble MPEG Video Wizard. They would be going through the MPEG-2 wringer twice also.

There's no need to re-encode; just re-quantise instead (very important difference between the two!). Your mpeg2 can be shrunk further by effectively (and simply) discarding some small fraction of the coefficients it has already generated during your original encode. The resulting quality loss will be minimal, and in fact the final result will be very close to what you would have achieved in a single encode with a smaller target size in the first place. If you try to re-encode, the quality loss will be far worse, and it will also take a lot longer. Requantising is a very fast operation, and it is generally what's under the hood of tools like DVD Shrink, as well as ffmpegx's shrink-to-fit tool. And if you're Unix-knowledgeable, there are free utilities for doing this as well ("vamps" is but one of several).

[outerspacerace]

Cheers Manono,

How embarrassing not knowing the logs were there. Many program logs end up there I know, again I'm using tiredness as an excuse lol

Tom,

Guess I kind of was on the right track in my original post. I was just incorrectly calling the process transcoding, rather than requantising...

So cheers for clarifying things for me, this thread has been ultra informative.

[lordsmurf]

. The resulting quality loss will be minimal, .

When concerning homemade video, this statement is often untrue. Quality loss tends to be pretty drastic on non-studio video. The source is not good enough to suffer from this brutal re-compression method.

[manono]

And since the supposed problem was max bitrate exceeding the specs, rather than the DVDs being oversized, I'm not sure I understand how transcoding would help in any event. And I agree with lordsmurf that for homemade stuff transcoding is a poorer solution than is reencoding. There's just no "overhead" for shrinking without winding up with noticeably lower quality. Even in outerspacerace's first post he noted artifacts caused probably by not having a high enough average bitrate, a problem that'll be made worse by transcoding to a smaller size.

[Nelson37]

Having run into this problem, I can definitely say that Shrink will not fix bitrate spikes. Failed 3 out of three.

Not sure of the accuracy of Bitrate Viewer, But where it showed spikes, GfD refused to author. Successfully authored disks showed no such spikes in the source. I tested all failures, but only a few good disks.

Encoding programs may vary significantly from user-specified bitrates, beware of version upgrades changing this!

[tomlee59]

. The resulting quality loss will be minimal, .

When concerning homemade video, this statement is often untrue. Quality loss tends to be pretty drastic on non-studio video. The source is not good enough to suffer from this brutal re-compression method.

"Brutality" is a function of how much reduction in size you're seeking. It sounded from the OP that the reduction sought is not 2x, but more like 10%. If that is correct, then the resulting quality loss will indeed be minimal. If he's seeking substantially more than that, then of course results will degrade. There's no magic.

Then there is the question of what the alternatives are. When compared to (re-)transcoding to achieve a given filesize, requantising is clearly the better option.

[outerspacerace]

Yeah Tom, 10% was about the amount I had in mind in the first post.

I was just going to try using Shrink to do that for me until I decided to join up and post here... now look at the can of worms before us!

My video would still have looked quite good I think. Though far from "studio" shooting and encoding, it is from a good 3CCD DV camera, shot in decent light and held very steady for the most part.

For the record I'm not going to try either methods as I think my discs are ok now, they seem to have survived enough programs and real world players to convince me of that.

However, I do know I don't need to push things so much with the variable bitrates from here on in.

It's a bit off topic but does anyone have any favourite bitrate settings to use from Vegas?

You know, just for next time

[lordsmurf]

On an unclean source, even "just 10%" can be pretty brutal.

[tomlee59]

Unless you're already running at low bitrates (which is manifestly not the case here), a 10% additional truncation in DCT coefficients will barely move the PSNR needle, and I doubt you'd really be able to see the difference. I think you are imagining a situation where the source is crappy AND encoded at low bitrates. This is not the scenario outlined by the OP.

[outerspacerace]

Manono,

Forgot to ask does muxman warn before authoring if there are bitrate and other problems, or did you mean just by showing info in the log files?

Cheers.

[manono]

Manono,

Forgot to ask does muxman warn before authoring if there are bitrate and other problems, or did you mean just by showing info in the log files?

It can't warn before authoring if the bitrate exceeds the specs somewhere along the line as there's no way for it to know. It can only learn as it's authoring. With a few overages, it may complete the authoring and warn onscreen and in the log when done. With a lot of them (half a dozen or more, maybe?), it'll abort with an error and you can learn more in the log.

You can even set your bitrate for, say, 12000 in the encoder, but if it doesn't actually go over the max 9800 (or less, depending on audio bitrate, subs, and overhead), you may even get a good mux out of it. May, I say.

If the asset isn't compliant to begin with (wrong framerate or resolution, for example), it won't even load it and will error out.

If it completes OK, and the little box saying it finished doesn't say anything bad, you've had a good mux.

[outerspacerace]

I wonder whether Blu-ray players are more forgiving of DVD bitrate spikes seeing as they handle much higher bitrates on Blu-ray encoded titles? (And yes I know the streams are different formats etc etc)

Or is the DVD playback functionality a firmware setting that sets the limit to that of the DVD spec?

Not that I'll be pushing it but it would be interesting to know.

Also, bitrate viewer is crazy. It doesn't even always give the same results when the same analyzing stream. I've closed and re-opened the program numerous times to check it out. Sometimes it shows a spike on the file other times not.

It's handy as a rough guide but gees... I'll be trusting Vegas more so from now on.