再测IVB核显加速转码【第三弹】换片源，低码率

第一弹联动——首次测试，软硬件环境说明
第二弹联动——第二次测试，改进测试方式

再次感谢大家的意见。看来对第二次测试仍然有些疑问。
@lynn 提出

LZ的测试依然不够规范。
第一：片源太少。只选择了一个片源，并且片源质量还不怎么样。
第二：测试项太少。X264 和 Intel Media SDK 的样本各一个。而且码率1000kbps，分辨率540p，这么低的参数，发挥不出X264的威力，明显偏向核显加速。

PS:CPU编码可以使用各种滤镜，GPU编码能跑么？

OK，这次换片源。
第二、样本数量提高到5个，分别测试2pass+very SLow，Faster，very Fast，Ultra Fast，GPU加速。码率按照22楼wqxhrl同学的标准，降到768kbps。
最后，GPU编码确实不支持滤镜，但支持不支持对于画质要求不高的人来说无所谓……

重申一下：真追求画质就是要CPU软编码，毋庸置疑。本帖不讨极限状态下谁强，只讨论GPU加速达到了CPU编码的什么程度。

然后是正题：
片源更换海盗湾Les Misérables（2012）1080p，YIFY版，种子和视频一起打包在本贴尾部上传。
选取时间段：      1h:35m:40s-1h:37m:36s

转码速度：

2pass:	90s
faster:	26.7s
very fast:	24.2s
Ultra fast:	18.7s
GPU:	18.4s

抛开画质不谈，可以看出Ultra Fast等级的CPU编码速度已经和GPU硬件加速差距不大了，看起来很合理，其实不然。
先看下Faster下的CPU占用率：

1. 平均CPU使用量：
   
2.         音频编码：1.8%
   
3.         视频解码：31.3%
   
4.         视频编码：51.8%

复制代码

加起来占用了85%的样子，如果算上后台运行的程序，还算合理。

再来看一下Ultra Fast编码下的CPU占用率：

1. 平均CPU使用量：
   
2.         音频编码：1.3%
   
3.         视频解码：41.1%
   
4.         视频编码：16.2%

复制代码

加起来不到60%，看起来占用率有点低。
那GPU硬件加速的呢：

1. 平均CPU使用量：
   
2.         音频编码：2.5%
   
3.         视频解码：31.9%
   
4.         视频编码：5.4%

复制代码

更低了，40%左右。

那么这时候再对比Ultra Fast跟GPU编码的转换时间，发现在时间差不多的情况下，本来就用不满的CPU 占用率更低了。
这说明一个问题：在这样的测试环境中，影响速度的瓶颈不是CPU或显卡的处理能力，其他共有的瓶颈导致转换速度相差不大。

那么瓶颈是什么，姑且猜测是硬盘速度，于是将临时文件跟最终存放区域都挪到SSD上去。（TLC啊……我的硬盘寿命）
测试结果如下：
GPU+SSD:    13.6s

1. 平均CPU使用量：
   
2.         音频编码：2.4%
   
3.         视频解码：57.8%
   
4.         视频编码：7.7%

复制代码

CPU占用率提高到70%了，转码速度也提高了35%。

Ultra Fast+SSD ： 18.1s

1. 平均CPU使用量：
   
2.         音频编码：2.5%
   
3.         视频解码：44.1%
   
4.         视频编码：18.2%

复制代码

占用率提高到63%，速度提升幅度也不大，看来对x264来说，瓶颈不是硬盘速度，怀疑是内存吞吐量或其他问题，如有知道的欢迎告知。

那么上表应替换成这个样子：

2pass:	90s
faster:	26.7s
very fast:	24.2s
Ultra fast:	18.1s
GPU:	13.6s

这样看起来GPU加速依然有他的价值。

最后是画质的对比：
视频信息我就不贴了，下载下来一看全有。
而且一次贴5个，又长又没人看……
片源：


2pass+very Slow：


Faster：


Very Fast：


Ultra Fast：


GPU加速：


注意挥舞的那两面旗帜。

PS：
有人说GPU加速编码出来的画质很渣，我发现还有默认设置的原因。
在默认设置下，intel Media SDK的参考帧数为"2"，设置为"5"后，转码速度没有明显下降，但画质提升幅度很大。


转换后的视频及片源：http://pan.baidu.com/share/link?shareid=332609&uk=1963211542
最后吐槽一下：
下班之后80%的时间都拿来搞这个，难怪找不到妹子……

wqxhrl 发表于 2013-3-19 22:06
我以前一直转的动漫，没想到2pass very slow压片还有这么大的损失。

码率的问题，768kbps跑540p还是有点勉强了。
再好的压制手段碰到高码率一样会败
再说静态图片对比跟实际看起来又不一样，效果还可以接受。

lynn 发表于 2013-3-19 21:59
BRRIP二压实在惨不忍睹……

额，其实是参考帧选的不大好，但找了好几次都是有Motion Blur的，这帧也是。

主要还是懒了点，加上想起来单位有点事没解决，就凑合了。

Limygm 发表于 2013-3-20 00:40
我还是再提出一点小意见吧

1. 参数选择：很方便的一个参数 --crf，现在直接指定码率已经很少用了吧

Intel Media SDK是不支持CRF的，所以测出来没有对比价值。除非先用x264+CRF跑一遍，然后在以跑出来的码率为标准测GPU加速，但这对GPU不公平。

精确截图最好的方式是用AE直接输出JPEG，但我最近五月病犯了……而且Mplayer支持帧步进，还算精确。

lynn 发表于 2013-3-19 23:28
因为这个片源本身不好，BRRIP二压 700K，已经损失惨重，然后三压的参数又太低，这种接近720P的东西，才给 ...

所以说群众是最操蛋的……
我前面用1000kbps测的，大家说这码率太高了，明显偏向GPU。
等换到700k，又说码率太低了，画质太差没有可比性。

玩我啊

lynn 发表于 2013-3-20 18:09
嗯，确实不支持，但是MEDIACODER中的INTEL CODER可以选择GPU加速，这是什么意思？ ...

额，道歉的该是我才对，发火发错人了。
这事情不是你提的，第一弹就有人提出来了，说1000kbps码率太高，GPU发挥空间大，要低码率才能比较的出来。

我其实也是这么认为的，毕竟测试跟实际应用如果是一样的东西那测起来意义不大。
如果是压片拿来看肯定是高码率，但比较画质确实是选低码率更容易分辨出编码器的实力。就如同汽车都宣扬百公里加速xx秒，但实际跑起来没人这么玩命踩油门。

而且出到这里我已经得到让自己满意的数据，结论这三期帖子也都没有变过，至于大家接不接受，那就随便了。

lynn 发表于 2013-3-20 18:09
嗯，确实不支持，但是MEDIACODER中的INTEL CODER可以选择GPU加速，这是什么意思？ ...

看具体速度吧，MediaCoder那个检测是按CPU选的，发现是SNB以上的都让选。
但如果设置不对，或者其实不支持，就会调用Intel Media SDK的软编码功能。

跑出来就跟第一代“ATI AVIVO视频转换”一样，速度没提多少，画质降低不少。

Limygm 发表于 2013-3-21 06:50
我的意思是，结论已经很明显了，参数不是太差的情况下，GPU 加速画质不行，但速度有优势

所以现在应该是 ...

嗯，大家目的都是一样的。

我的论点是既然是测试GPU转码的画质，那就最好以GPU的设置为基准，CRF不支持固定码率，会对测试造成不小的难度。
而且CRF的速度介于1pass到2pass之间，刚进行了实验，即使用Ultra Fast+CRF16，转码速度也接近Very Slow+1pass了（还是主楼那个样片，耗时40s），体积上也比较接近（最终平均码率760kbps）。画质上说，受限于Ultra Fast本身的处理方式，画质比Very Fast+1pass还惨。
那么可以认定CRF对画质的提升不如调预设，属于锦上添花的设置方式，对收藏党可能用处不小，但在应该不必参与这次测试（耗时过长、画质提升小）。

最后从原理上说，CRF通过减小motion blur帧的码率，提高关键帧码率，来达到视觉效果上的提升，而不是实际每帧的画质提升。如果真用图片比较，可能会更差也说不定。这点从视频信息上也可以看出来，CRF压出来的东西“最高码率”跟“最低码率”两个值的差距非常大。

jerrytot 发表于 2013-3-20 22:20
楼主你发的链接里没有片源啊, Les.Misérables.2012.1080p.BrRip.x264.YIFY这个文件不是片源, 才768K的码率 ...

哦，抱歉，那个是无意中压进去的，应该是倒数第二章截图的视频，跟“Ultra Fast”那个是同一个东西。

片源是那个BT种子，节选1:35:40-1:37:36之间的视频。