关于2PASS和CRF的比较

[gmail123]

最近纠结于2PASS和CRF的比较，什么时候适用2PASS，什么时候适用于CRF。2PASS是定码率，体积恒定，容易控制大小，CRF是似乎更注重动态场景下的码率分配。

我的问题是，哪些片源更适合于2PASS，哪些适合于CRF；假设2PASS和CRF压出来的片子码率一样，质量是否相同。

各位大大有何看法

[dgwxx]

着急出片的时候、省电的时候crf，有时间的时候2pass
对了，avs 0.01fps的时候也crf

[leih116]

Dark Shikari说的：
CRF and 2-pass use identical bit allocation algorithms. All 2-pass does is pick the CRF value that gives the filesize you want. It's still using the CRF algorithm.
哪些片源更适合于2PASS，哪些适合于CRF 2pass看来要靠经验来判断合适的比特率 还是直接crf简单点
假设2PASS和CRF压出来的片子码率一样，质量是否相同 应该相同吧

[mawen1250]

在大部分编码环节2 pass和crf是完全一样的，rc过程中2 pass的码率分配结果也是趋向于crf的结果，只不过前者多了个对平均码率的限制来调整最终输出的码率。
所以如果对最终码率没有严格要求的情况下用2 pass完全没有意义，而且由于ratetol的存在还会导致视频首尾质量的不平衡。

当然，如果你1st pass crf和2nd pass bitrate都用相同的参数而且--preset placebo --ratetol inf就当我没说。

[upyzl]

有明确体积需求用2pass，其余2pass并无明显优点了（倒不如说因为一般低精度1pass的关系，以及LS马文菊苣提到的ratetol相关，以及2pass相当于多跑一遍1pass的时间，反倒是不如crf的地方很多；另外由于x264时代以前，rc方式除了2pass也就是qp或1pass br这些不够好的rc方式了，此时自然都是选择2pass最佳）

另外，要想省心的话可以这样压
1pass crf 用slow firstpass且正常输出片，不满意的话，再继续跑2pass bitrate，满意了就直接拿1pass出的片用就行了

[gmail123]

谢谢各位，基本上清楚了。前些时候看到一篇文章说CRF在大动态下情况下,编码器会倾向于分配更多码率（相比2PASS）给大动态场景，会导致静态场景较差的情况，故有此问。
现在倾向于1PASS用CRF，看情况再用2PASS，应该是比较合理的选择。

对ratetol inf参数理解不太好，“视频首尾质量的不平衡。”这样的好象没怎么见过，能举例说明一下吗？

[Billy Herrington]

about ratetol:

1. Let me read pre-pass stats file, and guess what qp for frame N should be used to match your target bitrate
2. Apply my guess
3. Oh god, my guess is not perfect, the encoded bitrate goes higher than target bitrate * ( 1 + ratetol / 100. )
4. I need to lower bitrate for the following frames
5. Let me read pre-pass stats file, and guess what qp for frame N+1 should be used to match the fixed bitrate
6. Apply my guess
7. Oh god, my guess is not perfect, I lowered the bitrate too much, the encoded bitrate goes too low below target bitrate * ( 1 - ratetol / 100.)
8. I need to raise bitrate for the following frames
9. Let me read pre-pass stats file, and guess what qp for frame N+2 should be used to match the fixed bitrate
....

Bitrate-based RC: I'm a teapot.

The bitrate correction (lowering/raising) does not always occur at the beginning/end of encoding, but with every frame on which the estimated bitrate does not match the final encoded bitrate. If in one encoding process, the encoded bitrate of first N frames stays within target bitrate * ( 1 +or- ratetol / 100. ), then none of them need a fixed RC process; then if the encoded bitrate of the N+1 frame explodes, the bitrate of the N+2 frame needs to be fxed; and if after this fixing, all the following frames are encoded with perfect RC estimation, then their bitrate will not be fixed either. So in such a case, the 'unbalance' only happens on frame N+2, but not on any frames near the start or the end.