[原创]x264多版本横向测试

原文地址：
http://vx.moe-sos.com/?action=show&id=22

不好意思，我又开一个帖……
我那上一个帖子被好多热心朋友的数据塞了好多层楼，估计也不会有多少人喜欢爬楼和在数据堆里找自己需要的东西吧……囧
这次选了几个版本，测了参数出来，并且用Excel做了图，希望能更直观的展现给大家。


======================================================================


选用版本是x264.nl的763 786还有MEGUI更新的763 patched和798 patched
我的系统状态：
Core2Duo E6550 @ 3.2G
Windows XP Service Pack 3 v.3300
杀毒软件是ESET 3.0

基准测试参数:
--qp 18 --keyint 240 --min-keyint 24 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --trellis 1 --analyse all --8x8dct --threads 3 --thread-input --progress --no-dct-decimate
patched版本关闭AQ

修改测试参数:
包括subme和me两项

片源：
长度 1:11
格式 YV12
封装 AVI
帧数 1724
分辨率 864x480
动态 一般，普通动画

测试过程：
直接送AVI给x264，不经过AVS，在CMD下用命令行编码。记录各个编码器编码帧率,码率，PSNR，SSIM。











可以看到，798的码率比其他三个版本都要高上一些，不过相应的，PSNR和SSIM也跟着高了一些。再来看压制速度，798p是最快的，x264最近不停的更新都在致力于加快编码速度，效果还是可观的。

极限参数的码率比最低参数的下降20多K，不过fps下降了一半还要多，个人感觉不值得。

下面看798p的图。同样在umh下，me7比me6低了2fps左右，但是码率低了20K，并且PSNR和SSIM都高出一些，所以我个人推荐me7+umh的组合，感觉“性价比”比较高一些。

以上是我对这个几个图表的分析，希望能起到一个抛砖引玉的作用。

是的，只有对容量要求很严格的情况下才有必要用2pass，否则用crf即可，这是X264的特点之一。

出格子和Decoder也有很大关系...另外不喜用CRF等1PASS...这就像随机应变式的突袭和侦察后再突袭一样的道理....

引用

最初由 techneek 发布
楼上的，你的签名档图片终于换了，看着顺眼多了～

那张色彩华丽的LOLI图不能如您法眼:o

引用

最初由 techneek 发布
deadzone就是默认的量化方法，没有开不开这一说，只有deadzone的数值可以由用户调节这一说，deadzone不开x264是不能工作的。

trellis作为一种更“先进”的量化方法，能够自主干预量化的过程，而trellis并不是对所有的MB都起作用，trellis不起作用的MB，用的量化方法还是deadzone。

所以trellis是一种额外的编码工具，在x264里是默认关闭的，我想主要原因是速度问题？呵呵，所以默认关闭本身并不能说明什么问题。

我记得当时谁说过 DEADZONE只有在trellis为0时才起作用

banding现在不可避免，连用那么高码率压BD的authoring studio都对这个头痛不已呢

“しかし、デジタルならではの問題点もある。「アニメで特に多い問題は、階调表現が境界線として出てしまうバンディングという現象。これを低減することが高画質化に重要」という。IMAGICAでは境界線部分をなじませる処理(マッハバンド除去システム)として、独自の「M.A.P.S(マップス)」を導入。同様の問題を指摘するキュー・テックの平野氏も、「この問題に対応できる専用のシステムをスキームとして用意している。これまでの経験を活かし、カット&トライで品質を向上させている」と語った。”

君望OP前2000帧，640x480

x264 --crf 16 --level 4.1 --keyint 240 --min-keyint 24 --ref 5 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me tesa --threads auto --thread-input --sar 1:1

trellis 0

x264 [info]: SSIM Mean Y:0.9905929
x264 [info]: PSNR Mean Y:46.541 U:47.031 V:47.647 Avg:46.756 Global:46.268 kb/s:1528.04
encoded 2001 frames, 9.36 fps, 1528.18 kb/s

1

x264 [info]: SSIM Mean Y:0.9905956
x264 [info]: PSNR Mean Y:46.670 U:47.021 V:47.648 Avg:46.844 Global:46.365 kb/s:1564.27
encoded 2001 frames, 9.04 fps, 1564.41 kb/s

2
x264 [info]: SSIM Mean Y:0.9906953
x264 [info]: PSNR Mean Y:46.678 U:47.038 V:47.662 Avg:46.854 Global:46.365 kb/s:1494.10
encoded 2001 frames, 7.44 fps, 1494.24 kb/s

SSIM&PSNR 0<1<2
码率 2<0<1

引用

最初由 qyqgpower 发布
trellis1有用，trellis2需要RDO的subme，也就是6和7

trellis本来就是选择最低rate-distortion ratio的一种算法，如果要应用在所有decision上，不开Rate-distortion optimization它怎么选

但是CLI和MeGUI里，subme即使设成1，trellis还是可以随便选啊，呵呵～不过实际中可能不会有人这么设定吧～

再问一下大家，你们用x264压出来的片子，暗处色彩过度也是一块一块的吗？