View Full Version : Slight Undersize
magic144
16th November 2005, 14:29
hi folks
any reason why a rebuild would come in at about 3.98Gb vs the more usual 4.3-ish?
the reduction level is quite high at 94.6% (i.e. hardly any compression) on a movie-only backup, keeping a 5.1 track and a 2.0 commentary, plus english subtitle track
I can imagine that if the original was very high bitrate, then RB's built-in bitrate limit might cause it to be capped, but wouldn't the size estimation take that into account before rebuild?
anyway, it's no biggy - the output looks decent, I was just curious as to the somewhat unusual shortfall in this instance - in fact I re-ran it with 6-pass CCE instead of 3-pass, and the output even got a tiny bit smaller (3.87Gb)
I'm running it again now with HC to compare
cheers for your ideas/answers
magic144
16th November 2005, 14:32
btw, there were no errors or missing segments in the logs or intermediate files either - everything seems to be complete as expected
magic144
17th November 2005, 00:21
anybody?
is this undersize anything to worry about/examine further, or just a perfectly normal happenstance for a certain kind of source...???
magic144
17th November 2005, 00:58
hmm, HC has landed bang on the 4.33Gb "money" target-size-wise
what is it about CCE that is not meeting its target for this particular case?
is CCE doing something right and HC something wrong, or vice-versa?
will the HC picture quality be "better" in this case, or has the CCE encoder just been more judiciously efficient? or in fact was the pre-encode size prediction just easier/more-accurate/deterministic in the case of HC?
pg55555
17th November 2005, 22:10
I'm not an expert, but probably it has to do with the Q CCE uses, and how it uses it.
At least in the OPV mode, Q values are always an integer. So, it varies for example from 5 to 6 (a 20% increase), or from 30 to 31 (a 3.3% increase)
As your source does not need to be compressed so much (95%), CCE probably used a small Q to begin with. And when it try to use a lower Q, it would oversize.
So 4.3 is just 8% bigger than 3.98. If CCE was using a Q of 6 and reaching the 3.98 size, when it reduces the Q to 5 in order to have more bitrate, it changes the size in 20% and would produce a 4.7 output, too big. So it keeps it at 3.98.
I know the above explanation applies to OPV mode in CCE, not to VBR. But I think that it is probably related to your experience and how CCE works.
Probably HC works differently.
magic144
17th November 2005, 23:14
cheers pg,
I've got the impression before from jdobbs that CCE is much less predictable/controllable than e.g. HC, so I'm kind of going on the assumption that this encode is just CCE having one of its "moments" - I haven't taken the time to sit down and watch the rebuilt product on TV yet, but from skimming through the output on the PC, it looks perfectly fine
I'm not using OPV though - rather 3-pass VBR (or 6-pass in my subsequent test) - so I therefore assume it would be as close to the intended target size as ever before (and indeed possibly closer with 6 passes)
I'm still confused - if it decided to over-compress, doesn't that mean it could have used a higher (and presumably closer to the original) bitrate throughout to more effectively make use of the now-extra space? I don't think the granularity of the compression (be it in terms of 'Q' or another parameter) can be so coarse as to affect the output by 300+Mb given that the process for each cell is individually parameterically controlled
should I be looking at the vbr_bias (25) and quality_prec (16) numbers to be changed in order to get closer???
aaron10
18th November 2005, 02:05
http://forum.doom9.org/showthread.php?t=95102
magic144
18th November 2005, 03:10
wow, thanks aaron10
that was VERY informative
I followed the thread and ran the disc thru OPV prepare phase
and as you can see, Q=1 was chosen,
hence I guess the answer is that the encode is already as good as it needs to be
cheers v. much for the link
----
[18:59:53] Phase I, PREPARATION started.
- CCE SP 2.70.2.1 encoder selected.
- "One Pass VBR (w/analysis)" mode is enabled.
- "Movie Only" mode is enabled.
- VTS_01: 2,648,845 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 149,591 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 94.6%
- Overall Bitrate : 6,482/5,186Kbs
- Space for Video : 3,949,452KB
- Analyzing VTS_01 for optimal Q factor.
-- TargetSize (sectors):2,004,347
-- Sampling 3000 of 149591 frames.
-- Predicted size (sectors) at Q=19: 689,347
-- Predicted size (sectors) at Q=1: 1,516,266
- Q Value selected: 1
- HIGH/LOW/TYPICAL Bitrates: 5,845/600/5,186 Kbs
[19:06:53] Phase I, PREPARATION completed in 7 minutes.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.