文 / Jan Ozer
翻译 / 咪宝
原文
2018年8月我首次测试AV1编码时，其编码速度非常缓慢，严重影响了编解码器的潜在可用性。表1说明了此事。除非另有说明，否则所有编码时间数据都依托于我的HP ZBook笔记本电脑（配置了单个2.8 GHz Intel Xeon E3-1505M v5 CPU）。此外，LibVPx是FFmpeg中VP9的实现，所有对AV1的引用都参考FFmpeg中可用的AV1编解码器。
表1. AV1首次发布时的编码时间
2018年末开始，我曾写道，研究人员报告AV1编码时间低至10倍LibVPx编码时间。当我最近开始进行一个编解码器评估项目时，我很想知道这个时间是否匹配。我刚完成那个项目，表2显示了现在的情况。我知道你在想，去年VMAF视频压缩质量是96.18; 表2中引用的质量是95.55。由于需要6个VMF点才能产生明显的差异，即使是最敏锐的观察者也不会注意到这个.63差异。
表2. AV1当前的优化编码时间
根据2018年8月对其他编解码器的评测，AV1的编码时间是x265和LibVPx的3倍左右。正如你将在下面看到的那样，事情并不完全相同，而且我对其他编解码器并不完全公平，但是尽管如此，它的加速速度还是相当惊人，你不是这么认为吗?
如果你十分关心TL/DR，可以跳到表6并查看与其他编解码器的比较。如果你想花时间了解我是如何做到那一步的，那就让我们详细说来。
编码器速度的提升
在我们最初的测试中使用的命令字符串是这样的:
如果对当前版本的FFmpeg使用相同的字符串(我测试了N-93083-g8522d219ce版本)，编码时间从226,080秒(45K乘以real-time)下降到18,196秒(约3,639倍real-time)，速度提高了约12倍。虽然仍然比x265慢63倍，比LibVPx慢80倍，但是我们可以看到表3中所示的结果。表3中创建的AV1文件的VMAF得分为95.91，因此与去年的96.18相比，质量下降得非常小，而且不明显。
表3.使用带有当前代码的原始命令行（AOM的改进）
表3显示了我们初步测试的对两者各方面表现的比较。所有其他编码时间减少与编码字符串的更改有关。
寻找AV1的最佳速度/质量权衡
大多数编解码器都有预设，可以让你权衡编码时间的质量。例如，对于x264和x265，预设的名称包括慢速、非常慢、快速、非常快和中等。使用AV1，预设通过cpu-usedswitch控制，你可以在上面的批次中看到我使用cpu-used8in pass 1和cpu-used0in pass 2。
如果在FFmpeg中加载AV1帮助说明（ffmpeg -h encoder = libaom-av1），你将看到以下内容：
使用LibVPx和AV1时，首次传递质量不会影响第二次传递，因此你通常以最快/最低质量设置运行第一次传递。在Google的August First Look方向上，我以最高质量运行第二次传递，即cpu-used 0。编码时间太慢，我没有花时间尝试这些设置，就像我之前对x264、x265和LibVPx做的那样。
图1显示了在我开始严格测试或生产编码之前，我通常为每个编解码器/预设/编码器创建的图表。红线跟踪可用质量，而蓝线跟踪编码时间。例如，在cpu-used5，编码时间是最大值的6.63％（00:20:06与5:03:16相比），而质量是最大值的99.64％（95.56 VMAF与95.91相比）。
图1. AV1的质量/速度曲线
如果你是一名研究人员，试图度量某个特定编解码器的绝对最佳质量，你可以忽略该图在cpu-used 0处编码。如果你是一个视频制作人，则可能使用cpu-used 5编码，因为较低的设置可以节省最少的时间，而较高的设置可以最大限度地提高质量。当然，根据图1中显示的数字，如果你选择使用cpu-use8，也没有人会认为你发疯。假设你用cpu-used 5编码，表4显示了编码时间的比较。
表4. 当前版本的FFmpeg、cpu-used 5
单个五秒剪辑编码能否准确预测以多种数据速率编码的更广泛剪辑的质量/速度曲线？在我最近完成的项目中，我在不同的编解码器上使用相同的方法，基于5秒测试剪辑的单个编码的曲线预测在预设使用和最大质量（和预设切割）之间的质量差异为1.3％编码时间从18分钟到3分钟）。之后我测量了预设使用的和五个等级和六个测试片段的最大质量之间的实际差异，实际差异为1.4％。因此，虽然更多数据总是更好，但单个编码应该是一个相当准确的预测器。
也就是说，在我的“数字视频编码”一书中，我使用8个片段为x264，x265和LibVPx创建了类似的曲线，平均持续时间约为2分钟。在我开始使用新的编解码器或编码器（特别是AV1）进行严格编码之前，我会对类似的或更大数量的样本进行测试。
运行多个线程
在最近的项目中，我咨询了Google是否有其他方法可以加快编码速度。一位工程师建议：
如果在运行编码器时可以使用多个线程，则有助于编码器速度。对于高清及以上分辨率，我们建议使用区块（tile）。使用区块会导致质量下降，我的旧测试显示，使用2个区块时损失约0.6％，使用4个区块时损失约1.3％。
我自己没有测试过4k的剪辑，所以我在这里给出一些建议。对于1080p，使用2个tile和8个线程：“--tile-columns = 1 --tile-rows = 0 --threads = 8
对于4k，使用4个tile和16个线程：“--tile-columns = 1 --tile-rows = 1 --threads = 16”（甚至尝试：8个tile / 32个线程：“--tile-columns = 2 --tile-rows = 1 --threads = 32“）”
在该项目中实现区块和线程之前，我测试了1080p和4K文件，这次是在我的HP Z840 40核工作站上，并使用了多个线程。我使用了建议的1080p设置，以及4K的第二组设置（--tile-columns = 2 --tile-rows = 1 --threads = 32）。表5显示了结果。在1080p时，编码时间下降了41.66%，而对于4K，编码时间下降了70.56%，这两种情况下的质量差异可以忽略不计。
表5.在其他测试编码中部署多个线程
应用于ZBook测试平台上的测试片段，部署--tile-columns = 1 --tile-rows = 0 --threads = 8 它们在cpu-used 5上的编码时间从20:06下降到12:16，数字如表2所示。与此同时，VMAF指数也大幅下跌了0.01点(从95.56点跌至95.55点)。
实际上，要清楚的是，添加到FFmpeg命令字符串的操作如下：
Google工程师显示的设置很可能是独立于FFmpeg工作的AOM编码器。请注意，这些设置当前不在AV1编解码器的FFmpeg帮助文件中，但试一试，看看你是否得到相同的结果（注意：这些设置没有记录在我研究本文时检查的旧版本的FFmpeg中，但是在FFmpeg中的当前版本的AV1帮助文件中记录了tiles，tile-columns，tile-rows和row-mt。）
虽然这些设置不会增加任何特定编码运行的编码速度，但它们可能不会增加任何给定系统上的编码吞吐量。这是因为它们似乎并没有提高编码效率，就其本身而言，它们似乎允许每个单独的编码消耗更多的CPU资源，这在任何给定的系统上都是一个零和数字。
虽然数字没有完美映射，但本质上，我们不是在同一个系统上同时处理两个编码，每个编码在一个小时内生成5分钟的编码片段，而是在处理一个编码，它的运行速度是这个编码的两倍，每小时生成10分钟的编码片段。在这两种情况下，总体系统吞吐量都是每小时10分钟，但是多线程编码的工作速度是前者的两倍。如果您正在创建一个并行处理多个编码的编码器，则可能不希望使用这些设置。如果您在系统上运行一个FFmpeg实例，那么你几乎肯定会这样做。
所以，读者现在或许会理解我开始说我不是在比较两者间的差别，而且我对其他编解码器也不公平。x264，x265和LibVPx都有自己的质量/速度曲线，如果我们要对AV1应用“实用”设置，我们应该对这三个编解码器做同样的设置。
具体地说，如果对LibVPx使用speed 2(而不是最高质量的speed 0)，对x264和x265使用slow预置(而不是非常慢)，我们将得到如表6所示的时间。这使得AV1的制作成本几乎是x265和LibVPx的20倍，这只适用于编码高6位数和7位数的观众数量。到目前为止，使用新编解码器制作视频的通常是Netflix、Facebook和YouTube等公司(以及AOM联盟成员)。令人印象深刻的速度增长我相信还会有更多。
我在表6中展示的VMAF分数仅供参考;单个5秒1080p编码比编码的3 Mbps容易，剪辑不足以得出任何与质量相关的结论。相反，您需要查看来自多个剪辑的速率失真曲线和BD速率比较。我会在接下来的几周内更新AV1审核的结果，以创建相关的比较数据。
表6. 使用最“实用”的设置进行速度比较。
在此期间，如果您正在编码AV1，请尝试使用不同的cpu使用设置以及tile和线程，并查看结果是否相似。如果您阅读任何参考编码时间的AV1比较评论，请检查并查看研究人员使用的cpu使用设置。如果未指定，则默认值为1，这可能是真正的生产者不会使用的设置。如果它是cpu-used 0，虽然可以说适用于学术研究，编码时间与真正的生产者实际使用编解码器的方式完全没有关系。
为了帮助那些想要尝试这些新设置的人，这里是FFmpeg命令字符串的最终版本。
————————————————
版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/88549352
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
