小丸工具箱一般用什么编码器的简单介绍

我们很多时候更新软件的一个目的就是为了获得更好的优化，让软件更为充分的发挥出硬件的潜能，对于不少人经常要使用的视频编码器来说，更是如此，往往新版本对于新的硬件平台有更好的支持，那么，具体的提升幅度有多少呢？我们以著名的开源HEVC视频编码器x265为例做了简单的测试。

其实本来这个问题是这样发现的：我们在CPU性能测试中一直以来使用的x264/x265 Benchmark版本非常老了，其内置的x264编译完成于2011年，而x265则是1.4版本的，前者距今已经有8年多没更新过了，而后者距今也有将近5年的时间了。老版本编码器上面比较严重的问题就是对于新指令集的优化不够充分，并不能够发挥新CPU 100％的潜力。

那为什么选择x265作为测试对象软件呢？一是相对于x264，x265在并行化上面有着更好的优化，在现在有着众多核心的服务器/HEDT平台上会有更好的表现；二是x264的更新已经接近停滞，原本主要的几个mod版本都已经放弃了更新，比如MeGUI原来使用的kMod，小丸工具箱以前用过的tMod（原tMod作者06_taro早就不更新了，现在是有另外的开发者在更），而x265仍然保持了相当的开发力度，版本更迭还是比较快的；三是x264对于现在的新CPU来说已经不是什么大难题了，只要不开那种很变态的参数，速度还是很快的，而x265就不一样了，就算是一般的参数都可以把CPU性能吃干抹净，速度还远远达不到x264的地步。

废话不多说了，直接来看测试。

测试平台与说明

测试平台有两套，其实就是昨天两个CPU评测的那两套平台，主要的控制变量实验在Intel Core i9-10980XE上面进行。

对比选用了我们原来在x265 Benchmark上使用的1.4版x265，编译器为gcc，为了控制变量，选用了同样由gcc编译的两个较新版本的x265，一个为2.4+14版，另一个为3.2+2版，都是8bit版本，不过gcc版本不同，另外它们也是来自于不同的开发者，3.2+2版本使用的是国人开发者msg7086的修改版，性能方面与原版没有什么大的区别点。

新老x265在大部分默认参数上都保持了一致，少数可见的不同参数将使用手动方式进行控制，以保证可对比性。源仍然使用x265 Benchmark中附带的测试片段，使用Vapoursynth R48进行预处理并送入x265，预处理仅使用LSMASH读取视频文件，不做任何其他处理。

对比测试原版参数

首先是与原版x265 Benchmark使用相同的参数: --preset fast --crf 20来查看最直观的提升情况。

可以看到2.4+14版本在同参数下速率提升超过了一倍之多，另外通过码率情况也可以看到2.4+14版本的输出与更新的3.2+2版本并没有区别。根据常识，向一个确定的程序算法中输入相同的数据，其输出也应该是相同的，所以很有可能，在默认参数下，从2.4+14版本到3.2+2版本并没有对编码算法进行修改。

而在用这组参数跑测试的时候，CPU并没有满载，反映出了两种可能性，一是x265自身的压力不够大，二是x265的并行优化可能还没有针对这么多核心做到最好，所以在参考了前辈的经验和x265文档之后，加入了新的参数: --ctu 32。

缩小CTU值

--ctu参数提升的是x265编码中Code Tree Unit的最大单元大小，--fast参数默认是64，手动改成32可以提升并行编码效率，但会使视频的码率升高。

在该参数下，x265对于CPU的使用率确实变高了一些，但是仍然吃不满，利用率变高的结果就是编码帧率升高了不少，就算是老版本也有不小的提升。

但还是吃不满CPU，咋办呢？x265还提供了一些提升并行使用率的参数，比如--pme和--pmode。

提升并行化程度

就结果来看，用来提升CPU使用率的--pme和--pmode并没有起到预期的效果，实际的编码效率反而下降了。而从码率结果来看，开启--pme和--pmode可以有效降低码率，提高压缩比。另外，1.4+5版本的x265虽然在帧率表现上像是开了这两个参数一样，但是输出结果的码率是完全一致的，可能是并没有实际应用到最终输出上，同样，2.4+14版本的-pme参数也像是没有起效，而在3.2+2版本上面，两个参数表现正常。

修改预设，增大对处理器的压力

为了完全压榨处理器的性能，我决定修改使用的预设，从原本的--preset fast调至--preset medium和--preset slow。

其实开到--preset medium就可以让这颗Core i9-10980XE满负荷运行了，看来在fast预设下面，x265给的压力不够大，不足以让CPU满负荷运行。

AVX-512有用吗？

新版的x265也加入了针对新的AVX-512指令集的优化，由于时间关系，只来得及用3.2+2的msvc编译版本简单验证一下，默认情况下x265不会调用AVX-512指令集，需要手动添加--asm avx512命令进行启用。

呃，很尴尬，看上去像是x265的AVX-512支持还没有完善，开启之后成绩不升反降，也可能是编译器的关系，有时间我用gcc编译版再测一次。

那么，对于32核的优化呢？

好了，Core i9-10980XE这颗18核36线程的处理器被压榨干净了，那么Threadripper 3970X这颗32核心64线程的处理器呢？由于时间限制，我只能简单对其中一个版本进行简单测试。

直接跟Core i9-10980XE在同参数同版本x265下的成绩进行对比就可以看出端倪，x265对于超多核心的优化并没有做好，或者是部分参数的默认值在超多核心处理器上面没有进行自动调整导致Threadripper 3970X没有获得应该有的优势。

简单结论

其实问题在很上面就解决了，新版本的x265提升非常大。下面的参数测试算是偏题部分，只是想看看x265到底能不能压榨完超多核心处理器的性能，答案应该是可以的，只要给的负载够大就行，不过它对于Threadripper 3970X这样有32核心的处理器的优化还不到位，另外在默认情况下面它并不能100％反映出CPU的性能潜力，需要自己手动调整参数。

其实写这篇的目的只是想放这张截图装个X而已（逃