View Full Version : Q Factor Confusion
mrsnail
12th February 2004, 02:49
Hey all,
I've been reading up for many hours about the Q factor when using 1 pass vbr in CCE, but there is one thing I am still unclear about.
When I encode in multipass mode, I create the first pass first, and then select multipass, using the .vaf file created by the first pass. I presume this step is correct.
What I am unclear about is whether the value of Q I set in the first pass has any effect on the quality of the encode once it has been multipassed, for instance 4 times.
Would setting the value at 80 have the same result after the multipasses as if I set it at 1 ? I ran a few tests , and could not notice much of a difference, and what I may have concluded may have just been the good old placebo effect :/ The file sizes were slightly different by a very small amount indeed.
Thank you very much for your time :)
RB
13th February 2004, 10:02
I know many people will claim the opposite, but creating the VAF in One-pass VBR and then doing additional passes in multipass VBR mode using the existing VAF really gains nothing, IMHO. If you do only one additional pass quality may be even worse because the VAF file was created using a (probably too high) Q factor and CCE distributes bits based on that rather than on the optimized bitrate distribution it would have access to if the VAF would have been created in multipass VBR mode in the first place.
So, if you favor speed over quality, use simple one pass VBR and be done with it, otherwise use multipass VBR. Each mode should have the VAF file created in the very same mode. This also makes sense when you read the CCE manual:If the setting of the bitrate is a major change,
however,it is better to recreate the video information file because a
better encoding result can be obtained with less number of passes.
When an average bitrate is set to twice or more or half or less than
that previously specified, recreating the video information file is
recommended.
Now since you cannot specify an average bitrate in OPV mode, it can be assumed that many times when reusing the OPV VAF in multipass VBR mode where you specify an average bitrate, the "setting of the bitrate" will be a major change.
bobwillis
13th February 2004, 10:43
Hi,
If the OPV Q factor was determined using D2SRoBa, then the average bitrate of the OPV vaf pass & any additional VBR multipasses are near identical. Therefore, it is safe (and positively recommended) to use the OPV VAF for additional multipasses of VBR. IMHO, OPV + 1 pass VBR resizing yields improved quality for high Q movies.
This is because OPV attempts to acheive constant quantization for the whole movie. Constant quantization, (some would call it constant quality is not necessarily a desirable thing) - especially with a low average bitrate. VBR doesn't attempt to acheive constant quantization, its quantization distribution is affected by the bias parameter. VBR does a better job of allocating more bitrate to scenes where you are likely to notice more defects - instead of just encoding with a constant quantization which may yield good quality in some scenes, but indifferent quality in others.
Regards,
Bob
RB
13th February 2004, 13:07
Well, shouldn't you then set VBR Bias to 0 for your additional sizing pass, otherwise it would break in and "destroy" your constant quality from the OPV pass?
bobwillis
13th February 2004, 13:30
Hi,
That's right, if you want VBR to look very similar to OPV then set a bias =0. The bitrate deviation is then unconstrained, and a close to constant Q encode will result. Increasing bias actually constrains the amount that the bitrate can vary, in other words it will tend not to vary as much as it would with OPV. The result is a non-constant quantization encode. A thorough look at the plots at the end of the CCE v2.66.01.07 pdf manual highlight how the distribution of bitrate changes as the bias is modified. You can also compare it with the plots of OPV encodes of the same source (with differing Q factors).
Regards,
Bob
mrsnail
13th February 2004, 22:38
Thanks very much for all the imput :)
It's given me a new way of going about encoding - and I shall be trying out what you both said to see what I get :)
Thanks again.
ArchStanton
14th February 2004, 15:14
I tested OVP+3-pass-VBR vs. 3-pass-VBR a long time ago and the differences were marginal. IIRC the average quantisation in VBR mode was about 0.1 lower, the quantisation peak however was higher. And yes the quantisation curve with OVP+VBR is slightly more constant. Iīd say the result is pretty similar.
The reason I do OVP+VBR is to see how compressible the whole movie really is. When you can hit your target size, with a Q level of letīs say at least 25, the chances for high quality encodes are pretty good.
SiliconSoul
17th February 2004, 07:33
so at what point would you say the Q is not good enough to get high quality encodes and to use multipass?
r6d2
17th February 2004, 11:48
Some users have found this to be the case for Q above 40 as reported on the D2Sroba thread. It makes a lot of sense. The CCE manual states that Q~40 or higher is not so quality oriented as is it size oriented.
However, remember your own eyes are always the best rule. My personal is Q~35.
SiliconSoul
17th February 2004, 16:32
i have one that is a tv dvd and one of the episodes is longer and geta Q of 53 as per qcce. ill see how bad it gets compared to multipass.
DoctorM
12th August 2009, 19:47
Bumping an old thread here (since it's one of the few that discuss a sizing pass). I know the RoBa method uses an additional multipass, but is it still the consensus that doing one isn't a bad thing?
It's not uncommon for me to do a 1-pass encoding and miss my target to the point that I find myself recoding 1-2 more times. At that point a multipass would have made much more sense.
Sooo. According to what is being said above, as long as the bitrate difference is between 51 - 199% (though I would think outside 75-125% a new OPV would make sense anyway) and the bias is set to 0, adding a sizing pass is not only acceptable, but will have no negative impact on the final encoding?
Edit: Yes? No? Anyone?
r6d2
15th August 2009, 19:24
IMHO, yes.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.