Undersizing using 2.70.2.0

[Boulder]

If that is the case here, I'd use LimitedSharpen ;)

[Mr. Monte]

Unfortunately if it undersizes the problem would have to be within CCE, which is out of my control.

Except maybe the OPV feature ... correct?

You may need to tweak the setting for this correct?

[jdobbs]

You can always tweak OPV -- but it is inherently inaccurate, so if you tweak it in the positive direction a little there is always a chance that on another disc is will be slightly over. I'm thinking of adding a "correction" mechanism that will use ReJig to bring it into line if it goes a little over.

[HKT3020_1]

For the Toy Story example above which audio tracks are being kept? I'm intrigued why the available size for video is so high.

- Reduction Level for DVD-5: 92.4%
- Overall Bitrate : 8,304/6,643Kbs
- Space for Video : 3,924,190KB
- HIGH/LOW/TYPICAL Bitrates: 6,926/1,864/6,643 Kbs

Reducing 3,924,190 by 92.4% is not far off your final output size if there were no audio tracks.

The DDEX 5.1 track was what I kept, leaving out the English 5.1 DTS, English, French and Spanish 2.0. I suppose another alternative is to edit the DVD and keep the DD English 2.0 track and have the video untouched. I doubt my younger sibling will notice the difference between DDEX & DD 2.0. :D

[TECK]

With CCE SP 2.70.02.04 Trial, there is no undersize. I just did the movie Batman Begins (NTSC) today... it came perfect.
I used:
CCE=3
CCETargetSectors=2260000

in Rebuilder.ini file. The movie came out at 4696MB, just 10MB under the limit.
All the movies I do with the CCETargetSectors value listed above come close to this, never over 4706MB.

Here it is the .ini file for the Batman Begins movie:
[Options]
CCE=3
CCETargetSectors=2260000
SkinVersion=10
Skin=Teck Original
AudioDub=0
LogFile=0
QuEncHQ=0
QuEncodeType=0
iDCT=3
GOP=0
DCPrec=0
MainMatrix=Encoder Default
LowMatrix=Same as Main Feature
VLowMatrix=Same as Main Feature
ExtraMatrix=Same as Main Feature
HC_Quality=1
ProCoder_Quality=4
ReduceOpt=0
DVD_Label=BATMAN_BEGINS
DVD_Name=BATMAN_BEGINS.ISO
MovieOnly=1
HalfD1=00
Convert_16_9=00
DisableInterlace=00
ConvertToYUY2=1
ITU_Aspect=1
EncoderMinimized=1
RemoveDC=1
OneClick=1
NoWarn=1
AdditionalOutput=1
ISO_Output=1
ISO_Delete_Option=0
Decrypter_Write=0
Delete_Image_Option=0
Completed=1
[CCEOptions]
VBR_bias=25
Quality_prec=16
eclPasses=2
[Audio]
Selected=1
Remapping=
[Subpictures]
Selected=1
EDIT: One detail I forgot to mention, I never got an undersize issue with any CCE version.

[TECK]

HKT3020_1, something is definitely wrong in your configuration. A movie like that done in 69min??? My Batman took 120min on a 3.2 HT processor.
Are you running a farm? Curious... If yes, lucky you. :)

[HKT3020_1]

HKT3020_1, something is definitely wrong in your configuration. A movie like that done in 69min??? My Batman took 120min on a 3.2 HT processor.
Are you running a farm? Curious... If yes, lucky you. :)

Like you I'm also no a 3.2 P4 machine and not running anything else with DVD-RB, I try to avoid all possibilities of potential headaches. :D Toy Story is only a 81 minute movie so that would answer the short encode time. I'm usually not around when DVD-RB is creating a backup but according to my recent logs, it usually takes no longer than 100 minutes for a full backup. :)

[apfraats]

Just to point out:

1) This undersizing problem is REAL
2) It doesn't happen with all DVD's
3) In cases were it happens there are high bitrates and low compression reported.
4) It's an typicall 2.70.X.X 'feature'
5) It has nothing to do with DVD-RB
6) The problem is gone with CCE 2.66/2.67.
7) JDOBBS is wrong about 'saturation', because 2.66/2.67 don't have this problem.
8) We have to live with it, it's an CCE 2.70 feature.
9) You can do a 100% compression job, it will give larger output, but even then it can be undersized.
10) Quality of result, despite underzizing, is good.
11) We just have to live with it.

So clearly a typical 2.70.x.x issue, for sure.

Don't ask JDOBBS about it, because CCE is the target here....

But an 'saturated' bitrate doens't exists in DVD-land.

If you set average bitrate for cells a bit higher (with RB-OPT) , output comes out larger. I already tried that. So there is nothing like a 'saturated bitrate'.

A bitrate can be forced to be 9500 Kbps if you wish. Just use CBR (VBR_BIAS=100 IIRC) and set cell average to 9500.

You sure get oversized output in that way (if movie lasts long enough and that will be in the most cases).

The only restriction is:

totalbitrate (including all audio/subtitl./video)=<10.08 Mbps * time in seconds.

So you cannot fill a DVD with just 1 minute video at highest bitrate.

That's because of the DVD-SECS and not of any 'saturation'.

A 'saturation' doesn't exists.

I can encode a black picture stream at 9500 kbps if I want using CBR.

So there is no 'saturation'.

We have to live with it, as it seems to be erronous encoder behaviour in certain cicumstances. Lukey it's underzizing, NOT OVERSIZING, as that would be more problematic.

If you don't wanna have this undersizing just use 2.5 or 2.6X versions of CCE.

But it only seems to occur verry rarely so I gonna keep using 2.70.2.4 as it's faster, has a better encoder engine and hasn't problem 99,X % of the cases.

In the case I get this undersizing issue, I set DVD-RB targetsectors higher and try to get the most out of it.

'Saturated bitrate' also doens't exists, or the original could not be the original in these rare cases.

As long as you do not reach (MAX_TOTALBIRATE*TIME) there is always room for more bitrate......... definitely..

[jdobbs]

Please don't start making statements until you understand the facts. Saturation DOES exist. It has been proven repeatedly. You speak as if everything that leaves your mouth is coming from the burning bush....

To quote Shakespeare "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy".

The saturation has NOTHING TO DO WITH BITRATE. It has EVERYTHING TO DO WITH Q.... and it is related to CCE, not to DVD standards. It is related to VBR not CBR. CBR is very definitely NOT VBR!!! If you knew the difference, you wouldn't argue this point.

And one more point. Could you please try writing, just once, a post that will fit on one page?

[Boulder]

Yep, there is saturation. No matter what matrix you use, some sources do not use the bits you wish to allocate. Even at q1, the avg bitrate will be less than is desired. This is a well-known issue with MPEG4 codecs and MPEG2 isn't that different from them. The solution is to either live with it, make the source less compressible or use a matrix that quantizes less. I would choose option 3 first, then the rest.

Just try encoding something at q1 with HC and you'll see that the bitrate doesn't hit the max all the time.

[Trahald]

testing it with cbr doesnt work. mpeg-1/2 with cbr will pad out the difference to obtain the desired bitrate. this is done since generally when cbr is used falling below bitrate would cause flow problems (either from dvd/cd drive as with VCD or perhaps a streaming source.)

the only way to find out that a stream will undersize (saturate) is to run a vbr encode and then if its under-sized taking addition time to encode it in cbr. that is totally useless since the quality will only be at best AS good and even possibly worse in high demand sections than the smaller vbr encode.

[apfraats]

Keep youre horses, ok, maybe saturation exists, but I mean it is not an explanation for undersizing as 2.70.X should be saturated and 2.66 not with the same source ??? Nope... I don't think so.

So if it exists indeed it would have nothing to do with bitrate, so nothing with indersizing also, and you JDOBBS used it as argument for undersizing...

Q=1 ???

Not with the sources I've seen, nore with the results when using FULL VBR.

This thread was about undersizing, so if you mention SATURATION is probably the course, you have to put somoe more evidence to the scene.

I interpreted staturation as 'No more bit's are needed to improve quality'.

If it's an official term, sorry it's the first time I hear of it in this context.

So forgive me my ignorence, but still it isn't a reason for the undersizing, and that was were it all was about....

And this is NOT a page long.

Maybe a larger monitor would do the job :D

By the way, setting higher averages leaves larger result.

So it is not saturation here, or it would make no difference.

[jptheripper]

full vbr has nothing, and is probably inversely related to, q

full vbr is very bad for the encoder, it may alot many more bits where needed but it fails to alot bits properly (as you are seeing)

please do the same test with 2.7 but at defaults (vbr, q, etc..) i am resonably sure it wont undersize

[apfraats]

Some already reported undersizing with default settings....., I have tried also 'normal' settings, but NO it doesn't help.

The only thing that helps is using 2.66 instead of 2.70.x.x, and then the 'exact' targetsectors are reached.

I disagree about FULL VBR, a setting I always use.

Have the best results with it, so I won't stop using it. At least not in combination with CCE that behaves perfectly in FULL VBR.

Theoretically is the best way to dirstrubute bits in lesser room.

What's needed is used, what's not needed is not used.

As we deal with compression 100% of the times here (Why bother using DVD-RB else ?) it's the far most optimal setting if the encoder can handle it perfectly. CCE can, so why not use it ???

Since I used MIN_BITRATE=0 and VBR_BIAS=0 , results are much much better in compressions with lower averages.

No macroblocking anymore, although a 3 hour constant action movie with DTS and 5.1 DD is simply almost impossible to squeeze to a 4.35 GB DVD-5.

But everybody has the right to use their own 'optimízed' or prefered settings. That's the beauty of parameters, matrices, filters.

[jdobbs]

No one is arguing that CCE 2.70 doesn't have a sizing accuracy problem. I'm pretty confident it does. It just seems to be rare and on certain types of sources -- and I haven't seen the correlation between type and result yet. I only responded to your claim a few posts ago that "saturated bitrate does not exist" -- which is absolutely incorrect.

Your problem is that you're trying to come up with a "one size fits all" reason from undersizing. I'm telling you that one reason is saturation. Another is the fact that DVD-RB will not allow bitrates higher than the original. The CCE 2.70 output accuracy problem is just one more.

[apfraats]

Ok, I have mistakenly interpreted it, but It looked youre were pretty sure about it being the problem. No offense at all.

If it were due to saturation do you agree that:

1) Sizing UP targetsectors won't help in any way because of saturation (using FULL VBR, MINIMUM_BITRATE=0, MAX_BITARE=9000) ??

This is asked because setting a larger CCETARGETSECTORS yields a LARGER result with my problem DVD but I couldn't go towards reaching 4.35 GB, because DVD-RB decides to stop at 100% and probably adjusted CCETARGETSECTORS down towards SOURCESECTORS.

Correct me if I''m mistaken.

2) The limitation of MAX_SEGMENT_BITRATE by source I didn't like from start. So I always set it to 9000 , if not lower as the critical 10.08 mbps is gonna be reached, taking room for error in account.

I still don't see the use of this limitation as filters, matrices, different encoders can be expected to have total different charasteristics and why should a compression not have temporary spikes above source ?

Limiting it is usefull if encoding artificacts, I agree, but the limitation should be something to switch off in advanced settings for using correct sources and different encoders, which easily can behave differently and need this higher than source bitrate, due to matrices, filters, whatever reason.


For example sharpening or playing with contrast/brightness levels could simply demands a higher bitrate at a place.

Of course never TOTAL_MAXBITRATE must be exceeded....

Now I use RB-OPT to prevent DVD-RB from limiting bitrate.

However I notice that DVD-RB does NOT completely follows source, it still does use a max of 9000, even if source is going above (not it will hurt that much).

(I noticed this in different encodes having a 5.1 track only)

Well, the DIG.TV here 'just' uses CBR 6750 kbps.........

[jdobbs]

1. Incorrect. Bitrate is applied by segment. So changing TARGET_SECTORS will change the target size of all segments, not just the ones that are saturated.

2. You can do whatever you want with your source... but I wouldn't recommend it as a practice to the general population. There are other good reasons why I added it as well.

3. Setting the maximum bitrate to 9000 when DVD-RB recommends otherwise is a bad practice in all but CBR sources. But like I said -- it's your backup and you can do whatever you want with it... but, again, DVD-RB does things for a reason. When you bypass it's settings or override them with another package -- you also surrender your right to complain!

I suspect all these "customizations" you are performing after the fact may contribute to why you seem to see more undersizing than most do. But that's just speculation.

[apfraats]

Thanks JDOOBS,

1) I get it, yep, NOT ALL SEGMENTS ARE SATURATED.
You should be able to find the SATURATED SEGMNETS because they should have a lesser average then DVD-RB assigned to them ?

2) That MAX_BITRATE is the problem, I am talking about longer, because here in R2 a lot of movies have CBR.
To prevent a user from making mistakes, is precisely the REASON why it should be a user-defined setting. That's all I ever asked for.

So you could set: Limit to source bitrate: Y/N ?

Default: Y
In template: Y

If you set it to NO, then DVD-RB comes in and is going to calculate for you (on a per segment base):

10.08-(room for error)-(bitrate needed for suntitling/audio)= LIMIT FOR SEGMENT.

So then I'm satisfied with my CBR sources and I CANNOT make mistakes.

I don't see why this is so hard to do , because it was this way in older versions of DVD-RB IIRC.

So ALWAYS DVD-RB makes the decision for you.

When it goes wrong using it this way, I CAN BLAME YOU :D :D

But seriously, now I have to do manual calculations, I can make mistakes and all this calculation is already present in DVD-RB (or was at least).

So just choosing between: LIMIT BY SOURCE or LIMIT BY CALCULATION or whatever you call it, is simply more user-freindly for me as it saves me from making mistakes and doing manual calculations.

There is quit a lot of CBR stuff here. The latest was having 5500 CBR !!.


And my DVD and HDD-recorders use CBR as far as I know.

So that option would be really nice and helpfull. If it's implemented it has the major advantages:

1) Not having to adjust things manually.
2) Not making ERRORS
3) Not using not JDOBBS approved software tools :D

(remeber CCE 2.70.2.4 support ? oh boy.....:) )


And the undersizing: Like I always have:

1 DVD uptill now, and of course the very FIRST one using 2.7.x.x.
That was THE SKELETON KEY, and that problem was acknodledged by someone else.

I have tried about 25 now, and have no problem at all despite my settings. Because if there is someting wrong I always try the first and only thing before starting to make a statement:

Doing the thing with DEFAULT SETTINGS AND NO USER INTERVENTION IN ANY WAY (i'm not THAT stupid anymore :o ).

[jdobbs]

I think most realtime recorders use VBR. CBR use should be very limited. VBR always provides a better picture -- even if it only distributes across a small section of buffer.

Hmmm.... I think I'll test my recorder later...

[Edit] Just looked at the bitrate on a home video recorded by my realtime DVD recorder. As expected it is VBR -- and also as expected the range between high and low is much less than you'd get on a full analysis VBR encode. The recording peaks at about 4900Kbs and bottoms out at about 3100Kbs in 2 hour mode.

[winny]

@apfraats. What was the response from Cinemacraft support about the problem, as you stated early on the problem has nothing at all to do with Rebuilder.

Changing the default Rebuilder settings seems to be treating the symptom rather than finding a proper cure (to misquote the infamous 'aspirin management' technique spouted by executives).

I applaud anyone as committed as you are to finding a solution, but try not to overuse your CAPS LOCK key to hammer home your point to people with experience on their side, it just looks rude.

[Cropsy]

I made an encode that gave me 4.12G. It is the scandinavian release of Amityville horror 2005 released by Scanbox. It is protected by Macrovisions Ripguard system. I used fixvts to clean the vobs first.
I tried to change to cce 2.67.0.23, and it gave me an output of 4.20G with the same settings. I will try 2.67.0.10 later.
I use 3 passes and ccetarget set to 2255000.
The 2.70.2.0 used a total of 131 min, and 2.67.0.23 used 124 min. including creating an ISO.

[HKT3020_1]

With CCE SP 2.70.02.04 Trial, there is no undersize. I just did the movie Batman Begins (NTSC) today... it came perfect.
I used:
CCE=3
CCETargetSectors=2260000

in Rebuilder.ini file. The movie came out at 4696MB, just 10MB under the limit.
All the movies I do with the CCETargetSectors value listed above come close to this, never over 4706MB.

Just a note to those who alter the CCETargetSectors to 2260000, for the most part it works well with movies that average in at about 120 minutes but recently I ran Braveheart R1 DVD (177m) and it came in at 100.2% full for a DVD5 disc.:sly: I had to edit the credits to get it down to size to fit properly. I ran Movie & Menu mode keeping audio track #1.

I made an encode that gave me 4.12G. It is the scandinavian release of Amityville horror 2005 released by Scanbox. It is protected by Macrovisions Ripguard system. I used fixvts to clean the vobs first.
I tried to change to cce 2.67.0.23, and it gave me an output of 4.20G with the same settings. I will try 2.67.0.10 later.
I use 3 passes and ccetarget set to 2255000.
The 2.70.2.0 used a total of 131 min, and 2.67.0.23 used 124 min. including creating an ISO.

Take note that from the previous 2 ripguard DVDs I've purchased in the past, there was a 600-700MB blank PGC found in the Video Manager when browsing with DvdReMake and found in the VIDEO_TS.VOB file when using VobBlanker.

[kmac61]

i just wonder why apfraats is still using trial versions of ccesp while seeming to have every version since the dawn of time
CCTSPT2670010.EXE (for CCE 2.67.0.10)
CCTSPT2700204.EXE (for CCE 2.70.2.4)
If the logo doesn't bother you why complain about a slight undersize or
if you're using a patched version then this thread is violating the spirit of rule6

[raquete]

@ kmac61
everyday i search this thread to read.
i'm using the trial CCTSPT2700204.EXE too.the logo bore me but more the undersize like apfraats and sometimes oversize(sometimes) with this version.without logo the problem exist too.i think that apfraats bore more with undersize than with logo because when don't have under or oversizes problems,we can buy the full version.(i will).
i can't comment about "if you're using a patched version then this thread is violating the spirit of rule6",for my taste is strange to read words that don't was wroten(i read the whole thread and don't saw anything about it)...."if" is only conditional/imagination against who is posting about this cce version and not against RB! let the ball roll kmac61,all issues found about cce are true,we can't argue against legality,let the mods do that,they are "sensitives" and will close the thread if we start to post what is off topic.

[jptheripper]

my main issue is if you send the same script to 3 different cce's you get 3 different sizes. The most jdobbs can do is try and make sure things are right on his end. They are for 90% of users (made up but likely close statistic). the rest are likely cce issues, and therefore dont belong in this forum. the belong in the encoder forum, thats what it is there for.

I have a suspicion that incorrect avisynth and dgdecode versions may also be a source, in which case it is an installation error (user error) not a bug.

[jdobbs]

All I can comment upon is my own experience. Which is that I use CCE Basic v2.70.01.07 and CCE SP v2.20.01.05 (Trial) and I get the exact same size within 1% every time I run it.

[jptheripper]

i am the same

cce 2.5 and cce 2.67 and 4.30-4.32 everytime

[Cropsy]

OK. Here I go again.
Still working with the Amityville horror 2005 scandinavian release

I tried it with 2.50.1.0 and the result is 4.17G.
Then with 2.67.0.10 and it came out 4.20G.
And last I tried it with the latest HC that came with the installer, and it came out 4.21G in the best quality mode. HC used 162 min.

Maybe it is like HKT3020_1 said, that Ripguard is the bad guy here. Even though I cleaned the vobs with vtsfix first?

[jdobbs]

I don't think so. How could it randomly choose who it decides to affect?

Tell me this:

1. What version of AVISYNTH are you using?
2. What version of DGDECODE?
3. What happens if you don't do "FixVTS" first? (I've never used it and have never had a failed backup).
4. Are you doing any other preprocessing?
5. Are you using any other tools, like Matrix editors etc?
6. Are you using OPV?
7. Movie Only modes?
8. What is the overall bitrate shown by DVD-RB in the prepare phase? How about HIGH/LOW/TYPICAL?

[Cropsy]

Hi jdobbs

1. AVISYNTH 255
2. The one that comes with the installer, dated 21.1.2005
3. Haven't tried that yet. I will do so later today.
4. Yes and no. (tried both)
5. No
6. No
7. Whole disc and movie and menues
8. HIGH/LOW/TYPICAL Bitrates: 7*104/400/6*235 Kbs

Last night I increased the targetsectors to 2295000 and tried it with 2.70.2.0 again and it came out 4.12G

And just finished movie and menues only and it came out 4.20G with 2.70.2.0 wich is the biggest I got with 2.70.

It is now running without using fixvts, so I will be back with the result later.

[jdobbs]

Based upon your bitrates, I think what you are experiencing is CCE bitrate saturation. CCE seems to only allow the bitrate to rise to the point at which it has determined it has done a "perfect" representation. So some of the segments will not increase in size beyond a set point.

So the bad news is you aren't going to easily make it any larger. The good news is that it wouldn't increase the quality of the picture, even if you did.

Remember that output size is not representative of quality. It often correlates -- but occasionally it doesn't.

[Mr. Monte]

So the bad news is you aren't going to easily make it any larger. The good news is that it wouldn't increase the quality of the picture, even if you did.

Remember that output size is not representative of quality. It often correlates -- but occasionally it doesn't.

Not to mention..the less you write to the outside of a DVD..the less possible playback errors. Most blank DVD's have higher errors near the end of the disk.

[Cropsy]

OK thank you jdobbs.

I'm not into the technical details at all. I'm just a regular user.
I'm glad that there was a natural explanation for this.:D
The version I did without preprosseing with fixvts also came out 4.12G with 2.70.

[apfraats]

But if the saturation question is in effect here, one might assume that using a VBR_BIAS of 100 (= constant bitrate) MUST give correct output resutls.

But as I tried this, even this is not the case, and the result quality you even don't wanna see.....

But assuming this is the case with 2.70.x.x is is a reason for DVD-RB to take this into account.

I know JDOBBS (don't take this seriously !!)

If there are suaturated segments, and this is noticed by DVD-RB is some way, THEORATICALLY it should be possible to spent more bitrate to segments NOT SATURATED, thus yielding a better result.

You then get something like a TWO PASS DVD-RB job.

In the first pass it can detect segments that are smaller then predicted, these are marked saturated. The whole process can be done again with newer parameters for the really compressed segments, so these get improved.

And the the OLD question comes up:

Doing the whole PGC in one-pass, oh boy, there we go again.

Then we have NO SATURED SEGMENTS anymore....

CCE will automatically spread the bitrate on a needed base concerning the WHOLE chain, and not just the segments.

As no other encoders seem to have this problem we also could make the statements that CCE 2.70.x.x is one of the best, if not THE BEST encoder.

It's simply won't spend bitrate where it isn't needed.

But still segments that are not saturated are NOT COMPRESSED IN THE BEST POSIBBLE QUALITY because we waste space....

That's because of the SEGMENT LEVEL in which DVD-RB operates.

But let's be honest all together, how many % of the compressions are really iundersized ???

Uptill now I have had two... out of 50 done do far..

[jdobbs]

This is going way overboard. Why do we want to spend all this time discussing something that doesn't improve the quality -- but only adds more bits to satisfy someone's "fill 'er up" obsession. Frankly I have better things to do with my time.

Setting a bias to 100 makes it more like CBR -- but doesn't make it CBR... so it would have little effect on saturated areas.

As for doing the entire PGC in one pass... you're ignoring lots of factors... it's been discussed -- it's a dead subject. No more, please.

Let's get on to something more important, ok?

[raquete]

Why do we want to spend all this time discussing something that doesn't improve the quality ........it's been discussed -- it's a dead subject. ...
Let's get on to something more important, ok? ok! :goodpost: :thanks:

[Mr. Monte]

Yea..like 1.06 <g>

[apfraats]

This is going way overboard. Why do we want to spend all this time discussing something that doesn't improve the quality -- but only adds more bits to satisfy someone's "fill 'er up" obsession. Frankly I have better things to do with my time.




I also told 'not to take it seriously'.

and said I didn't condsider it a real problem seen the percentage affected.

Although I still wonder what encoder 'the pro's' use to produce oversaturated segments in a stream.....

I also still wonder if CCE's decession to cut on bitrate is really based upon saturation or is faulty at this point.

As all other encoders seem not to have any problem with this, that would mean:

a) CCE 2.70 is at fault here....
b) Other encoders waste bitrate...

Seen the results of CCE 2.70.2.4 on difficult material using VBR_BIAS=0 and MIN_BITRATE=0, which are perfect even at 8* zoom (:D ), I suppose the quality of CCE is just still at TOP-LEVEL........

However concerning the MIN_BITRATE that still under heavy fire (I really don't know why, as other encoders even doens't have such a setting), I'll test soon with a complete BLACK movie. Just replace a 3+ hour movie in DVD_SHRINK with a complete black image. Also saturation will show up, because there is no need for bitrate in P,B frames.

[jptheripper]

wow, what a complete and utter waste of time (my opinion only). can we kill this thread? as it is going nowhere and producing nothing

[apfraats]

In youre opinion maybe.........

And of course youre the master of the universe....

Ignorance is not the same as knowledge.

[winny]

Ignorance is not the same as knowledge.

... and people in glass houses shouldn't throw stones.

Anyone who feels the merit in testing 3 hours of black movie go for it, I agree the point is lost on me too.

[apfraats]

Considering the intellectual level of youre post, I even don't gonna explain.

[apfraats]

And the good news so far:

Using blankclip(framecount) gives CCE complete saturation at bitrate of contantly 0.21 (210 bits/sec) and a Q of 1.

Because there is full saturation the result is ridiculously undersized.

And it plays great, seeing nothing but black and of course the audio track plays.

So no need for anybody not to use MIN_BIRATE=0, as CCE's lowest value is a bitrate of 0.21 kbps constantly on a black source.

VBR_BIAS=0. MIN_BITRATE=0.

And it even generates GOP strcuture that's perfectly having q=1 for all I,P,B frames.

Now running HC test. That indicates an even lower bitrate.

So anyone complaining about player compatebility problems with a MIN_BITRATE=0 settings and using CCE 2.70.2.4 has to try HC that doens't honor MIN_BITRATE and procduces even lower bitrates on black straems.

HC reports 184 bits/sec...... Checked M2V's so far and also have Q=1.

When this output of CCE is input for DVD-RB again, it reports a 'source compliant' bitrate of 11xx bits/sec.

Well that's not source-compliant (500% too much !) but I suppose JDOBBS can explain this.

BITRATEVIEWER also reports averages according to the encoder information of CCE. So why DVD-RB decides reporting an 11xx bits/sec is a complete riddle for me.

[dragongodz]

So no need for anybody not to use MIN_BIRATE=0, as CCE's lowest value is a bitrate of 0.21 kbps constantly on a black source.
So anyone complaining about player compatebility problems with a MIN_BITRATE=0 settings and using CCE 2.70.2.4 has to try HC that doens't honor MIN_BITRATE and procduces even lower bitrates on black straems.
no what you need to do is give this constant pushing of "min bitrate = 0 is fine for all players" a rest. you have been told multiple times using a min bitrate of 300 fixed playback problems with a few dvd players irrelivant of if its not needed on yours. since anyone can change it to 0 if they wish please leave it at that and stop posting the same thing repeatedly.

oh and the fact that the encoders dont pad out that black stream doesnt mean the results will be fine on all players etc. you are trying to prove a point with an unnatural stream and how an encoder handles it, not how all dvd players will handle the produced streams, there is no relation. so PLEASE dont keep trying to find proof of what you think when you dont understand it.

[hank315]

I still don't see what you want to prove with this black frame movie.
HC that doens't honor MIN_BITRATE and procduces even lower bitrates on black straems.
HC calculates a minimum bitrate internally which is used to create a compression curve, that min. bitrate value has nothing to do with the actual minimum bitrate as it can appear in a stream.
If there's nothing to encode it will saturate even at Q=1.
In previous versions of HC padding was used to keep the bitrate above 400, that was dumped because it didn't work well with the last bitrate control algorithm and until now I didn't get any complaints about it.

The bitrate for black streams of HC will be a bit lower than CCE's bitrate, CCE always uses some padding (not only on black streams).

[jdobbs]

When this output of CCE is input for DVD-RB again, it reports a 'source compliant' bitrate of 11xx bits/sec. I have no clue what this means. DVD-RB doesn't check the MPEG input stream for source bitrate compliancy. The bitrates reported by DVD-RB are those it is passing to the encoder.

[winny]

... I even don't gonna explain.

No worries. If the above quote is anything to go by I wouldn't have been able to understand it anyways.

Have Cinemacraft responded to your support request yet? I would have expected them to have done by now, especially with the money they charge for the product.

[jptheripper]

In youre opinion maybe.........

And of course youre the master of the universe....

Ignorance is not the same as knowledge.

this was aimed at me I see.

And i can only assume you are the one chosing ignorance over knowledge, as the knowledgeable on this forum (jdobbs, etc..) have told you this is a saturation issue, and you have chosen to _ignore_ their knowledge. But hey, if you want a perfect 4.37gb blank video.. more power to ya. Just please stop wasting my time, and I assume the time of many others

[apfraats]

I have no clue what this means. DVD-RB doesn't check the MPEG input stream for source bitrate compliancy. The bitrates reported by DVD-RB are those it is passing to the encoder.


What I supposed to say , sorry not to be clear on this, is that you stated the max_bitrate DVD-RB is determing is depending on the max_birate found in the source segment (aka CELL).

In my back movie there is a constant bitrate of 210 at GOP-LEVEL, as usual BITRATEVIEWER makes a mess of this because it's trying to caclulate on a per second base. but the average is displayed ok.

So if I give the output that consists of constant 210 kbits/sec GOP's to DVD-RB again, and I do PREPARE, and look with RB-OPT it's reporting a MAX_BITRATE for the segments that all are equal and all are 210 kbits/sec GOPS of 1219 kbit/sec and for some segments 1220 Kbit/sec.

So what I want to say here is:

Input for DVD-RB consists of 210 Kbits GOPS constantly for over 2 hours.

DVD-RB assigns MAX_BIRATES of 1219 Kbits/sec after prepare !!!!!!

This is far too high and now I wonder what CAN happen in other cases....

JDOBBS , you told me the source was inspected as GOP-level and that bitrate determines the MAX_BITRATE for that segment.

But 120 Kbits source results DVD-RB in believing the max is 1219 Kbits/sec for a segment !!

That is simply impossible, or you have another explanation for this.

Simply I don't understand what's happeninmg here and expected a caculated max_bitrate of about 210 Kbits/sec or a little higher maybe but not a 500% difference !

That's my problem, and maybe you can explain.

For example it's possible you have a minimum implemented, I don't know.

Just experimenting and seeing what's happening.

It's 1219/1220 for ALL segments, and there are absolutely NO spikes whatsoever. I even tried DVD-LAB and it reported no peak bitrate over what was expected.

[apfraats]

I still don't see what you want to prove with this black frame movie.

HC calculates a minimum bitrate internally which is used to create a compression curve, that min. bitrate value has nothing to do with the actual minimum bitrate as it can appear in a stream.
If there's nothing to encode it will saturate even at Q=1.
In previous versions of HC padding was used to keep the bitrate above 400, that was dumped because it didn't work well with the last bitrate control algorithm and until now I didn't get any complaints about it.

The bitrate for black streams of HC will be a bit lower than CCE's bitrate, CCE always uses some padding (not only on black streams).

Thanks HANK, now I know that the statement of others that HC uses a minimum bitrate inernally is no longer true.....

So if youre encoder procudes lower bitrate and the Q was indeed perfectly 1 over the whole output, can you explain to me why CCE 2.70.2.4 produces undersized output probably due to q=1 sections and HC doen not ??

I would expect that knowing now what you stated about CCE that the underzizing of HC would even be more.

Biut with the sources I tried it wasn't so, there only CCE 2.70.2.4 was undersizing.

Thanx for explanation so far...