文件"/>
如何把X264输出的INFO信息保存到文件
如何把X264输出的INFO信息保存到文件原作者博客地址：/?tag=%E8%A7%86%E9%A2%91%E7%BC%96%E7%A0%81
x264的信息是往STDERR输出的，因此如下另存到文件：
| 1 | mencoder - nosound - ovc x264 - x264encopts bitrate = 475 : psnr - of avi - ofps 24 1_001.mp4 - o . / 1278491108.avi 2 > log . txt |
如果直接用x264编码的话可以这样：
| 1 2 | x264 [ options ] 2 > logfile . txt x264 [ options ] - o outfile infile 2 > & 1 | Findstr / V "frames:" > log . txt |
【 翻译 】简述x264几种码率控制方式的实现
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。
翻译自：/?p=x264.git;a=blob_plain;f=doc/ratecontrol.txt;hb=HEAD
Tags 2pass • abr • bitrate • cbr • cqp • crf • x264 • 比特分配 • 码率控制 • 翻译 • 视频 • 视频编码H264视频编码和解码速度的比较
2010 年 5 月 26 日结论
H264视频解码的速度是编码速度的约20倍。
如果有硬解码设备参与，这速度比率还会成倍扩大。
实验
在没有显卡的Server上：
| 1 2 3 4 5 6 7 | time mencoder 1.mpg - ovc raw - of rawvideo - nosound - o 1.raw user 0m3.706s sys 0m1.704s time x264 - o 1.h264 -- fps 25 -- bitrate 500 1.raw 600x450 user 1m6.952s sys 0m0.641s |
以上的实验中编码速度为解码速度的8%。编出的文件为H264 Main。
考虑到我们编码的一大堆参数，而且又加上二次编码。解码速度应该不到编码速度的5%。
顺便一提
H264 Main 释放出来的raw文件是原来的50倍大。
MPEG 释放出来的raw文件是原来的15倍大。
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
总帧数，编码速度（每秒 编了多少帧），总帧率
翻译自：.php?t=129491#post1039674
Tags x264 • 视频编码如何设置编码降低H264解码时的CPU占用
以下三个参数是影响解码CPU占用的主力：
码率、帧率、帧尺寸。
如果使用x264编码。可以使用–tune fastedecode选项方便地编出更容易解码的视频文件。
Tags x264 • 视频编码x264命令行参数优先级
preset -> tune -> user set options -> fast first pass -> profile -> level
来自J_Darnley的测试。
Tags 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
视频编码小TIP：修正编码后音视频不同步二法
2010 年 5 月 10 日A/V同步（视频音频同步）是个热门话题，我想在这里分享一些我自己处理A/V不同步问题的经验。大家都知道，mencoder是没有-delay选项的，但这不意味着我们就处理不了A/V不同步问题了。事实上，有很多方法值得一试。
方法一：
如果源音频不是MP3，比如DVD或者糟糕的AVI文件中包含的divx/wma音频，那么对音频重新编码是非常有效的一个方法。
1、用mplayer -ao pcm -nowaveheader把音频抽取出来。
有一些选项可以大幅加速此过程，比如-vo null, -vc null, and/or -hardframedrop。 -benchmark选项也能有所帮助。
2、用mplayer的-delay选项估算出不同步的值。
如果是正值，执行下面的命令：
dd if=audiodump.wav bs=1764 skip=[delay] | lame -x – out.mp3
[delay]用不同步的时间代替（单位是百分之一秒，也就是mplayer的-delay参数数值的十分之一）。
如果是负值，执行下面的命令：
( dd if=/dev/zero bs=1764 skip=[delay] ; cat audiodump.wav ) | lame -x – out.mp3
记得替换[delay]时不要写上负号（-）.
还有，如果你的音频流不是44100/16bit/little-endian/stereo标准的，那么要把1764换成相应的值还要给lame增加相应的参数。
3、用mencoder把新的MP3文件重新封装到影片中去。
mencoder -audiofile out.mp3 -oac copy …
此时对于视频流只是复制（-ovc copy）或者重新编码都行。
最后，作为这种方法的一个变种（让处理过程更快，而且不使用那么多临时磁盘空间）。我们可以用一个叫做“audiodump.wav”（键入mkfifo audiodump.wav）的命名管道把第一步和第二步合并，让lame在mplayer抽取音频的同时进行编码。
方法二：
这次我们放弃对音频重新编码。我们这次用mplayer -dumpaudio把文件中的MP3流抽取出来，然后我们往这个流上剪切或者粘贴一点点。
如果延迟是负值，会简单一点。用lame把那段时间用相同采样率的静音音频填充就可以了：
cat silence.mp3 stream.dump > out.mp3
mencoder -audiofile out.mp3 -oac copy …
如果延迟是正值，需要把音频开头剪掉一点点。
如果比特率是平均的（大概是就可以），那很简单，剪去(比特率*延迟/8)字节就可以了。可以用dd或者任何可以编辑二进制的编辑器来做这件事。
如果是可变比特率，那就不断切切试试看了，可以在用mencoder重新封装之前用mplayer -audiofile测试切得是不是刚好。
我希望这些技巧被广泛传播，如果谁想把他们放进文档或者别的什么里面，请随意。最后一天mencoder会有-delay选项的。
Rich
翻译自.txt
Tags mencoder • 视频编码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 |
本文翻译自：.html?
Tags mencoder • x264 • 视频编码【 视频 】NTSC和PAL电视制式
2010 年 4 月 27 日今天的电视机还沿用着50年代彩色电视发明时的标准。它们就是NTSC（国家电视制式委员会）和PAL（逐行倒相）。NTSC多用于美国和日本（二战），PAL多用于欧洲、澳大利亚、中东和亚洲地区。
本文将介绍NTSC和PAL的主要概念。这些知识对更现代的高清视频格式而言，不一定再具有相同意义。
帧尺寸
电脑显示器由一大堆像素点构成，而电视显示屏则是由横线构成的。NTSC标准规定了525根横线，PAL是576根。现代显示器的横向分辨率比这高出很多（用像素衡量），768或1024都很正常。所以，当电视视频在电脑显示器上播放时，需要在垂直方向上拉伸才能充满整个屏幕。
美国电影电视工程师协会（SMPTE）在标准259M中说明，NTSC的525根横线要最终绘制出720*486的帧来，这个默认的帧尺寸被称为D1（ITU-R 601标准）。现在大多数视频采集卡从录像带采集出的视频都是D1的帧尺寸，从DV源则采出720*480的帧。它们相差6个像素高。因为当帧尺寸是16的倍数时，压缩算法会大大简化（便于切块），而比D1少6个像素高的DV帧尺寸刚好能被16整除，所以压缩算法大多支持DV帧的压缩。
对PAL视频而言，不管视频源是什么，帧尺寸总是720 * 576。因为576已经可以被16整除了，所以不用再为DV压缩做出什么改变了。
帧率
本质上，视频就是一辑快速连续播放的图像，以让人产生连续感。每秒播放图像数就叫做帧率，常用单位是fps（帧/秒）。帧率越高则每秒播放的图像数越多，视频也就越流畅。当然视频文件体积就会越大，带宽消耗也就越大。
一般我们都说NTSC的帧率是30，PAL的帧率是25。但准确的说，NTSC的帧率是29.97，这个奇怪的帧率是当年为了让黑白电视机可以兼容播放彩色电视信号。
压缩视频时，帧率起到的影响跟视频具体内容和使用的压缩算法都有很大的关系。更低的帧率可以减少需要被编码的内容，自然也就会减小文件体积，加强视频质量。但更低的帧率也会导致像素在每个帧之间的变化更大了，这样反而又需要占用更大的文件体积。但无论如何，在整体码率不变的前提下提高帧率，会使视频看上去更加流畅。
视频编码时如果要降低帧率，最好是降低成一个原视频帧率可整除的帧率，不然编码器就要去制造源视频中本不存在的帧。比如说源视频是24fps，则可以选择12fps、8fps、6fps、4fps、3fps、2fps。如果源视频是30帧，则15fps、10fps、6fps都是不错的选择。
另外，如果29.97fps的源视频时长长于10分钟，而你又没有选择可以被29.97整除的数（比如说14.98）作为输出帧数时，输出视频将出现明显的音画不同步现象。
像素宽高比
像素宽高比的英文缩写是PAR（Pixel aspect ratio），正如我们所知，电脑的像素是正方形的，但D1/DV的NTSC和PAL标准全都定义了非正方形的像素（称为D1纵横比）。DV/D1 NTSC的像素纵横比是0.91，所以NTSC的像素是瘦高的。DV/D1 PAL的像素纵横比是1.09，PAL的像素是扁胖的。所以，当在电脑显示器上看D1纵横比的视频时，它看上去就像被拉伸过。下表是各制式的像素纵横比。
| 制式 | 纵横比 |
|---|---|
| D1/DV NTSC | 0.91 |
| D1/DV NTSC Widescreen | 1.21 |
| D1/DV PAL | 1.09 |
| D1/DV PAL Widescreen | 1.46 |
隔行扫描和逐行扫描
NTSC和PAL视频的一帧由两个“场”组成，上半场包含奇数线，下半场包含偶数线。所谓“场序”，就是定义的哪个场先被显示出来。NTSC的视频的场率约为60，这样除以二以后，就得到了30fps的帧率。
隔行扫描是一个在有限的带宽的传输视频的解决方案，电视机屏幕一直采用这种显示方式。而且当时的技术无法快速地逐行扫描过整个屏幕，这样在视觉上就会产生百叶窗效果，把每帧分割为两场就解决了这个问题。所有的模拟电视标准都采用了隔行扫描的方式，而数字电视标准则有采用隔行扫描也有采用逐行扫描的。
现在一些新的高清视频标准采用了逐行扫描（一次从顶到底绘出整幅图像）的方案，但仍有不少高清视频标准选择了隔行扫描方案来提高视频的时间分辨率。在相同的码率下，逐行扫描让我们每2n个时间单位中看到一幅完全清晰的图像而隔行扫描在每n个时间单位中就看到一副图像，虽然相对而言并非那么完美的。对于体育视频而言，后者显然是更好的选择，因为能获得更好的时间分辨率，这样才能更好地观察高速运动的物体。这也是目前各大电视机厂商都想要保持隔行扫描方案的原因之一。
在一般的视频中，相邻的两场一般差别都很小，所以在电脑显示器上看不出异样。但在电脑显示器上观看快速变化的视频时，则会出现明显的“场效应”现象，通常会让视频变得模糊而且诡异。这是因为本应在不同时刻刷新的两个场在一帧中被同时显示出来了。因此，在电脑上播放此种视频时通过把两场整合成一个简单帧的方式来“去隔行扫描效应”是很有必要的。
支持逐行扫描的摄像机通常也会带有隔行扫描模式，并且会提供各种帧率。典型的有60p（60fps逐行扫描）、30i（30fps隔行扫描）、30p（30fps逐行扫描）、24p（24fps逐行扫描）。逐行扫描的视频在电脑上观看时不需要进行“去隔行扫描效应”的处理。
还有有一个术语叫做“非隔行扫描”，它和“逐行扫描”是表达的相同意思。但它常用于描述视频信号，而“逐行扫描”则一般用于描述设备。
翻译自：.html
Tags 成为视频编码工程师 • 视频编码| « | Previous page |
- 备忘 (174)
- 实践 (66)
- 实验 (17)
- 扯淡 (87)
- 正事 (11)
- 翻译 (36)
- 读书 (22)
- 转载 (19)
- DarwinStreamingServer搭建RTSP服务器
- Mac下为Android Studio编译Ffmpeg（二）Android Studio部分
- Mac下为Android Studio编译Ffmpeg（一）ndk部分
- Rust官方指南摘抄（八）并发任务
- Rust官方指南摘抄（七）闭包和迭代器
- Rust官方指南摘抄（六）方法语法、泛型和抽象方法
- MADAO's blog
- 何跃的博客
- 当密码代替钥匙的时候
- 扶凯
- 阿土's Blog
- 阿文的自留地
- 2015年二月 (1)
- 2015年一月 (10)
- 2014年十二月 (3)
- 2014年十月 (1)
- 2014年九月 (6)
- 2014年八月 (8)
- 2014年七月 (2)
- 2014年六月 (2)
- 2014年五月 (2)
- 2014年四月 (4)
- 2014年三月 (5)
- 2014年二月 (4)
- 2014年一月 (2)
- 2013年十一月 (2)
- 2013年十月 (4)
- 2013年九月 (4)
- 2013年八月 (8)
- 2013年七月 (2)
- 2013年五月 (4)
- 2013年四月 (6)
- 2013年三月 (4)
- 2013年二月 (2)
- 2012年十一月 (4)
- 2012年十月 (2)
- 2012年九月 (1)
- 2012年七月 (6)
- 2012年六月 (1)
- 2012年五月 (4)
- 2012年四月 (2)
- 2012年三月 (1)
- 2012年二月 (4)
- 2012年一月 (8)
- 2011年十二月 (10)
- 2011年十月 (8)
- 2011年九月 (8)
- 2011年七月 (7)
- 2011年六月 (12)
- 2011年五月 (1)
- 2011年四月 (15)
- 2011年三月 (7)
- 2011年二月 (2)
- 2011年一月 (4)
- 2010年十二月 (4)
- 2010年十一月 (9)
- 2010年十月 (2)
- 2010年九月 (10)
- 2010年八月 (9)
- 2010年七月 (12)
- 2010年六月 (8)
- 2010年五月 (14)
- 2010年四月 (9)
- 2010年三月 (4)
- 2010年二月 (2)
- 2010年一月 (3)
- 2009年十二月 (1)
- 2009年十一月 (10)
- 2009年十月 (7)
- 2009年九月 (5)
- 2009年八月 (2)
- 2009年七月 (4)
- 2009年六月 (1)
- 2009年五月 (2)
- 2009年四月 (2)
- 2009年三月 (1)
- 2009年一月 (2)
- 2008年十二月 (8)
- 2008年十一月 (4)
- 2008年十月 (5)
- 2008年九月 (4)
- 2008年八月 (2)
- 2008年六月 (2)
- 2008年四月 (1)
- 2008年三月 (1)
- 2008年二月 (1)
- 2007年十一月 (1)
- 2007年九月 (1)
- 2007年六月 (3)
- 2007年四月 (2)
- 2007年三月 (1)
- 2006年十二月 (1)
- 2006年十月 (1)
- 2006年四月 (4)
- 2006年二月 (3)
- 2006年一月 (3)
- 2005年十二月 (3)
- 2005年九月 (8)
- 2005年八月 (9)
更多推荐
如何把X264输出的INFO信息保存到文件
发布评论