on multipasses

[10L23r]

is there any advantage to using crf for the first pass rather than abr?

[shon3i]

If you like the quality of the output after CRF, you will save you time

[J_Darnley]

The advantage is that you pick a quality then use the resulting bitrate in the second pass, but this does mean that you should use "slow" settings on the first pass. "Fast" settings alter the resulting bitrate by a fair amount.

If you are targeting a specific bitrate, I don't know if/why you should use crf for the first pass.

[EDIT] Do the common "fast" settings use subme 1 or 2?

[LoRd_MuldeR]

A 2-Pass encode with CRF in the first pass makes only sense if you want to use CRF plus VBV.

Unless VBV is involved, CRF works perfectly fine with a single pass. And if you are targeting for a specific filesize (or average bitrate), you will need to do a "classical" ABR 2-Pass encode anyway...

[St Devious]

I have never really used anything besides automatic 2 pass encode average bitrate encoding in MeGUI. But I am looking to expand my knowledge to different ways to encode.

So bear with me.

I understand from here (http://mewiki.project357.com/wiki/X264_Settings) that CRF is a parameter to set the output quality and it selects bitrate by itself.

Is it a 2 pass encode or just one pass ?

Is it better than 2-pass average bitrate encode ?

[J_Darnley]

Plain CRF is one pass, it is equivalent to 2-pass at the same bitrate.

[kemuri-_9]

[EDIT] Do the common "fast" settings use subme 1 or 2?

last i recall, subme=2 in megui's "turbo" settings and I haven't heard of it changing since then.

[LoRd_MuldeR]

Plain CRF is one pass, it is equivalent to 2-pass at the same bitrate.

...with the subtle difference that with CRF you can't know the resulting bitrate in advanced ;)

It's also possible to run the first pass of a 2-Pass encode with CRF mode (instead of ABR mode), but the second pass will be ABR again (with the target bitrate that resulted from the first CBR pass). But I say it again: This kind of "2-Pass CRF" makes only sense, if you want to use CRF mode with VBV (because VBV doesn't perform well with a single pass). However if you are not using VBV, then CRF will work perfectly fine with a single pass! And if you want to do a "classical" 2-Pass encode to hit a desired filesize (or target betirate), then you can not run the first pass in CRF mode for obvious reasons...

(BTW: ABR mode is used via "--bitrate x", CRF mode is used via "--crf x". These two parameters are not used at the same time!)

[St Devious]

...with the subtle difference that with CRF you can't know the resulting bitrate in advanced ;)

It's also possible to run the first pass of a 2-Pass encode with CRF mode (instead of ABR mode), but the second pass will be ABR again (with the target bitrate that resulted from the first CBR pass). But I say it again: This kind of "2-Pass CRF" makes only sense, if you want to use CRF mode with VBV (because VBV doesn't perform well with a single pass). However if you are not using VBV, then CRF will work perfectly fine with a single pass! And if you want to do a "classical" 2-Pass encode to hit a desired filesize (or target betirate), then you can not run the first pass in CRF mode for obvious reasons...

thanks.

So is CRF faster than 2-pass encode but almost the same quality if they are the same bitrate ?

Is it possible to judge than a certain CRF value like 18 would always have certain bitrate ?

[LoRd_MuldeR]

So is CRF faster than 2-pass encode but almost the same quality if they are the same bitrate ?

Obviously CRF is faster, because usually it requires only one single pass. So compared to a 2-Pass encode, a normal CRF encode will require roughly 1/2 the time.

And as said before: A 2-Pass encode and a CRF encode of the same bitrate are equivalent. You probably couldn't tell the difference ;)

Is it possible to judge than a certain CRF value like 18 would always have certain bitrate ?

Nope. It totally depends on the content of the video. That's why we have CRF mode: We don't need to decide on a bitrate in advance :D

(Try encoding a clean CGI source and a grainy "real life" source of the same length/resolution/framerate, both at the very same CRF value. They'll come out at completely different sizes)

[St Devious]

(Try encoding a clean CGI source and a grainy "real life" source of the same length/resolution/framerate, both at the very same CRF value. They'll come out at completely different sizes)

What about two game videos with the same CRF setting ?

[10L23r]

A 2-Pass encode with CRF in the first pass makes only sense if you want to use CRF plus VBV.

Unless VBV is involved, CRF works perfectly fine with a single pass. And if you are targeting for a specific filesize (or average bitrate), you will need to do a "classical" ABR 2-Pass encode anyway...

:thanks:, got it

now more questions:

is crf more similar to 3pass or 2pass? (yes, i know that 3pass is only 1% or so better than 2pass). ignore vbv here.

how exactly does using fast settings on the first pass influence the quality of the second pass?
well here are my two guesses:
1. the .stats file is less accurate cus of the fast settings' intrinsic inaccuracy
2. when using fast settings, the final bitrate of the first pass varies more greatly from the specified bitrate than when using slow settings.

also, by how much does a fast first pass influence the second pass's quality? i would guess that the decrease is along the lines of using 2pass over 3pass or using umh over tesa, but idk.

@st devious
they should come out at about the same size, depending on the quality of the video. a crysis video and a super mario video at the same resolution and crf would NOT have the save filesize

[LoRd_MuldeR]

What about two game videos with the same CRF setting ?

Probably it would result in a more similar bitarte than sources of different type, but you still won't get the same bitrate and you still won't be able to predict the size in advance.

If you care about the resulting bitrate (or filesize), then simply don't use CRF ;)

now more questions:

is crf more similar to 3pass or 2pass? (yes, i know that 3pass is only 1% or so better than 2pass). ignore vbv here.

There is no "similar to 3-Pass", because 3-Pass is useless. 3-Pass is nothing but a placebo. It's no better than 2-Pass.

how exactly does using fast settings on the first pass influence the quality of the second pass?

Many options (for example the ones MeGUI lowers in "Turbo" mode) can be lowered safely in the first pass, with no noticeable (or negligible) effect on the second pass.

1. the .stats file is less accurate cus of the fast settings' intrinsic inaccuracy
2. when using fast settings, the final bitrate of the first pass varies more greatly from the specified bitrate than when using slow settings.

1) Yes. But the difference in stats file "accuracy" usually is too small to be noticeable in the final encode (second pass).

2) 2-Pass will always hit the desired target bitrate, even when using "fast" settings. Using faster settings (in the final pass) will only lower the "quality per bit".

BTW: You can even use a bitrate for the second pass that differs from the bitrate that was used for the first pass. x264 will still hit the target bitrate!
But be aware: The bigger the bitrate difference (first pass vs. second pass), the more quality will suffer. Ideally use the same bitrate for both passes.

[10L23r]

But be aware: The bigger the bitrate difference (first pass vs. second pass), the more quality will suffer. Ideally use the same bitrate for both passes.

what if u specify 500kbps for the first pass and it gives u something crazy like 2000kbps? shouldn't a third pass be slightly useful then?

or... is 3pass COMPLETELY useless. i mean even more useless than me-tesa

[J_Darnley]

x264 is very unlikely to do that and if it does there are probably other problems that you should fix before doing a third pass.

[JohannesL]

If you care about the resulting bitrate (or filesize), then simply don't use CRF ;)

Significant correction:
If there is a specific bitrate you need to stay below, at the expense of quality, don't use CRF. Otherwise, use CRF.

[LoRd_MuldeR]

what if u specify 500kbps for the first pass and it gives u something crazy like 2000kbps? shouldn't a third pass be slightly useful then?

That won't happen. Even with only the first pass, x264 will hit the specified target avarage bitrate (or the specified target filesize).

So if you specify 500 kbps for the first pass, then you will get a 500 kbps file after that first pass.

And of course you still get a 500 kbps file after the second pass, unless you changed the target bitrate between the passes (which generally is NOT recommended).

We don't need 2-Pass to hit a specific (average) bitrate or filesize! 1-Pass ABR can do that just fine!

The one and only purpose of 2-Pass encoding is to improve the bitrate distribution within the file - under the given target bitrate restriction.

So a 2-Pass encode gives significant better quality than a 1-Pass ABR encode of the same size (bitrate). But a thrid pass won't improve the quality any further!

And yes, I'd consider three passes more "useless" than ME TESA. Anyway, I wouldn't use ME TESA, unless I had a lot of time to waste ;)

Significant correction:
If there is a specific bitrate you need to stay below, at the expense of quality, don't use CRF. Otherwise, use CRF.

In fact if you need to stay below a certain maximum bitrate, then VBV is needed (either 2-Pass or CRF).

2-Pass alone (without VBV) will hit the target average bitrate exactly, not just stay below it. But there may be bitrate spikes MUCH higher than the target (average) bitrate!

[kemuri-_9]

That won't happen. Even with only the first pass, x264 will hit the specified target avarage bitrate (or the specified target filesize).

So if you specify 500 kbps for the first pass, then you will get a 500 kbps file after that first pass.

that's technically incorrect.
1pass ABR is allowed to fluctuate from the given bitrate based on the value of ratetol.
if you throw ratetol up to something beyond the default value of 1, you allow it to diverge even farther away from the given bitrate.

[LoRd_MuldeR]

that's technically incorrect.
1pass ABR is allowed to fluctuate from the given bitrate based on the value of ratetol.
if you throw ratetol up to something beyond the default value of 1, you allow it to diverge even farther away from the given bitrate.

I know. But the divergence allowed for 1-Pass ABR is pretty small in fact. And as you said, it can be tweaked if needed (in both directions).

The default value allows a divergence of 1%. So if you specify 500 kbps, you will end up with 505 kbps in worst case...

[10L23r]

uhm... ya 1%... how about 10%??

using r1165 from x264.nl:
x264.exe --bitrate 500 --pass 1 --ref 4 --mixed-refs --bframes 6 --
b-adapt 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --subme 7 --trelli
s 2 --psy-rd 1.0:0.1 --8x8dct --me umh --threads 1 --thread-input --progress --
no-psnr --no-ssim --partitions all --output "huh.264" "bbb.avs"
avis [info]: 640x352 @ 24.00 fps (241 frames)
x264 [info]: using cpu capabilities: MMX2 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: slice I:7 Avg QP:27.10 size: 15493
x264 [info]: slice P:100 Avg QP:30.12 size: 4086
x264 [info]: slice B:134 Avg QP:31.63 size: 1257
x264 [info]: consecutive B-frames: 7.7% 37.6% 38.5% 5.1% 8.5% 2.6% 0.0%
x264 [info]: mb I I16..4: 15.7% 70.9% 13.4%
x264 [info]: mb P I16..4: 2.0% 5.7% 0.4% P16..4: 44.1% 12.8% 9.4% 0.2% 0
.3% skip:25.0%
x264 [info]: mb B I16..4: 0.3% 0.4% 0.0% B16..8: 39.5% 1.1% 1.6% direct:
2.8% skip:54.3% L0:37.1% L1:58.6% BI: 4.3%
x264 [info]: final ratefactor: 27.47
x264 [info]: 8x8 transform intra:69.3% inter:64.1%
x264 [info]: direct mvs spatial:94.8% temporal:5.2%
x264 [info]: coded y,uvDC,uvAC intra:47.5% 71.2% 40.4% inter:12.7% 16.2% 2.5%
x264 [info]: ref P L0 76.3% 12.6% 7.2% 3.9%
x264 [info]: ref B L0 86.5% 9.6% 3.9%
x264 [info]: ref B L1 93.6% 6.4%
x264 [info]: kb/s:546.2

encoded 241 frames, 6.05 fps, 546.77 kb/s

ok, i did pick a pretty damn complex scene from bigbuckbunny... but still, how would u explain this???

[LoRd_MuldeR]

241 frames is far too short. Use some source of reasonable length...

[10L23r]

so that's why... how long should the scene be?? is 1000 frames ok?

[LoRd_MuldeR]

so that's why... how long should the scene be?? is 1000 frames ok?

Something like 5000 frames should be okay, I think. But on a full-length movie 1-Pass ABR should perform even better...

[kemuri-_9]

Something like 5000 frames should be okay, I think. But on a full-length movie 1-Pass ABR should perform even better...

abr isn't guaranteed to be accurate for longer sequences either.
i easily/usually get +3-5% variance even with ratetol set to 1 on 30K - 40K frame sequences

[10L23r]

abr isn't guaranteed to be accurate for longer sequences either.
i easily/usually get +3-5% variance even with ratetol set to 1 on 30K - 40K frame sequences

i think that ratotol's value is not a percentage but something else...

but abr should be more accurate on long sequences cus the effects of outlier groups of frames decrease

[LoRd_MuldeR]

i think that ratotol's value is not a percentage but something else...

Well, the x264 developer once said it's percentage:

Bitrate Variance (--ratetol) only affects 1pass ABR. ABR's goal is: get as close as possible to CRF's quality, while still being somewhere near the target filesize. The more you restrict the filesize, the more CBR compromises it has to make in order to be sure it's within the tolerance. 1% is already pretty restricted, though still much better that CBR. (note: the effective range isn't unlimited. --ratetol inf is still usually within +/- 30%, and is still not as good as CRF)

BTW: Even a divergence of 3-5% is pretty small for a 1-Pass encode.

You definitely won't get ~2000 kbps, if you specified 500 kbps, as suspected in this (http://forum.doom9.org/showpost.php?p=1297505&postcount=14) post! That would be a divergence of 300% ;)

[10L23r]

ok fine, whatever :) i was just kinda confused... i don't need 1% or anything on a first pass anyway.

now my question is: is NOT using turbo settings in the first pass comparable to using me-tesa in terms of the quality/speed tradeoff?

[LoRd_MuldeR]

now my question is: is NOT using turbo settings in the first pass comparable to using me-tesa in terms of the quality/speed tradeoff?

Both, not using "fast" settings in the first pass -and- using TESA in the final pass, takes a lot of additional encoding time for very minor (if at all) quality improvement.

You probably couldn't tell the difference by looking at the results! So don't consider using any of them, unless you have a lot of time to waste...

[j8ee]

/.../ It's also possible to run the first pass of a 2-Pass encode with CRF mode (instead of ABR mode), but the second pass will be ABR again (with the target bitrate that resulted from the first CBR pass). But I say it again: This kind of "2-Pass CRF" makes only sense, if you want to use CRF mode with VBV (because VBV doesn't perform well with a single pass). /.../

I've come across this a few times now, but I can't find any info about how the VBV restraints should be used in this case. Should they be in the first preparing crf pass, the following second pass, or maybe both passes?


/.../Many options (for example the ones MeGUI lowers in "Turbo" mode) can be lowered safely in the first pass, with no noticeable (or negligible) effect on the second pass.

1. the .stats file is less accurate cus of the fast settings' intrinsic inaccuracy
2. when using fast settings, the final bitrate of the first pass varies more greatly from the specified bitrate than when using slow settings. [questions inserted for easier reading]

1) Yes. But the difference in stats file "accuracy" usually is too small to be noticeable in the final encode (second pass).

2) 2-Pass will always hit the desired target bitrate, even when using "fast" settings. Using faster settings (in the final pass) will only lower the "quality per bit".

BTW: You can even use a bitrate for the second pass that differs from the bitrate that was used for the first pass. x264 will still hit the target bitrate!
But be aware: The bigger the bitrate difference (first pass vs. second pass), the more quality will suffer. Ideally use the same bitrate for both passes.

Ah, many thanks for bringing clarification about that! I've been curious about both the difference in stats file accuracy and eventual difference in bitrate differences between first and second pass.

I just noticed that x264 uses some kind of "turbo/fast" mode by default now in the first pass. It made me a little nervous before I checked the forum and read x264 presets, profiles, and tuning system (http://forum.doom9.org/showthread.php?t=148149). Made me relax... I've started to trust these developers and their defaults more and more - they're pretty smart! :)

[LoRd_MuldeR]

I've come across this a few times now, but I can't find any info about how the VBV restraints should be used in this case. Should they be in the first preparing crf pass, the following second pass, or maybe both passes?

In the second pass you will need to set the VBV parameters for sure, if you want your final output to be VBV conformant ;)

I'm not so sure about the first one. But you probably get a more accurate stats file, if you use the same VBV parameters in the first pass too...