9.8Mbps averaged over what period?

[Mr Henderson]

I've been told that there is no set period or number of frames over which the 9.8Mbps bitrate limit for DVD is averaged, so that it's not possible to predict with certainty whether a spike above the limit will be a problem. All the same, I'm hoping that someone has an idea of what a typical averaging period might be - it would be very useful to know.

[Mug Funky]

i thought the buffer was for 1 second...

but it's best to not take chances. just use a lower max bitrate.

[dragongodz]

I've been told that there is no set period or number of frames over which the 9.8Mbps bitrate limit for DVD is averaged
by who exactly and why do you think they know what they are talking about ? :sly:

9.8Mbps
care to guess what the last 2 letters at the end stand for ? here i will start it off for you - 9.8Mb per secon* . i am guessing you can fill in the last letter and clearly see what the averaging period actually is. ;)

note of course thats just video max bitrate and once you start adding other streams, such as audio will need to be lowered so the total muxxed rate is not exceeded.

[Sir Didymus]

i thought the buffer was for 1 second...

Mhhh. Normally the buffers have size constraints... not time limitations... So have to disagree with the quoted statement...


but it's best to not take chances. just use a lower max bitrate.
This part, insteed is based on the common sense, so what you suggest is ok for me, and I fully agree with this...

Please consider that the (and the only) clearily stated limitation in the reference docs is that the datarate of 9.8 Mbps (for the video) and 10.08 Mbps (including video, all audio, all subpictures), should be sustainded by a standard decoder for an indefinite period of time...

@dragongodz
Hi, dragon :)
Well, I understand you may be a little bit tired of reading again questions related to the video bitrate of mpeg2 streams after the long work and discussions related to the (highly appreciated, really) developments and contributions you are giving to the community.

Stated this, nevertheless, it does not seem to me the question of Mr Henderson is so silly to be just shortly dropped out with some humoristic comments...

To say the truth his premise seems to me correct, and the answer to the question "... I'm hoping that someone has an idea of what a typical averaging period might be - it would be very useful to know..." is simply that this typical averaging period does not exist: what is limiting the peak video bitrate is the size of the STD buffer - 232 Kbytes - and the fact that it should not overflow in any circumstances...

A total bitrate higher than 10.08 Mbps CAN be accepted by a standard decoder for a period longer than 1 second - it could be significantly longer - without infringing any compliancy with the DVD specs...

[Nic]

@Sir Didymus:
Hi,
This is a question that keeps coming up and is one of much contention. You are quite right, it is supposedly the buffer that is the important part. i.e. the part that should never really overflow or underflow.

I'll tell you my story:
So we make encoders like QuEnc etc that try to obey such limits as the VBV/STD buffer. However when an encode is run through apps like bitrateviewer people tell me that the encode has spikes above 9.8MBits/sec. I tell them not to worry as the buffer is obeyed and that's all that matters and ignore their worries. Then I find out that these spikes are causing all manner of problems for DVD Players. So I limit it to the literal 9.8MBits/sec AND obey the buffer limits. Then things appear to be fine.

So this is at least why I do a literal limiting rather than just rely on buffer control.

I hope my view point of the situation helps mr henderson and any others as to why we try to be strict about the 9.8Mbits/sec limit.

-Nic

[dragongodz]

To say the truth his premise seems to me correct, and the answer to the question "... I'm hoping that someone has an idea of what a typical averaging period might be - it would be very useful to know..." is simply that this typical averaging period does not exist: what is limiting the peak video bitrate is the size of the STD buffer - 232 Kbytes - and the fact that it should not overflow in any circumstances...
sorry but i have to disagree. when a specification GIVES a time period for a maximum bitrate to be averaged over,which the dvd specs do with the /sec, then it is applicable aswell. to simply ignore it is to invite problems which has already been shown.

now what must also be remembered is the dvd specs where written some time ago and hardware then is not the same as now. so they also have a basis in dvd read speed etc etc etc. now it could easily be said that 99.9% of dvd players will play now higher than what the specs state but you can not guarentee that will always be the case. best to just stick to the literal specs and not have to worry so much.

Stated this, nevertheless, it does not seem to me the question of Mr Henderson is so silly to be just shortly dropped out with some humoristic comments...
would it have been more preferable if i had simply told him to use search and not ask things that have been discussed before ? so i gave him the answer in a whimsical way, i didnt know that was such a crime.

[Sir Didymus]

...I'll tell you my story:
So we make encoders like QuEnc etc that try to obey such limits as the VBV/STD buffer. However when an encode is run through apps like bitrateviewer people tell me that the encode has spikes above 9.8MBits/sec. I tell them not to worry as the buffer is obeyed and that's all that matters and ignore their worries. Then I find out that these spikes are causing all manner of problems for DVD Players. So I limit it to the literal 9.8MBits/sec AND obey the buffer limits. Then things appear to be fine.

So this is at least why I do a literal limiting rather than just rely on buffer control.


Hem, I read something [well, maybe something more than just "something"] about the story, by looking at some posts related to QUEnc development. Some of these posts have not being very nice, to say the thruth, and someones seemed really offensive, so first of all let me state clearily that I fully agree with your reasons and with the way it was decided to implemented the max bitrate constraint in your excellent encoder. That's all. I have to say again that the community (myself included of course) should be grateful for all what you did (and are doing) on the subject.

Said this, I am almost sure that many of the reported troubles were caused by the adoption of authoring applications [that have the responsibility of formatting the assets] that simply did not properly implement the STD buffer constraint. Among these applications there are all the ones based on the code of mplex [ifoedit as example...]. This can be easily demonstrated: there are some profiling tools available to professionals [Mpeg2 TS and DVD-Video veryfiers from Tektronix and Phylips] showing that today as example Scenarist and Muxman are properly handling the STD buffer during the muxing stage, but many other authoring applications are not.


...sorry but i have to disagree. when a specification GIVES a time period for a maximum bitrate to be averaged over,which the dvd specs do with the /sec, then it is applicable aswell. to simply ignore it is to invite problems which has already been shown.

OK. It is evident here we are in disagreement.
I can just say that it does not seem to me that specs are stating exactely the time period for the max bitrate to be averaged over. If you could point me out some references, it would be appreciated. I have to say again I read many documents, and everywhere it is stated that the datarate of 9.8 Mbps (for the video) and 10.08 Mbps (including video, all audio, all subpictures), should be sustainded by a standard decoder for an indefinite period of time... My position is that the simple value of the bitrate is not giving any indication about the time over wich the measure is taken...


would it have been more preferable if i had simply told him to use search and not ask things that have been discussed before ? ...i didnt know that was such a crime.


Of course you're right... it's not a crime...
I just felt it was maybe not correct just to close in a whimsical manner an argument that is debatable (and maybe it is so debatable that in the past the discussion led to flames)... I's just a personal opinion (so it is maybe not relevant) but maybe some reference to "storic posts" would have been really much more appreciated...

SD

[Guest]

when a specification GIVES a time period for a maximum bitrate to be averaged over, which the dvd specs do with the /sec If I measure someone's time to swim 100 metres as 48 seconds, I don't state the speed as '100 metres per 48 seconds'! I state it as 2.083 metres per second.

My point is that just because the base time unit of the rate specification is one second, that does not imply that the averaging period is one second. It just means that it is the base unit conventionally used to state the rate.

Specifications are often incomplete/ambiguous. This appears to be such a case.

[dragongodz]

Specifications are often incomplete/ambiguous. This appears to be such a case.
possibly so but then you have to take in actual experience to make a judgement upon what is both best and safest to use. yes it would be nice to have the full specs and see exactly what they say but since none of us appear to we can only go on what works and what doesnt.
in this case, as Nic has already said, following the literal meaning provides the least real life problems.

Some of these posts have not being very nice, to say the thruth, and someones seemed really offensive
and you guys didnt even get to see some of the language used or things said in PM's. :D
but lets not go in to that.

I am almost sure that many of the reported troubles were caused by the adoption of authoring applications [that have the responsibility of formatting the assets] that simply did not properly implement the STD buffer constraint.
can you guarentee that is always the case though ?

[Bodysurf]

I've been told that there is no set period or number of frames over which the 9.8Mbps bitrate limit for DVD is averaged, so that it's not possible to predict with certainty whether a spike above the limit will be a problem. All the same, I'm hoping that someone has an idea of what a typical averaging period might be - it would be very useful to know.
Also, it is important to remember with standalone DVD-Video players that this 9.8Mbps limit is with pressed or replicated discs only. Duplicated or burnt DVD-Video onto DVD+R need not apply. From reading articles from people far smarter than I, they say don't go higher than about 7Mbps with recordable DVDs.

If you are doing VBR MPEG-2 for replicated discs, then I would set the max at 9.8Mbps and then run a quality-based or VBR encode based on the footage length. There is hardly any footage that requires more than 9.8Mbps bitrate if you use a high-quality MPEG-2 encoder. From running bitrate viewer on commercial DVD-Videos the average range is anywhere from 4-6Mbps. I've hardly ever seen a commercial DVD even spike more than 8Mbps -- in fact, I don't if I've ever seen a commercial DVD-Video hit that high.

[Mug Funky]

@ bodysurf:

you mustn't have seen many discs then. if there's room, discs will be encoded at the maximum problem-free rate. for me that means 8500 mbps, CBR. of course, hollywood discs will have 4 hours of extras shoved onto them, so it isn't unheard of to see a feature encoded lower than 4500 kbps (this is far too low).

that number was arrived upon via trial and error - when spruce spat out an error the bitrate was lowered, likewise when a customer reports playback difficulties due to too-high bitrates the max rate was lowered again.

MPX3000 encoder cards don't even allow anything higher than 9600, even when "DVD compliant" is turned off (that's more a sound thing, where it allows AC3 rates higher than 448kbps).

[Sir Didymus]

can you guarentee that is always the case though ?

Oh, no! of course not...

I have many examples (of video assets encoded at bitrates far below 7Mbps, that autored with "wrong" applications led to STD buffer infringements and playback stutters) and no counter-examples (of video assets encoded well above 9Mbps, that authored with a "good" application - assuming the authoring application reports no errors and veryfied with a STD buffer profiler - lead to perfectly smooth playback on a large set of standalones)...

Some of the examples - in some posts related to the DVD-RB development - have been also posted in the doom9 forum...

But the guarantee you ask is simply impossible to provide...
And this is the reason, after all, I fully agree it's ok to give the suggestion to apply the "strict" interpretation.

On the other hand, when the encoder is not able to apply this "strong" limitation, IMHO this is not a disaster: when a "good" authoring application is reporting no errors, that is most probably not leading to a crap.

The most relevant case is the one of CCE. The multipass VBR encodings are very well respecting minimum and maximum bitrate indications; on the other hand in one pass VBR, constant Q, the bitrate of the encoding is easily spikeing in a relevant manner - the maximum bitrate value is simply not strictly obeyed -.

Never worried too much into these circumstances...
I say again: the important is to use an authoring application which is including a robust STD buffer model in its muxing stage, and which is able to report errors generated by STD overflows. If no errors are reported, most probably the DVD will play smooth...

Most probably, of course... :D

Cheers,
SD

[Audionut]

they say don't go higher than about 7Mbps with recordable DVDs.

Completly wrong. I set most all my dvd's to max rate of 9.3Mbps. With no problems what so ever found from playback from numerous devices.
That's from experience.


There is hardly any footage that requires more than 9.8Mbps bitrate if you use a high-quality MPEG-2 encoder. From running bitrate viewer on commercial DVD-Videos the average range is anywhere from 4-6Mbps. I've hardly ever seen a commercial DVD even spike more than 8Mbps -- in fact, I don't if I've ever seen a commercial DVD-Video hit that high.


Wrong, wrong, wrong.

With all due respect, you might want to base your opinions on actual experiance, rather than what "other" people say.

[FlashBlade]

Originally Posted by Bodysurf
There is hardly any footage that requires more than 9.8Mbps bitrate if you use a high-quality MPEG-2 encoder. From running bitrate viewer on commercial DVD-Videos the average range is anywhere from 4-6Mbps. I've hardly ever seen a commercial DVD even spike more than 8Mbps -- in fact, I don't if I've ever seen a commercial DVD-Video hit that high.

Check out here:
http://www.new.dvdbeaver.com/film/DVDReviews17/naked_dvd_review.htm
Here:
http://www.new.dvdbeaver.com/film/DVDReviews11/f_for_fake_.htm
And here:
http://www.new.dvdbeaver.com/film/DVDReviews5/videodrome.htm

I guess it really depends of the DVD production company.

[Mug Funky]

CBR encodes will render bitrate scans less useful though... some would say inadmissible as evidence of quality.

remember that commecial DVDs use CBR when there's room. simply because:

a) it's 1-pass and maximum quality, so if there's room on the disc, do it :). 1-pass is a huge huge timesaver when you're talking about the sheer number of releases some places do (my work does around 50 per month, and increasing all the time).

b) the 1-pass ratecontrol on some encoder cards is not all that good, usually CBR is a better bet, and 2-pass VBR when bitrate is less than 7000 or so.

now bitrate scans will not take padding into account when they do their thing. a 8500 kbps encode could have 5000 kbps of actual picture and 3000 kbps of padding. though a decent encoder will use all the bits it can, a clean enough source will easily "saturate" before the encoder has given it the full 8500 kbps.

this means when comparing bitrates on commercial DVDs, you may rate an 8500 DVD as "better" than a 5000 one, when all things considered they're exactly the same.

a fun thing to do in bitrateview is scan something CBR and look for the bits where the bitrate curve is completely flat (rather than oscillating about the CBR rate). these are the bits where the encoder is saturated and has to use lots of padding. you'll also see the quantizers are pegged at 1 for long periods.

[edit] btw, the criterion stuff is pretty good - good transfers in particular, but those encodes are average for high-budget titles. things would be different if these weren't 2-disc sets :)

[Bodysurf]

Originally Posted by Bodysurf
they say don't go higher than about 7Mbps with recordable DVDs.

Completly wrong.
No, it's not completely wrong that that is what "they say":

http://www.customflix.com/Special/AuthoringNightmares/03/BitsAndBytes.jsp

[...]

In a similar vein, DVD-R and DVD+R media is subtly different from replicated media, so some players may have a harder time playing duplicated discs. By sticking to an even lower maximum bitrate of 6.5 mbps, you're giving the player the chance to re-read some sectors if needed without interrupting the video. This provides similar benefits for scratched or dirty discs, making them a bit more likely to continue playing correctly.

[...]

Procoder's manual says something similar.

http://www.signvideo.com/bt-rts.htm

[...]

While a calculator will show you the maximum bitrate you should use, it's often best to use a lower bitrate and generally-speaking, when recording to DVD-R/RW or DVD+R/RW you should keep the video bitrate below 7Mbps even if the calculator shows that you can use a higher rate. Some experts on DVD production even suggest keeping the maximum MPEG-2 bitrate at 6Mbps.

[...]

http://www.hellmanproduction.com/DVD_101/dvd-encoding.php (this place says 8Mb)

[...]

Let's say your video is only 15 minutes long, and you are thinking about encoding it at the maximum bit rate. Should you do it? The answer is NO. The maximum bit rate is not necessarily better. We suggest encoding at no higher than 8 megabits per second. Certain DVD players might not be able to handle videos that are encoded with too high of a bit rate. So higher is certainly not better.

[...]

http://72.14.207.104/search?q=cache:7jWTESuOjpQJ:www.planetoftunes.com/dvd/encodev.html+maximum+bitrate+dvd+commercial&hl=en&gl=us&ct=clnk&cd=3

[...]

The MPEG-2 codec allows for encoding between 1Mbps and 9.8Mbps. In practice 8Mbps is the maximum bit rate you should use, for 2 reasons ...

1. You need to allow some bandwidth for audio and subtitles
2. Some DVD-video players will struggle to decode bit rates above 8Mbps

To recap ...

1Mbps = minimum data rate allowed by DVD specification

9.8Mbps = maximum data rate allowed by DVD specification

8Mbps = maximum data rate you should use (to allow for poorly specified DVD players

[...]

http://www.creationtrek.com/DVD.htm

[...]

I have a friend who authors full-time on a Mac with DVD-Studio pro, and a $100,000+ Sonic Solutions system. He has given me lots of general advice that seems to be true, no matter what system you use, for ultimate playback compatibility.

1: He claims, for set-top players, a maximum bitrate of 7 seems to take care of almost all players.

[..]

I've read articles in DV magazine and EMedia that state the same thing.

I set most all my dvd's to max rate of 9.3Mbps. With no problems what so ever found from playback from numerous devices.
That's from experience.
Other people's experience differ from yours.

Wrong, wrong, wrong.

With all due respect, you might want to base your opinions on actual experiance, rather than what "other" people say.
I choose to not reinvent the wheel.

My time is too valuable for me to experiment to see what the max bitrate I can use that will work on a wide variety of players, so I choose to listen to the experience and advice of people/places I consider to be experts in the field.

Please don't be offended if I choose to follow their advice rather than that which you give.

[Bodysurf]

Originally posted by Bodysurf
From running bitrate viewer on commercial DVD-Videos the average range is anywhere from 4-6Mbps. I've hardly ever seen a commercial DVD even spike more than 8Mbps -- in fact, I don't if I've ever seen a commercial DVD-Video hit that high.

you mustn't have seen many discs then. if there's room, discs will be encoded at the maximum problem-free rate. for me that means 8500 mbps, CBR. of course, hollywood discs will have 4 hours of extras shoved onto them, so it isn't unheard of to see a feature encoded lower than 4500 kbps (this is far too low).

that number was arrived upon via trial and error - when spruce spat out an error the bitrate was lowered, likewise when a customer reports playback difficulties due to too-high bitrates the max rate was lowered again.

http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=8309&PageNum=2

[...]

Hollywood movies, by contrast, have an average bit rate of around 3-5Mbps.

[...]

http://www.fact.co.uk/main/services/mites/dvd/faqs

[...]

Most commercial feature film DVDs are encoded at a bitrate of 4.5 - 6 Megabits per second.

[...]

http://72.14.207.104/search?q=cache:7jWTESuOjpQJ:www.planetoftunes.com/dvd/encodev.html+maximum+bitrate+dvd+commercial&hl=en&gl=us&ct=clnk&cd=3

[...]

5.5 - 6.5Mbps = typical commercial DVD data rates

[...]

Regardless of what some people may think, I am not just pulling these numbers out of the air.

[Bodysurf]

CBR encodes will render bitrate scans less useful though... some would say inadmissible as evidence of quality.

remember that commecial DVDs use CBR when there's room. simply because:

a) it's 1-pass and maximum quality, so if there's room on the disc, do it :).
I am not saying you are wrong, but your experience completely flies in the face of my experience.

First of all, I have probably a hundred commerical DVDs and I am not aware of even one of them that is CBR encoded. I don't doubt their existance, but I would expect them to be quite rare. Observing their bitrate using PowerDVD and bitrate viewer, they tend to on average to fluctuate between 4-6Mb/s and occasionally spike higher and lower than that.

Secondly, I never encode CBR even if there is plenty of room, I encode a 1 pass VBR quality-based encode at maximum quality. The benefit is it takes less room on the disk (so it burns/authors faster) while theoretically maintains the same quality as full bit-rate CBR and encoding at the same speed as CBR. In fact, I encoded 48 minutes of NSTC 29.97 D1 footage at max quality-based VBR MPEG-2 encode/192Kbps AC-3 audio and it took 1.76GB. I could have encoded the video at "9.3Mb/s" CBR MPEG-2 and really gained nothing, but perhaps even lost something in compatibility!

When there is a question of a 1-pass VBR max quality encode possibly being too big to fit on a SL DVD-R, then I go to regular VBR based encode and set the max/min bitrates depending on the footage length.

Finally, here's an interesting article.

http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=8309&PageNum=2

[...]

There are two modes of DVD encoding, constant bit rate (CBR), and variable bit rate (VBR). When encoding in constant bit rate mode, the level of compression difficulty or motion within the video stream is irrelevant, because the same bit rate is used throughout the entire process. So a static talking-head segment of a given video project will be compressed at the same bit rate as dynamic, high-motion scenes, which does a disservice to both and makes inefficient use of the disc's overall bit budget. Most home videos are encoded in CBR because it is quick and less complicated. (Most entry-level tools don't even include VBR encoders.) So the quality of the final product is consequently compromised. According to DVD author Richard Diercks, "No professional video should be encoded in constant bit rate (CBR), even if bandwidth is high. Our experience is that variable bit rate (VBR) always looks better."

[...]

[foxyshadis]

now bitrate scans will not take padding into account when they do their thing. a 8500 kbps encode could have 5000 kbps of actual picture and 3000 kbps of padding. though a decent encoder will use all the bits it can, a clean enough source will easily "saturate" before the encoder has given it the full 8500 kbps.
As a curiosity, do you ever use custom matrices in this case? Or would that hurt the other frames in cbr mode?

[Kika]

The problem with some players are the bad dvd drives they use. If the drive has problems to read a sector of the disc, the buffer may run out of data and this causes stuttering videos.
But in fact: all dvd players have to play videos with up to 9800mbps - that's what the standard says.

[Bodysurf]

The problem with some players are the bad dvd drives they use. If the drive has problems to read a sector of the disc, the buffer may run out of data and this causes stuttering videos.
But in fact: all dvd players have to play videos with up to 9800mbps - that's what the standard says.
With replicated or pressed discs, there is no question the above is true.

DVD-Video on duplicated, recordable DVDs should play any standalone players (that support recordable DVDs) as long as it is within the DVD standards. However, the fact of the matter is that quite a few of them do not, especially when the bitrate is too high. Some of the earliest players is fact will not play any DVDs except those that were pressed. Some of these earliest players were released before even recordable DVDs were available.

My point is that may people have found that when you are putting DVD-Video on recordable DVDs, if you go beyond the bitrates I described earlier in this thread, you increase the risk of the video not playing properly to what is considered by many to be unacceptably high. You run the risk of people saying that your DVD is defective. You run the risk of having to tell people to get a better DVD player, or that their DVD player is defective -- and then they tell you it doesn't have any problems playing anything else but yours. People that do a lot of disc replicating don't like to hear or tell people that, hence the advice given above.

I have also found that as time goes on, this is becoming less and less of an issue with modern players. If you have full control over the standalone DVD players that your audience uses and have tested these out, then you may find that you never have had a problem when burning full bitrate DVD-Videos -- great for you. Or you may just have been lucky.

Others do not have the same experience.

[dragongodz]

a couple of points

But in fact: all dvd players have to play videos with up to 9800mbps - that's what the standard says.
take that as video only though. once you add audio and/or subtitles you need to reduce that so the total muxxed combination falls under the muxxed max.

bodysurf - if you read those links you gave about lower max bitrate the reasons given are for incase of dodgy players or dodgy burnt dvds etc. as such they can be good advice for extreme newbs but is not actually realistic. its more of a "ok most of your dvds will be fine with a higher max bitrate but just incase 1 isnt set them all lower to start with" type thing. it doesnt address the issues at all but tries to hide them.

[Bodysurf]

bodysurf - if you read those links you gave about lower max bitrate the reasons given are for incase of dodgy players or dodgy burnt dvds etc. as such they can be good advice for extreme newbs but is not actually realistic. its more of a "ok most of your dvds will be fine with a higher max bitrate but just incase 1 isnt set them all lower to start with" type thing. it doesnt address the issues at all but tries to hide them.
Correct. It can be (1) flakey media with great players, (2) great media with flakey players or (3) flakey media with flakey players.

I agree that all standalone players that support recordable DVD media should and should be able to play DVD-Video burnt to DVD+R to the full specifications. But the fact of the matter is quite a number of them do not. And quite a few people who do a lot of duplicating of discs suggest, based on their experiences, to lower the bitrate to the levels listed earlier. By doing so, you lower the effect of flakey media and/or flakey players has on your duplicated DVDs working.

I mean -- think about it. If you do a lot of this stuff, do you want to tell, or potentially tell a significant percentage of your clients their players are subpar potentially over and over again? Or would you rather just encode at a lower bitrate and avoid a lot of the headache? I hear where you are coming from, but I hope you can appreciate where the people are coming from who giver this advice and I hope you can understand why they do it.

I hope I made it clear my advice was not based on a lot of personal experience in this area. I researched the subject and the general consensus I obtained was what I wrote earlier, so that is what I go by. It works well, and there hasn't been any reason or desire on my part to experiment or see if I can reproduce their results.

[Audionut]

No, it's not completely wrong that that is what "they say":


"THEY"

Ok, you continue to use the suggested settings of what "THEY" say.

and there hasn't been any reason or desire on my part to experiment or see if I can reproduce their results.

Which I guess is why you listen to what "THEY" say.

Myself, I know from personal experiance, that I have no problems with combined video/audio bitrates of 9.8MB/s.



I cannot stand when a sub-optimal standard is introduced, for the sake of compatibility with all the people who have purchased sub-optimal equipment.

For christ sake, people who buy something from an company that was made by some dude getting paid $1/day should expect problems.
And rather than tell these people that they bought a piece of shit, your certain that we should produce sub-optimal content.

[Bodysurf]

Myself, I know from personal experiance, that I have no problems with combined video/audio bitrates of 9.8MB/s.
Are "we" not getting it?

I do not doubt your personal experience, OK. I merely stated my recommendations and why I believe them:

Because it is my opinion that the general consensus of people who do this for a living have stated when they do what you do, they run into problems too often. I have also provided what they suggest as a solution.

I cannot stand when a sub-optimal standard is introduced, for the sake of compatibility with all the people who have purchased sub-optimal equipment.

For christ sake, people who buy something from an company that was made by some dude getting paid $1/day should expect problems.
I hear you loud and clear brother.

And rather than tell these people that they bought a piece of shit, your certain that we should produce sub-optimal content.
It should be obvious, but it is the opinion of the people I quoted that the pros of recommending keeping the average MPEG-2 bit rate under around 7Mb/s outweighs the cons of what you refer to as "sub-optimal content".

As far as "sub-optimal content", as I wrote in another article in this thread, the times you need an average bitrate higher than 7Mb/s is few and far between if you use a top-quality MPEG-2 encoder. I have gone through quite a few commercial DVDs and monitored the bitrate on them, and my experience is similar to what I mentioned earlier about the bitrate level on commercial DVDs.

As an exercize, pick a top quality MPEG-2 encoder and encode at the maximum CQ that it allows. Then run that through a bitrate viewer and see what the min, average, and max bitrate ends up being. Sure, I can generate footage of difficult to encode swishing water and twirling leaves on a random checkboard pattern and make something that will cause it to demand that 9.8Mb/s bitrate, but see what happens when you are using real world footage.

[Audionut]

Do not ask a question, if you don't already know the answer.;)
Star wars episode 3. Chapter 30. Fast Motion. Quant 1. Fox home Matrix.


---------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.16A beta |
---------------------------------------------

input: c:\star_wars_episo\chap 20\test.avs
output: c:\star_wars_episo\chap 20\fox.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 4348
framerate: 25.00
aspect ratio: 16:9
bitrate: NA
max. bitrate: NA
pass: 1 (Constant Quant)
constant Q: 1.000
closed gops: no
VBV check: no
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 0
time code: 0 0 0 0
CPU: SSE2
matrix: CUSTOM

--------------------
| source stats |
--------------------

nr. of frames in source: 5348
width*height: 720*576
fps: 25.00
nr. of frames to encode: 4348
frames to encode: 1 - 4348

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:02:43 (163 s)
average fps: 26.7

------------------
| encoding stats |
------------------

total encoding time: 0:02:43 (163 s)

intra matrix used
8 8 9 9 10 10 11 11
8 9 9 10 10 11 11 12
9 9 10 10 11 11 12 12
9 10 10 11 11 12 13 13
10 10 11 11 12 13 13 14
10 11 11 12 13 13 14 15
11 11 12 13 13 14 15 15
11 12 13 13 14 15 15 16

non-intra matrix used
8 8 9 9 10 10 11 11
8 9 9 10 10 11 11 12
9 9 10 10 11 11 12 12
9 10 10 11 11 12 13 13
10 10 11 11 12 13 13 14
10 11 11 12 13 13 14 15
11 11 12 13 13 14 15 15
11 12 13 13 14 15 15 16

nr. of gops: 325
nr. of frames: 4348
nr. of I-frames: 325
nr. of P-frames: 1430
nr. of B-frames: 2593
average quant (non linear): 1.000
VBV underflows detected: disabled
VBV underflows fixed: disabled
minimum bitrate: 23331
maximum bitrate: 56304
average bitrate: 39797


Let's try something that I assume is more along the lines of what you "meant".

Chapter 39. Low Motion. Mpeg Matrix. Quant 2.


---------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.16A beta |
---------------------------------------------

input: c:\star_wars_episo\video_ts\test.avs
output: c:\star_wars_episo\video_ts\mpeg.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 3840
framerate: 25.00
aspect ratio: 16:9
bitrate: NA
max. bitrate: NA
pass: 1 (Constant Quant)
constant Q: 2.000
closed gops: no
VBV check: no
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 0
time code: 0 0 0 0
CPU: SSE2
matrix: MPEG

--------------------
| source stats |
--------------------

nr. of frames in source: 3840
width*height: 720*576
fps: 25.00
nr. of frames to encode: 3840
frames to encode: 1 - 3840

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:01:46 (106 s)
average fps: 36.2

------------------
| encoding stats |
------------------

total encoding time: 0:01:46 (106 s)

intra matrix used
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83

non-intra matrix used
16 17 18 19 20 21 22 23
17 18 19 20 21 22 23 24
18 19 20 21 22 23 24 25
19 20 21 22 23 24 26 27
20 21 22 23 25 26 27 28
21 22 23 24 26 27 28 30
22 23 24 26 27 28 30 31
23 24 25 27 28 30 31 33

nr. of gops: 288
nr. of frames: 3840
nr. of I-frames: 288
nr. of P-frames: 1168
nr. of B-frames: 2384
average quant (non linear): 2.000
VBV underflows detected: disabled
VBV underflows fixed: disabled
minimum bitrate: 4259
maximum bitrate: 16170
average bitrate: 6845

Chapter 30. Fast Motion, Mpeg Matrix. Quant 2.


---------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.16A beta |
---------------------------------------------

input: c:\star_wars_episo\chap 20\test.avs
output: c:\star_wars_episo\chap 20\mpeg.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 4348
framerate: 25.00
aspect ratio: 16:9
bitrate: NA
max. bitrate: NA
pass: 1 (Constant Quant)
constant Q: 2.000
closed gops: no
VBV check: no
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 0
time code: 0 0 0 0
CPU: SSE2
matrix: MPEG

--------------------
| source stats |
--------------------

nr. of frames in source: 5348
width*height: 720*576
fps: 25.00
nr. of frames to encode: 4348
frames to encode: 1 - 4348

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:02:10 (130 s)
average fps: 33.4

------------------
| encoding stats |
------------------

total encoding time: 0:02:10 (130 s)

intra matrix used
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83

non-intra matrix used
16 17 18 19 20 21 22 23
17 18 19 20 21 22 23 24
18 19 20 21 22 23 24 25
19 20 21 22 23 24 26 27
20 21 22 23 25 26 27 28
21 22 23 24 26 27 28 30
22 23 24 26 27 28 30 31
23 24 25 27 28 30 31 33

nr. of gops: 325
nr. of frames: 4348
nr. of I-frames: 325
nr. of P-frames: 1430
nr. of B-frames: 2593
average quant (non linear): 2.000
VBV underflows detected: disabled
VBV underflows fixed: disabled
minimum bitrate: 4862
maximum bitrate: 19968
average bitrate: 10831

As you can clearly see. Even the low motion stuff needs an average of 6.854MB/s.
The average Bitrate of both clips is 8.838MB/s.
I do these types of "excersize's" all the time. I could have told you that it is very easy to go way past 9.8MB/s.
But here's the proof.

[Audionut]

In a similar vein, DVD-R and DVD+R media is subtly different from replicated media, so some players may have a harder time playing duplicated discs. By sticking to an even lower maximum bitrate of 6.5 mbps, you're giving the player the chance to re-read some sectors if needed without interrupting the video. This provides similar benefits for scratched or dirty discs, making them a bit more likely to continue playing correctly.


To be able to stay under your "THEY SAY" maximum bitrate's, requires a constant quant 7 encode of the chapter 30 scene.


---------------------------------------------
| HCbatch - MPEG2 encoder - rel. 0.16A beta |
---------------------------------------------

input: c:\star_wars_episo\chap 20\test.avs
output: c:\star_wars_episo\chap 20\test.m2v

--------------------
| encoder settings |
--------------------

profile: BEST
frames: 1 4348
framerate: 25.00
aspect ratio: 16:9
bitrate: NA
max. bitrate: NA
pass: 1 (Constant Quant)
constant Q: 7.000
closed gops: no
VBV check: no
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 0
time code: 0 0 0 0
CPU: SSE2
matrix: MPEG

--------------------
| source stats |
--------------------

nr. of frames in source: 5348
width*height: 720*576
fps: 25.00
nr. of frames to encode: 4348
frames to encode: 1 - 4348

---------------------
| encoding - pass 1 |
---------------------

pass 1 encoding time: 0:01:56 (116 s)
average fps: 37.5

------------------
| encoding stats |
------------------

total encoding time: 0:01:56 (116 s)

intra matrix used
8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83

non-intra matrix used
16 17 18 19 20 21 22 23
17 18 19 20 21 22 23 24
18 19 20 21 22 23 24 25
19 20 21 22 23 24 26 27
20 21 22 23 25 26 27 28
21 22 23 24 26 27 28 30
22 23 24 26 27 28 30 31
23 24 25 27 28 30 31 33

nr. of gops: 325
nr. of frames: 4348
nr. of I-frames: 325
nr. of P-frames: 1430
nr. of B-frames: 2593
average quant (non linear): 7.000
VBV underflows detected: disabled
VBV underflows fixed: disabled
minimum bitrate: 1172
maximum bitrate: 6676
average bitrate: 3162

Note that the max bitrate still peaked over the recommened 6-6.5MB/s that 2 of these "experts" recommended.
I also realize that a 2 pass encode would produce better quality results over all, However, there would still be scenes that have high quants (7 or more) to compansate for the maximum bitrate limit.
The encode at quant 7, looks terrible.

[dragongodz]

another little clarification.

it is my opinion that the general consensus of people who do this for a living
of course you do realise Mug Funky actually IS one of the people that do it for a living. i have retail dvds with Mugs real name on them and one of his conversions is even being used by an American company. :)

you will also see he specifically mentioned hollywood movies usually have heaps of extras so a lower average bitrate. so he didnt actually disagree with you for that. however he said if there was room then they can sometimes simply do 1 pass CBR and even then you have to consider that at least some of that is going to be padding etc. but his professional encodes for such plenty of room dvds has been he can encode 8500 CBR problem free. this is his professional experience with encoding for retail dvds and feedback from customers etc.

[Bodysurf]

My final word on the subject:

This is like Coke vs Pepsi, Intel vs AMD, Blu-Ray vs HD-DVD, AC-3 vs DTS, UNiX vs Windows, Intelligent Design vs Evolution, being a Democrat vs a Republican, etc.

There are smart people on both sides of the issue who have differing opinions. You "know" you're right and others "know" they're right.

I've given what I believe to be good reasons why I do what I do, and you give good reasons too. I have little doubt that I could take the footage that was encoded two posts earlier in this thread that shot out those insanely high bitrates, run them through Procoder or a Sonic SD-2000 hardware encoder at the bitrates I was talking about and produce results that are indistinguishable under real world situations to 99% of the people out there. But we'll never know because I don't have the motivation to do so.

All I would suggest is that people with concerns either follow my recommendations, other people's recommendations, or do whatever they want and see what ends up working for them.

:D

[Mug Funky]

But we'll never know because I don't have the motivation to do so.

that's too bad... i've got a few samples that are almost impossible to get a good result under 8500 kbps. i even increased the max bitrate to 8800 and hoped for the best on this one, as well as doing endless segment re-encodes and using some outlandish (but DVD compliant) GOP structures, matrices, avisynth filters and even different encoders. ever get a master that is just so unbelievably good that no encoder can do it justice? it's worth it though - the sort of encode that makes you wish you had a better TV.

[edit]

btw, the encode i refer to (max 8800, avg 8100 or so) was burnt to a DVD+R DL as a test before replication, and played perfectly on my craptastic hyundai. even the layer-break wasn't distracting which is beyond rare for a burn.

i don't envy anyone who tries to run this one through DVD shrink et al, because it'll suffer quite a bit.