Log in

View Full Version : Survey: At what Q-value do you decide to do multipass?


archaeo
4th February 2005, 01:20
For those of you who (can) do OPV (and assume optimum size output), at what Q-value do you tend to go to a multi-pass?

jdobbs
4th February 2005, 01:25
???? Q value for multipass?:confused:

archaeo
4th February 2005, 01:38
Yes, lets say you run two OPV projects, one results in a Q of 4, and the other gives you a Q of 23... I'd tend to accept the former w/one pass and run the second as a multi pass. Just wondering what others would accept with OPV Q results.

edit: this question arises from an earlier post I read by Ddogg, where he discusses OPV Q values and his decision to go to multipass.
Ddogg wrote:Frankly I just could never personally tell the difference between an OPV in the sweet-spot of 18-36 and a 4 pass multi-pass. Especially since it took a fifth of the time of a 4 pass. Other people say they can and some say they can't. Typical bs and it sure ain't very scientific. It is very good to see these less subjective results from you. Thanks for taking the time to post them.

jdobbs
4th February 2005, 01:50
There is no Q value that can be set for multipass. You aren't confusing Q value with Quality Prec are you?

The Q value that you get from OPV is based upon the size and compressibility of the source. There is no relationship between the two -- each is applicable only to the source from which it was calculated.

Multipass does not use Q value for processing -- its quality level is pretty much guaranteed to be as high as is possible to fit in the target size.

Don't know if this applies to you, but generally folks shouldn't shouldn't be changing Quality Prec unless you understand exactly what it is -- and it isn't related to quality directly. The default value works best for almost all sources.

Search here at Doom9, there is a lot of discussion on that setting.

wmansir
4th February 2005, 01:57
He's saying: when doing OPV at what point do you say "That Q value is too high, I'm switching to multipass".

archaeo
4th February 2005, 02:00
jdobbs,
sorry for the confusion.

No, I'm not talking about setting Q, I'm talking about using a Q-value obtained from an OPV to decide if I'll do a multi pass... With a low Q I'd tend to stick with a one pass VBR; with a higher Q, I may go to a multipass... Wanted to see where this threshold was for others.
I used Ddogg's quote above to try to clarify.. :(

jdobbs
4th February 2005, 02:05
Oh... I see. Sometimes I can be a little dense.

I usually go with 40 as the max I can tolerate for the main movie. Here is what Cinemacraft says:

1 - 40 Priority is given to image quality over compression rate
40 - 80 Standard setting
80 - 120 Priority is given to compression rate over image quality
120 -> Image quality deteriorates considerably

Others choose a lower value...

Sir Didymus
4th February 2005, 09:13
@archaeo

- Also, in your question, you underlying assumption is that at a given point (based on a specific Q value) it may be necessary to switch to multipass encoding to improve quality, right ?

- Well, me simply not agree with the assumption...

Regards,
SD

Edit.
Well my experience on the subject is very limited; nevertheless a little test was done here (look specifically at the post "Constant Q Test"):
http://forum.doom9.org/showthread.php?s=&threadid=86038&perpage=20&pagenumber=5

It seems (me being convinced) that if OPV at some given Q values is "optimal", meaning it perfectly reach the wanted bitrate, multipass encoding can not improve at all the obtained encoding...

archaeo
4th February 2005, 15:31
@Sir Didymus,

Interesting thread, and informative :cool:
Yes, that was my assumption, that if you received a 'high' Q, say beyond 30 or 40, you might retain (or 'increase', as you say) quality by going to multipass. From what I am reading more and more, other than for sizing accuracy, multipass is NOT going to improve quality over an OPV pass. The additional pass(es) are really only useful to get the result sized properly (which may only slightly improve quality). It seems to be borne out by these tests that One pass VBR sets up bitrate to it's optimum allocation, and it's only really a matter of optimizing target size.

So if I do a One Pass VBR on a source and it comes in at my target of 4.3 Gb, there's really nothing more I can do to improve result, with the exception of filtering, if I am not happy with the visual results.
This certainly does lead me to look more toward OPV encodes, as the time required for multipass may be just that - a waste of time. If I get to my target size through OPV, what's the point of even doing one more pass?

Sir Didymus
4th February 2005, 17:42
Good question, archaeo, what's the point ? :D

I am not sure, maybe I am wrong, but on what I quickly remind CCE is the only MPEG2 encoder allowing more than 1+1 in multipass encoding; and by sure it is very rich of many nice parameters and tuning values other than the number of passes in VBR encoding.

--- Sometimes me think this specific one, and its effects - the number of passes in VBR mode - is a little bit abused, and its effects, by sure, over estimated...

Cheers,
SD

TheSeeker
4th February 2005, 17:54
Originally posted by Sir Didymus
@archaeo

- Also, in your question, you underlying assumption is that at a given point (based on a specific Q value) it may be necessary to switch to multipass encoding to improve quality, right ?

- Well, me simply not agree with the assumption...

I agree with this up to a point... I agree that if the Q is under 40 for sure you are going to see little or no difference. Higher than that you could see a difference..> But I find it really hard to believe that even if you get a ridiculous quant of like 100 + or so that there will be no difference in quality. I admit I havent done enough testing to say this with absolute certainty. But I dont think we should totally right off a 1+1 multipass as being totally useless.. I mean if you want guaranteed quality and guaranteed sizing then you cant beat a quick 1+1 encode. Sure you might spend a little more time doing it but then you have to take into account the little extra time spent in accurately calculating the target Q (this takes a bit more time if using rb opts double pass prediction), not to mention completely reencoding if the target size is way off. For the most part one could use OPV almost exclusively (especially if using rb-opts double pass prediction, which is right on), but I wouldnt totally write off multipass as a great method. Just a question, you can use filters and custom matrices in OPV mode right?

EDIT: Would anyone that has used OPV mode with a high Q please share their findings? Is there a big difference in quality between multipass and OPV when a high Q is needed?

Sir Didymus
5th February 2005, 00:13
Hi TheSeeker! :)

Sorry it tooks a little bit to elaborate...

Originally posted by TheSeeker
...But I dont think we should totally right off a 1+1 multipass as being totally useless.. I mean if you want guaranteed quality and guaranteed sizing then you cant beat a quick 1+1 encode. Sure you might spend a little more time doing it but then you have to take into account the little extra time spent in accurately calculating the target Q (this takes a bit more time if using rb opts double pass prediction), not to mention completely reencoding if the target size is way off. For the most part one could use OPV almost exclusively (especially if using rb-opts double pass prediction, which is right on), but I wouldnt totally write off multipass as a great method. Just a question, you can use filters and custom matrices in OPV mode right?

EDIT: Would anyone that has used OPV mode with a high Q please share their findings? Is there a big difference in quality between multipass and OPV when a high Q is needed?

1. Maybe what stated by myself before is easily misinterpretable... Me totally agree with all this part of your post... And I am really convinced if you want to be guaranteed both about size and quality multipass VBR is the proper (and very valid) choice...

2. Yes, you can use in OPV filters and custom matrices, exactely as you do in multipass VBR; in my tests posted few months ago no filters were used, but custom matrices did, both with OPV and VBR multipass...

3. Me too very interested to ear opinions of other people having carried out comparisons, encodings, tests, at OPV - high Q...

4. What I am not understanding is the logic of your first statement: "...I agree that if the Q is under 40 for sure you are going to see little or no difference. Higher than that you could see a difference... But I find it really hard to believe that even if you get a ridiculous quant of like 100 + or so that there will be no difference in quality.". I mean, what are the reasons, if you see or if you feel that under Q=40 things go in a given manner, they should provide different results when Q >> 40 ?

All the best,
Didymus

TheSeeker
5th February 2005, 19:29
First off let me say Im not really sure if Im interpreting your question right, so if you felt I havent understood you then please let me know.

Oh I think everything will go as planned with a Q above 40. As I understand it setting the Q says this to the encoder: "I want this level of quality and I want you to change the bitrate however is needed to meet this constant quality measurement." Well this is fine if you say Q of 40 or under:

1 - 40 Priority is given to image quality over compression rate

But if you tell the encoder.... "Just keep it at a decent quality" (Q of 70 or so)

40 - 80 Standard setting

Then you may see a little difference in image quality (compared to the original) but probably not all that much because a little more of the priority is given to the target compression rate than to the quality controls.

But if you say "I really dont care about quality much" (Q of 100 or more)

80 - 120 Priority is given to compression rate over image quality

Then I think that on a bigger, longer movie you could definately start to see some definate loss of quality of image (again as compared to the original stream). Are these not fairly logical assumptions?? Or am I totally missing the point?