CRF 22/18 and stat file

[Atak_Snajpera]

Can I assume that below commands will give similar stat file?

--crf 22 --pass 1 --stats somefile.log

--crf 18 --pass 1 --stats somefile.log

[MasterNobody]

What do you mean by similar? Will they produce identical stats-file => NO. Can they both be used for 2nd pass with some bitrate => YES. Which will give better quality => probably the one which will have more close bitrate to target (but this is questionable and can be wrong).

[Atak_Snajpera]

i just need to know if i can use that stat file in second pass with any bitrate without hurting quality?

[Sharc]

This question has been discussed in the forum some time ago IIRC. I tied to find the discussion but I have not been successful. DS was involved as far as I remember, and the answer is yes (no noticeable loss in quality) as long as the bitrates are not totally different between pass 1 and pass 2, say within 10%, maybe more but I am not sure.

[sneaker_ger]

You mean this one (http://forum.doom9.org/showthread.php?t=161644)?

Though the difference between CRF 18 and 22 should be "a bit" more than some 5%, I think it should still be OK.

[Sharc]

... or this one (http://forum.doom9.org/showthread.php?p=1357109#post1357109)
In example B the difference is quite significant, in the order of 50% it seems.

Added:
Somewhere else DS suggested to run pass 1 at a lower resolution (say half) in order to speed pass 1 up. I don't think that this idea has ever materialized. Would be an interesting exercise ;)

[sneaker_ger]

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=0ba8a9c6973897ec35e1a5d241a71f4f5a4f81aa

[Atak_Snajpera]

so --CRF XX --SLOW-FIRSTPASS allows to use ANY bitrate in second pass without sirious consequences ?

[Sharc]

I doubt that the --slow firstpass makes a big difference in your case for generating the stat file. The main reason for the --slow firstpass is that you get a perfect encode in 1 pass which you may keep in case the resulting file size fits your needs.

[LoRd_MuldeR]

so --CRF XX --SLOW-FIRSTPASS allows to use ANY bitrate in second pass without sirious consequences ?

I don't think this will ever be the case!

The rule of thumb has always been: It's okay to use a different bitrate in the second pass, as long as it's not "too much" different from the first pass bitrate. The more the bitrates differ, the bigger the potential quality loss (compared to re-doing both passes at the identical bitrate).

Doing the first pass in CRF mode doesn't change much, except that you don't know beforehand at which average bitrate your first pass will come out. So with CRF first pass the "reasonable" range for the choice of the second pass bitrate will be more limited (compared to choosing the target bitrate before the first pass and doing the first pass in ABR mode with that bitrate). Using "--slow firstpass" shouldn't make a fundamental difference here, I think...

[Sharc]

Resuming this old thread:
Reducing the resolution for the 1st pass like "ReduceBy2()" speeds up the 1st pass significantly. The resulting PSNR is a fraction of a dB (typ. 0.1....0.3, depending on scene) worse compared to a regular 1st pass at original resolution, in my tests.
It seems that the developers of x264 have taken care of this option:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=0ba8a9c6973897ec35e1a5d241a71f4f5a4f81aa
http://git.videolan.org/?p=x264.git;a=commit;h=dea5d7a54b5ba948ed71d74e0264a2191bcd9815