2-pass CQ

[Shinobu]

hello,
for constant quality viewing, i do a lot of 1-pass CQ encoding, but i sometime need to do the encoding 2 or 3 times to have file more or less the filesize i want (for movie, for series i don't realy care ^^).

so is thre any way to do a first pass like in 2-pass mode, and then calculate precisly the constant quantitiser to use / final size of the video (for exmple at Q4 i'll have 560mo ....); so we can do a "precise" encoding in CQ mode in 2-pass.

++

[Didée]

You could use jonny's "enc" tool for this. Heard his site is currently down (?), but there was a link in this thread (http://forum.doom9.org/showthread.php?s=&threadid=86494&highlight=enc) lately.

You would do some short comp.-test alike size prediction tests, and by that find your "target quantizer".

BTW, if you find your're going to head for, say, quantizer 4.5, then you could also use 1-pass CBR with all quants capped to 4-5. Probably better than a constant quantizer, then.

[Selur]

though constant quantizer doesn't imply "constant quality viewing", since it only sais how much lost during quantization, but difficult/complex scenes could still look crappy,...

[Ark]

Well, imho costant Q is the closest thing to costant quality mode...

[Sharktooth]

uhm... no. CBR isnt constant quality too...
ideally a constant quality encode is made of all frames with the same PSNR.

[Didée]

Originally posted by Sharktooth
uhm... no. CBR isnt constant quality too...... which is not what I've been saying. (I suppose it's addressed to me, since I was the only one in this thread mentioning CBR.)

I've explained my opinion of "CBR-with-tight-capping" versus "quants jumping up-down-up-down-up-down" several times. Should be enough by now. If I didn't reach any ears ... well, pity. :)

[Sharktooth]

@didée: it was not referred to you. I just meant there still isnt a way to encode at constant quality.

[Ark]

I meant costant quantizer, which (as far as i know) is basically give the same amount of compression to all frames(or take away the same amount of detail...), in short treat all frames almost the same way.

This is costant for me, or at least more costant quality than CBR, because it doesn't adapt itself to complexity changes, and i'm talking about perceived quality, not syntetic tests (like PSNR).

[manono]

If I were Shinobu, I'd do a standard 2-pass, figure after the first pass roughly in between which 2 quants the 2nd pass should be to achieve the size he wants, and then cap at those 2 quants. So, for example, if the first pass is, say, 1,200MB, he has audio of MP3 at say, 80MB, and he wants to fill 1 CD, I'd make the quants 3/3, 3/4, 3/4 for the second pass.

That's similar to what Didée was saying (I think), except this way, in most cases, with exceptions under a few scenarios, he'll get a perfect final file size by running the second pass.

[Shinobu]

i don't want a perfect file size, but a constant quality around a file size i want.
on dark or foggy scene, the two-pass will make them encode at highter quant (don't know why)and on those scene a difference of quant 3 versus quant 4 isclearly visible, so i don't want to do a second pass with variable quant but want to calculate (as accurate as possible) the lower constant quantitiser i can use to put my video file on a defined support size.

no ways to do it ?

thanks.

++

[jonny]

You can speed up things in some ways:

you can run an encode @ quantizer=2 and use this:

average_quant = 2 * q2_size / target_size

example:

your size for the q=2 encode is 2100MB
you want the final size around 1200MB

average_quant = 2 * 2100 / 1200 = 3.5

this is an approximation... better than nothing :D


note:

you don't need to do full encodes in order to get q2_size, use Enc ( http://jonny.leffe.dnsalias.com/ ), in 5 minutes you can get the size for the quantizer you want (and you get an idea of the errors looking in the tests)
+ using the formula above you reduce the "prediction steps"


ps:

the 2-pass method, from manono (hi! how are you? ^^) and Didée give you the best of all

[Blue_MiSfit]

add SelectRangeEvery(280,14) to your AVS at the end. This will select 14 frames every 280 frames, and thus provide a comp test. Encode this using CQ, starting with 2, and set a batch job up in vdub to test 2,3,4, whatever you want.

Then, open these comp tests in vdub when theyre done, go into the file info, and multiply the average delta frame size by the total number of frames in the movie. This will give you a good idea of how big the final movie will be at whatever CQ you specified for that given file.

I usually do standard 2 pass that ends up at an average quant of 3-4.

Redo which version pleases your eyes to approximate your filesize.

[manono]

Hi-

i don't want a perfect file size, but a constant quality around a file size i want.

Well, unless you can use a final whole number quant (2, 3, 4, etc), with wildly varying file sizes, then you'll always get a minimum of 2 different quants being used, and the complex scenes will usually use the higher quant. If, for example, the approximate final size requires an average quant of 3.5, then the best you can do is all 3s and 4s. Quants only come in whole numbers.

If you can easily tell the difference between quant 3 and quant 4, then perhaps your best bet is to use a high bitrate matrix, such as the 6 of 9 matrix or one of Soulhunter's high bitrate matrices. Then the H.263 equivalent quants might be 6 and 7, or something like that. And I defy you to tell the difference between those 2 quants with just your eyes. So, you'd set up your encode with a high bitrate custom matrix, run the compress test with jonny's enc, or GKnot's Compress Test, similar to what Blue_MiSfit just described, and then run a single pass, perhaps following Didée's instructions above. With a high bitrate matrix, even just doing a constant quant encode, you'll get better file size prediction, because of the lesser difference between the higher numbered quants than you would with a constant quant encode using H.263 or even the MPEG matrix.

Hi jonny-long time no see. :)

[Shinobu]

thanks i'll tst all that...

++