陈钢的博客 ? x264

2010年7月19日

x264的码率控制是基于libavcodec和经验的。这篇文章将尝试说明复杂的码率控制算法背后的理论基础。

几点理论：

1、固定质量并不等价于PSNR或QP完全恒定。复杂场景或者高速场景中难以辨别的细节会被选择性省略，以节省空间；
2、如果运动预测生效，将获得更好的质量：低速场景中，1个错误可能停留好几秒钟。此时如果运动预测启用，只需要更改一个帧，就能增进整个场景的质量；
3、如果有一个帧的一个QP的编码结果，就可以预测这个帧其它QP编码将消耗的空间。QP差距越大，预测越不准确；
4、帧的重要性取决于参照它的帧的数量。因此I帧将根据最近的可被参考帧的复杂程度来调正自己的QP。用作参考帧的B帧（自由B帧）的QP高于P帧，参考的B帧的QP则介于P帧和用作参考帧的B帧之间。

几种码率控制模式：

2pass：指定目标码率，2趟编码
在第1趟编码（比如下面提到的ABR）时为每一帧生成一些统计信息，以助在第2趟编码中时为每一帧找到最好的量化参数。第2趟编码包含以下三部分：
1、第2趟编码开始之前，拿出一些空间用于在帧间灵活分配。空间大小的计算与目标码率无关，只是一个使用恒定QP编码的码率的比值，一般是0.6；
2、用(1)得出来的值和目标码率计算每一帧要使用的QP。使用VBV是方法之一，VBV是一个迭代的过程，因为使用VBV和QP会互相影响；
3、现在开始编码。每编完一帧，按照还剩下的空间重新计算后面将要使用的QP，如果编码过程中第2趟编码的实际码率偏离了目标码率（因为第二趟编码用了更慢的参数）（译者按：也就是使用了快速第一趟编码，所以通常是低于目标码率），会在随后的帧里做出变化（译者按：通常是增大码率）以纠正错误趋势。另外，还会有个小处理，会保证我们不在视频的开始或结束的阶段远远偏离目标码率。

ABR：1趟编码，平均码率
目标是达到和2趟编码同样的效果，但没有第1趟编码的帮助，所以只能一边编码一边控制码率：
1、和2趟编码的(1)过程一样，但因为没有第1趟编码的帧信息，所以把帧缩小为一半分辨率后用一个快速预测算法和SATD（译者按：sum of absolute transform differences绝对变换差值和）（此计算也用于P帧B帧决策）做一个预测来代替。而且也不知道后面的GOP（译者按：图像组）的大小和复杂度，所以I帧的决策基于之前的帧；
2、因为不知道后面帧的复杂度，所以只根据前面的帧来测算QP。测算的因数将定为如果应用于目前所有帧则可以满足目标比特率的数；
3、和2趟编码一样有溢出补偿，调节补偿力度可以得到很接近2趟编码的质量（但大小将在接近正负10%的范围内浮动），通过这种方式可以在一定程度上控制住文件大小而又不太牺牲视频质量。

CBR：1趟编码，恒定码率（用VBV限制）
1、同ABR；
2、测算因子基于一个范围内（由VBV buffer大小决定）的均值，而不是之前所有帧；
3、溢出补偿更加严格，而且在VBV接近0时将会强制限制QP。但在VBV没用完时并不会强制限制QP，所以CBR的结果多少会比目标码率低一点。还要注意的是，如果在所有机制过后，一个帧还是超出了VBV的限制，那它是不会被重新编码的。

CRF：1趟编码，恒定码率因子（译者注：就是crf参数，crf = constant rate factor）
1、同ABR；
2、换算因子恒定为 –crf参数的值；
3、没有溢出补偿。

CQP：恒定量化参数
QP只简单地和帧类型相关。

以上所有类型：
H.264规范允许每个宏块使用不同的QP。x264目前没有实现这一特性，码率控制算法只会为每一帧生成一个QP。

翻译自：http://git.videolan.org/?p=x264.git;a=blob_plain;f=doc/ratecontrol.txt;hb=HEAD

翻译 x264, 比特分配, 码率控制, 翻译, 视频, 视频编码

FLV及各profile的x264编码速度对比

2010年6月28日

没有评论

除了必要的feature option，其它选项都选择了比较偏向质量的选择，使用单线程单趟对一个88m的新闻类mpg文件编码。

编码时间如下：
FLV 1分53秒 113秒 (psnr Y:28.31 ALL:29.53)
Baseline 3分57秒 237秒
Main 5分41秒 341秒
High 6分2秒 362秒

顺便看一下subq和me对编码时间的影响。
把前面subq=7和me=umh的High Profile改为subq=6和me=dia以后：
High Profile： subq=6:me=dia 4分17秒 257秒 (psnr 32.57)
High Profile： subq=5:me=dia 3分27秒 207秒 (psnr 32.59)
High Profile 2pass： subq=5:me=dia:turbo=2 4分11秒 251秒 (psnr 32.88)

Main Profile： subq=6:me=dia 4分5秒 245秒 (psnr 32.43)

Baseline Profile： subq=7:me=umh 3分58秒 238秒 (psnr 30.90)
Baseline Profile： subq=6:me=dia 2分57秒 177秒 (psnr 30.84)
Baseline Profile： subq=5:me=dia 2分40秒 160秒 (psnr 31.04) (subq=5会导致trellis=2失效)
Baseline Profile 2pass： subq=5:me=dia:turbo=2 3分21秒 201秒 (psnr 31.15)

可见，subq和me对编码速度的影响比profile还要厉害。

CPU是一颗3.00GHz的Xeon，此次测试中的时间均为不计算psnr的时间，若计算psnr将约增加1秒长的时间。部分实验数据如下：

查看源码

打印帮助

01	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -o 2.avi -of lavf -nosound -ovc lavc -lavcopts vcodec=flv:vbit<wbr>rate=400:mbd=2:<wbr>mv0:trell:v4mv:<wbr>cbp:last_pred=3<wbr>

02	real    1m52.594s

03	user    1m52.272s

04	sys     0m0.314s

05

06	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:noc<wbr>abac:weightp=0:<wbr>no8x8dct:bframe<wbr>s=0:weight_b:mi<wbr>xed-refs:trelli<wbr>s=2:partitions=<wbr>all:me=umh:subq<wbr>=7:threads=1

07	real    3m57.288s

08	user    3m56.771s

09	sys     0m0.456s

10

11	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:cab<wbr>ac:weightp=2:no<wbr>8x8dct:bframes=<wbr>3:weight_b:mixe<wbr>d-refs:trellis=<wbr>2:partitions=al<wbr>l:me=umh:subq=7<wbr>:threads=1

12	real    5m41.048s

13	user    5m40.507s

14	sys     0m0.470s

15

16	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:cab<wbr>ac:weightp=2:8x<wbr>8dct:bframes=3:<wbr>weight_b:mixed-<wbr>refs:trellis=2:<wbr>partitions=all:<wbr>me=umh:subq=7:t<wbr>hreads=1

17	real    6m1.585s

18	user    6m1.050s

19	sys     0m0.479s

20

21	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:cab<wbr>ac:weightp=2:8x<wbr>8dct:bframes=3:<wbr>weight_b:mixed-<wbr>refs:trellis=2:<wbr>partitions=all:<wbr>me=dia:subq=6:t<wbr>hreads=1

22	real    4m17.232s

23	user    4m16.680s

24	sys     0m0.518s

25

26	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:cab<wbr>ac:weightp=2:8x<wbr>8dct:bframes=3:<wbr>weight_b:mixed-<wbr>refs:trellis=2:<wbr>partitions=all:<wbr>me=dia:subq=5:t<wbr>hreads=1

27	real    3m27.635s

28	user    3m27.140s

29	sys     0m0.485s

30

31	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:noc<wbr>abac:weightp=0:<wbr>no8x8dct:bframe<wbr>s=0:weight_b:mi<wbr>xed-refs:trelli<wbr>s=2:partitions=<wbr>all:me=dia:subq<wbr>=6:threads=1

32	real    2m57.230s

33	user    2m56.772s

34	sys     0m0.447s

35

36	[root@localhost<wbr> bvideo]# time mencoder 1.mpg -nosound -o 2.avi -ovc x264 -x264encopts bitrate=400:noc<wbr>abac:weightp=0:<wbr>no8x8dct:bframe<wbr>s=0:weight_b:mi<wbr>xed-refs:trelli<wbr>s=2:partitions=<wbr>all:me=dia:subq<wbr>=5:threads=1

37	real    2m39.449s

38	user    2m38.969s

39	sys     0m0.468s

实验 h264, profile, x264, 编码速度

如何用mencoder编出High\Main\Baseline的H264视频

2010年6月28日

没有评论

从上往下判断：

1、开启8x8dct，则视频为High。
2、开启以下任意一项weightp\cabac\bframes，则视频为Main。
3、以上项皆关闭，则视频为Baseline。（no8x8dct:nocabac:weightp=0:bframes=0）

p.s. 旧版本的mencoder不支持weightp，所以不用设置它。

实践 baseline, high, main, mencoder, x264

隐藏h264视频中的x264版本和编码设置

2010年6月28日

7 条评论

用MP4Box抽出纯h264的视频后，可以如下隐藏x264版本和编码设置：

查看源码

打印帮助

01	#! /usr/bin/env perl

02

03	my $h264file = shift;

04

local $/;

05	open my $fh,"<",$h264fi<wbr>le;

06	my $bin = <$fh>;

07

08	my $reg = qr(x264[\w\d\s\<wbr>=\:\_\-\,\.\/\\<wbr>]*);

09	my ($str) = $bin =~ /($reg)/;

10

11	$str =~ s/./ /g;

12	$bin =~ s/$reg/$str/;

13

14	close $fh;

15

16	open $fh,">",$h264fi<wbr>le;

17	print $fh $bin;

18	close $fh;

MP4Box和mp4tags都无力做到这件事，这玩意儿不是iTunes-tags。

实践 h264, perl, x264, 编码设置

H264视频编码和解码速度的比较

2010年5月26日

没有评论

结论

H264视频解码的速度是编码速度的约20倍。

如果有硬解码设备参与，这速度比率还会成倍扩大。

实验

在没有显卡的Server上：

查看源码

打印帮助

1	time mencoder 1.mpg -ovc raw -of rawvideo -nosound -o 1.raw

2	user    0m3.706s

3	sys     0m1.704s

4

5	time x264 -o 1.h264 --fps 25 --bitrate 500 1.raw  600x450

6	user    1m6.952s

7	sys     0m0.641s

以上的实验中编码速度为解码速度的8%。编出的文件为H264 Main。

考虑到我们编码的一大堆参数，而且又加上二次编码。解码速度应该不到编码速度的5%。

顺便一提

H264 Main 释放出来的raw文件是原来的50倍大。
MPEG 释放出来的raw文件是原来的15倍大。

实验 x264, 视频编码

x264屏幕输出信息的解释

2010年5月17日

没有评论

avis [info]: 1280×544 @ 23.98 fps (239470 frames)

输入文件的分辨率、帧率、总帧数

x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!

CPU中可被x264使用的指令集

x264 [warning]: VBV maxrate specified, but no bufsize.

定义了码率，没定义缓冲区的警报。如果是为特定设备编码，可指定一个缓冲区大小。

mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:2323 Avg QP:19.01 size: 78885a 0:00:00
x264 [info]: slice P:101512 Avg QP:21.38 size: 28261
x264 [info]: slice B:135635 Avg QP:22.36 size: 9179

每种帧使用的数量，平均量化参数。更小的量化参数一般意味着更多的码率占用和更好的质量。

x264 [info]: mb I I16..4: 19.1% 75.0% 5.9%
x264 [info]: mb P I16..4: 6.8% 17.0% 1.1% P16..4: 36.9% 6.0% 7.8% 0.0% 0.0% skip:14.4%
x264 [info]: mb B I16..4: 0.3% 1.0% 0.2% B16..8: 26.6% 2.0% 4.4% direct: 4.5% skip:61.0%

各种块类型的使用。这里显示了5.9%的I帧使用了4×4的块。这个是-partitions参数控制的。

x264 [info]: 8×8 transform intra:68.8% inter:73.5%

转换中开启了-8x8dct参数。显示8x8DCT变换的使用程度。

x264 [info]: coded y,uvDC,uvAC intra: 32.1% 39.2% 15.9% inter: 17.9% 13.6% 1.5%

至少含有一个DCT系数的8x8dct变换块的内部块或者交 错块的亮度(y)，uvDC,uvAC的比率。

x264 [info]: direct mvs spatial:96.3% temporal:3.7%

如果使用了默认的–direct auto，这里显示spatial和temporal的使用量。

x264 [info]: ref P 68.0% 17.8% 6.6% 4.6% 2.9%
x264 [info]: ref B 83.3% 10.7% 2.9% 1.9% 1.2%

5个百分数说明编码时设置了frameref=5，这里是显示分别在P帧和B帧时使用每个参照帧的频率。这对观察具体设置多少个参照帧很有用。

x264 [info]: kb/s:3441.8

编码出的H264的最终码率。

encoded 239470 frames, 3.55 fps, 3441.84 kb/s

总帧数，编码速度（每秒 编了多少帧），总帧率

翻译自：http://forum./showthread.php?t=129491#post1039674

翻译 x264, 视频编码

如何设置编码降低H264解码时的CPU占用

2010年5月17日

没有评论

以下三个参数是影响解码CPU占用的主力：

码率、帧率、帧尺寸。

如果使用x264编码。可以使用–tune fastedecode选项方便地编出更容易解码的视频文件。

实践 x264, 视频编码

x264命令行参数优先级

2010年5月17日

没有评论

preset -> tune -> user set options -> fast first pass -> profile -> level

来自J_Darnley的测试。

转载 x264, 视频编码

x264起多少个线程比较好

2010年5月16日

没有评论

建议线程数：

1、2、4、8

测试结论：

1、更多的线程会消耗更多总CPU时间片，因此在长期满载的机器上不宜使用多线程。

2、获得的时间收益随线程增多呈递减趋势，8线程以后尤为明显。

3、PNSR下降随线程数增加呈抛物递增趋势，16线程增加到24线程PSNR时下降了0.6之巨。

4、设置threads=auto时，线程数为逻辑CPU个数的1.5倍。

附加一个小Tip：

如果启用了turbo特性，那么无论设置threads为多少，mencoder都只将最多启动6个线程用于第1阶段编码。

部分测试数据：

测试机器配置为：Xeon  E5520（8核+超线程），内存12G。

threads = 1:
x264 [info]: SSIM Mean Y:0.9719788
x264 [info]: PSNR Mean Y:38.438 U:43.524 V:41.191 Avg:39.352 Global:38.796 kb/s:401.41

real    0m45.528s
user    0m45.486s
sys     0m0.047s

threads = 2:
x264 [info]: SSIM Mean Y:0.9719308
x264 [info]: PSNR Mean Y:38.434 U:43.525 V:41.228 Avg:39.353 Global:38.806 kb/s:401.40

real    0m26.281s
user    0m46.744s
sys     0m0.086s

threads = 4:
x264 [info]: SSIM Mean Y:0.9718774
x264 [info]: PSNR Mean Y:38.429 U:43.508 V:41.222 Avg:39.348 Global:38.817 kb/s:401.11

real    0m14.951s
user    0m47.585s
sys     0m0.117s

threads = 8:
x264 [info]: SSIM Mean Y:0.9716865
x264 [info]: PSNR Mean Y:38.397 U:43.480 V:41.171 Avg:39.313 Global:38.802 kb/s:400.77

real    0m8.368s
user    0m48.637s
sys     0m0.093s

threads = 12:
x264 [info]: SSIM Mean Y:0.9713859
x264 [info]: PSNR Mean Y:38.311 U:43.417 V:41.130 Avg:39.235 Global:38.734 kb/s:400.34

real    0m7.209s
user    0m51.494s
sys     0m0.110s

threads = 16:
x264 [info]: SSIM Mean Y:0.9706691
x264 [info]: PSNR Mean Y:38.198 U:43.415 V:41.077 Avg:39.136 Global:38.607 kb/s:399.22

real    0m6.962s
user    0m52.314s
sys     0m0.121s

threads = 24:
x264 [info]: SSIM Mean Y:0.9686221
x264 [info]: PSNR Mean Y:37.972 U:43.254 V:40.949 Avg:38.914 Global:38.071 kb/s:400.82

real    0m6.927s
user    0m53.975s
sys     0m0.116s

threads = auto:
x264 [info]: SSIM Mean Y:0.9686221
x264 [info]: PSNR Mean Y:37.972 U:43.254 V:40.949 Avg:38.914 Global:38.071 kb/s:400.82

real    0m6.941s
user    0m53.422s
sys     0m0.144s

实践 1pass, threads, x264, 视频编码

mencoder的x264encopts选项参数略解

2010年5月7日

没有评论

概要

这份指南主要介绍两类编码选项：
第一类，主要对速度质量平衡造成影响的选项；
第二类，可以满足个性化需求的选项。

要注意的是，虽然不是主要目的，第二类选项同样会对速度和质量造成很大的影响。这类选项可能导致有人觉得视频质量提升了，有人觉得视频质量下降了。

继续之前还有两点要说明：
1、这份指南只以一个指标作为视频质量的标准：全局PSNR（峰值信噪比），也就是在x264encopts选项中带上PSNR参数后输出的数值。所有的PSNR都是以相同码率为前提假定条件的。
2、所有的选项介绍以使用2次编码为条件。使用2次编码有两个原因：第一，2次编码能提高1db的PSNR（很大的提升）；第二，2次编码能避免1次编码一个很大的缺点：相当大的随机性的存在导致难以分辨质量变化是随机性造成的还是改变参数造成的。

主要影响编码速度和质量的参数

1、subq。它和下面的frameref是目前对编码速度和质量造成最大影响的两个参数。

如果是要在速度和质量牺牲一者换取另一者，它们是首先要被考虑到的选项。在速度方面，这两个选项间的相互影响也很大。经验指出，当frameref=1时，subq=5（默认值）要比subq=1多花出35%的时间。在frameref=6时，这个数值则超过60%。

不管frameref怎样设置，subq对PSNR的影响是恒定的。通常subq=5会比subq=1带来0.2-0.5db的PSNR提高，这是相当可观的提高。

subq=6更慢一些，但会换来值得的质量提升。通常它比subq=5多耗时25%-100%，同时带来0.1-0.4db的PSNR提高。subq=6和其它选择有个不同的地方，它不依赖frameref和me参数的设置，它主要依赖B帧的数量。这意味着它在激烈运动和碰撞的场景中会很有效，而对缓和的场景则起不到太大作用。不管怎样，建议不要把bframes设置为0（禁用B帧）。

subq=7是最慢质量最好的选择。它用比subq=6多出15%-33%的耗时换回0.01-0.05db的质量提升。若你非常不介意时间开销而且想充分利用每个比特时，选择它。

2、frameref。它的默认值是1，但不意味着1是最合理的值。

把frameref调整到2就可以马上获得0.15db的提升而仅仅只需要多付出5%-10%的时间开销，这是个不错的交易。frameref=3能比frameref=1多耗时15%，PSNR提高0.25db。

不幸的是，从3开始，收益开始迅速递减。frameref=6比frameref=3多耗时15%而只能带来0.05-0.1db的质量提升。比6更大的值只能带来非常少的质量提升（当然，和视频源有关系）。一般情况下，frameref=12比frameref=6多耗时15%-20%，而全局PSNR仅提高0.02db。

但无论frameref调得再高，它不会损伤PSNR，只是带来的提升很微小罢了。

目前，如果把frameref调高到不必要的非常高的值，那它只在关闭CABAC时才会影响编码速度，当打开CABAC时则不用担心。将来，关闭CABAC选项时的编码速度可能也会被优化，

如果十分在意编码速度，可以在第一次编码中调低subq和frameref的值，在第二次编码中调高它们（可以用方便的turbo参数），这样做会带来0.1db的PSNR损失，基本看不出来对画质的损伤。

frameref可能偶尔会影响到帧类型的决策，虽然非常少见，但如果要完全避免，那就去看看视频中是否有全白或者全黑的场景导致强制输出了I帧，调整第一次编码的frameref值，使它的值要大于连续全屏闪烁或全黑的帧数。比如，如果视频的5帧是在2个画面之间来回闪烁，那就应当把frameref设置为5或更大。这种情况在真实视频中很少发生，大多是游戏截出来的视频。

3、me。这个选项用于选择运动估计搜索算法。它直接影响编码速度和编码质量的平衡。

me=dia比默认选项（me=hex）只快一点点，带来0.1db的全局PSNR损失。默认选项me=hex在速度和质量间获得了不错的平衡。me=umh可以提高全局PSNR0.1db，它的速度损失取决于frameref的值。frameref=12时，me=umh比me=hex慢40%，frameref=3时，me=umh比me=hex慢25%-30%。me=esa使用穷举算法，对实际应用来说，它太慢了。

4、partition=all。这个选项会在默认值的基础上多开启8×4、4×8、4×4这3种预测宏块类型，它会带来10%-15%的速度损失。当视频源中的运动缓慢时，它几乎没用。但在饱含很多小物体的高速运动场景的视频源中，我们可以期望它带来0.1db的提升。

5、bframes。如果用其它编码器编码，会发现B帧不是很有用。这个状况在H.264中得到了改善，它为B帧引入了很多新技术和块类型。

B帧对提高PSNR有重大作用，而且有趣的是，使用B帧会稍稍加速第2次编码，而在1次编码中，开启自适应B帧决策则会减速。如果关闭自适应B帧检测(nob_adapt)，则bframe最好设为1，不然高速场景将会很惨。自适应B帧检测默认是开启的，此时把bframes设为较高的值是安全的，在会损伤压缩效果时，编码器会自动减少B帧的使用。编码器一般不会选择大于4的B帧，把这个值稍微设高点能得到一些效能提升。

6、b_adapt。默认开启，此时编码器将用一个较快的判定过程来排除那些不能带来足够质量提升的B帧生成。

可以使用b_bias选项调节排除的阈值。此选项牺牲的速度还算合理，而且它只会提升而不会损伤视频质量。要注意的是，b_adapt和b_bias只在第一次编码时影响速度和帧类型，对后续的编码不产生影响。

7、b_pyramid。如果bframes选项大于等于2的话，最好也开启此选项，它能在不增加时间开销的同时提升一些质量。要注意的是，开启此选项编码的视频不能被基于2005年3月5日之前的libavcodec核心的解码器解码。

8、weight_b。这个选项通常不会带来什么好处，但在渐变和淡入淡出的场景中，基于权重的预测可以很大地增加压缩比。

在MPEG-4 ASP中，类似的场景会用一连串昂贵的I帧来编码，开启本选项的话，就可能把其中很大一部分用小很多的B帧代替。因为决策过程并不复杂，所以时间开销也很小。而且和很多人幻想地不同的是，解码时也不怎么影响CPU开销。不幸的是，目前的自适应B帧决策算法恰恰强烈倾向于在淡入淡出时避免使用B帧，这样这个选项也就失效了。因此，在当前版本，如果想要把淡入淡出压缩好，需要设置nob_adapt。

9、threads。此选项可以在多核CPU的机器上开启多线程以加快编码速度。可以手动指定线程数，更好是设置threads=auto让x264自己侦测并决定使用多少个线程。如果使用多核机器，此选项可以依据CPU核心个数线性地加速编码时间（每个CPU核心约94% ）。使用多核特性会稍微降低视频质量（双核约降低0.005db，4核约降低0.01db）。

个性化选择的参数

1、2次编码。

本文一开始建议始终开启2次编码，但是也还是有一些不能使用它的时候。比如说实时编码电视信号时，就只能使用1次编码了。而且1次编码也明显比2次编码快，几乎只花费2次编码的一半时间。

再反过来继续说说2次编码的好处。因为1次编码无法对视频有整体把握，所以它的码率控制只能十分保守。比方说编码一个2分钟的视频，这个视频的前1分钟充满了激烈的运动，需要2500kbps的码率才能得到良好的观看效果，而随后的1分钟视频只需要300kbps的码率就能得到很好的观看效果了。其实此时平均1400kbps的码率就足以让整个视频看起来很好了。但由于缺乏对视频的整体把握，1次编码会在视频的前1分钟和后1分钟同样使用1400kbs的码率，这样就导致前1分钟的视频观看质量不可接受而后一分钟又产生严重的码率浪费。怎么适当地使用码率对1次编码是个难题。也有一些解决这个难题的办法，但他们都会导致另一个难题：码率有可能会不可控制地增大。

多次编码能对码率分配产生非常大的好处。由于有了从第一次编码中得到的对视频的整体把握，编码器就有了控制帧的使用和量化精度调整的依据，进而就可以更合理地在更需要码率和更不需要码率的视频片段间分配码率的利用。下面将要介绍的qcomp就是用于按照我们的喜好调节这个分配的力度的。

另外，2次编码并不真的要花费2倍于1次编码那么就的时间。第一次编码并不需要太高的质量，如果配置合适，第1次编码可以很快。当然更快的第1次编码会稍稍降低预测的精度从而稍稍影响最终的编码质量，但这个影响通常小到难以察觉。可以试试这个例子：使用参数subq=1:frameref=1进行快速第1次编码，然后使用subq=6:frameref=15:partitions=all:me=umh进行很慢的但高质量的第2次编码。

2、3次编码。

x264可以进行任意次数的连续编码。如果第一次编码时设置pass=1而在随后的编码中设置pass=3，则随后的编码会读取前一次编码的统计信息并记录下新的统计信息，然后再随后的编码会得到更加精确的信息用于决策帧使用和量化精度。

但在实际应用中，这样做所带来的提升几近于0，还很有可能第3次编码的全局PSNR还稍低于第2次编码的全局PSNR。推荐只在2次编码确实没有控制好码流率或者视频质量不合理的低下时才使用3次以上的编码，这种情况通常只在编码非常非常短的视频时发生。

对于高级用户而言，3次以上的编码还有另外一些特殊用途，但这已超出这份指南的范围。

3、qcomp。用于调节在视频片段间转移码率的力度。

一个极端就是设置qcomp=0，这样就完全关闭了在视频片断间转移码率，会导致快速运动的视频片断看起来很糟，而缓慢的视频片断浪费码率的问题。另一个极端是设置qcomp=1，这样会产生恒定的QP（量化参数）。这没太大坏处，但很多人认为还是稍稍限制一下那些极度需要使用码率的视频片断对码率的获取，这样对整体视频的质量提升比较好。

qcomp=0.6是默认值，大部分人都会觉得这个值有点偏低（常用0.7-0.8）。

4、keyint。这是唯一平衡编码效率和视频可拖动程度的选项。

默认值是250，这意味着在1个25fps的视频中，至少可以以10秒为单位拖动。如果想要以5秒为单位拖动，那就把这个值设置为125，这样会稍稍损伤视频质量。如果完全不关心视频的可拖动性，把这个值设超大也没有关系（注意收益是会递减的，直至0）。即使这样，视频也会在场景转换的地方留下可拖动的点。

5、deblock。该参数调整的是H.264内循环反块效应滤镜所用的阈值。

这是这篇指南中唯一一个稍微有些争议的参数。H.264标准中定义了一个简单的反块效应的滤镜，并且有预制好的阈值和过滤强度，这个阈值是以块的QP（量化参数）为标准的。

此滤镜默认的行为是大力过滤QP高的块而完全放过QP低的块。预制的强度是H.264标准定义的，这个强度是仔细选择的结果，通常它对所有视频都可以起到很好的效果。可以通过deblocl参数重设此阈值。

一些人认为应该大幅度调低过滤强度（比如把deblock设置为-3）。这绝不是一个好主意，大多数这么干的人并没有完全理解反块效应滤镜在默认状态下是怎么工作的。

首先且必须知道的是，这个内循环反块效应滤镜在默认状态下是以PSNR为优化目标的，而且优化地非常好。即使它没做好，使用deblock=1或者deblock=-1微调它就足够了。更大幅度的调整是绝对会损伤PSNR的。

正值会导致滤镜干掉更多视频细节，而负值会导致更多可见的块效应。

如果视频源不是空间复杂度很高（充满了细节）的话，调低deblock的值会是个坏主意。内循环反块效应滤镜把人工处理的痕迹处理得非常好。如果视频源在空间上十分复杂，块效应就会相对弱很多。这是因为人总是更容易把注意力放在细节或者噪音上。人类视觉体系很容易发现移动的细节，而不容易发现静止的噪音。当然主观判断时，细节和噪音也许是一回事。所以，如果降低反块效应的强度，虽然同时增加了噪音和细节，但人眼却难以发觉那些参杂在细节中的噪音。

以上并非说明调低反块效应滤镜的强度就是绝对正确的了。

我们还能在后续处理中进一步处理噪音。如果H.264编码器出来的结果看上去模糊而且有点脏脏的，可以试试在播放视频时加上-vf noise滤镜。-vf noise=8a:4a几乎可以隐藏所有噪音，这个设置几乎总是能得到比只是来回调校deblock更好的观看效果。

几个例子

以下参数演示了在目标码率相同时几个在编码速度和质量间取得的不同平衡。

测试环境：
视频源：720×448@29.97fps，目标码率900kbps，AMD64 3400+ 2.4Ghz 64位模式。

注意1：表格第三列的PSNR数值是以[超高质量]为基准比较的（这也是它的此项为0的原因）。
注意2：不同视频源、转码机器和软件版本都可能造成很不同结果。

类型	参数选择	每秒编码帧数	相对 PSNR 损失
超高质量	subq=6:partitions=all:8x8dct :me=umh:frameref=5:bframes=3: b_pyramid:weight_b	6fps	0dB
高质量	subq=5:8x8dct:frameref=2: bframes=3:b_pyramid:weight_b	13fps	-0.89dB
快速	subq=4:bframes=2:b_pyramid:weight_b	17fps	-1.48dB

本文翻译自：http://www.mplayerhq.hu/DOCS/HTML/zh_CN/menc-feat-x264.html?