2020年9月18日
By Jan Ozer 特约编辑
专题文章

AV1已经到来:比较来自amedia, Visionular和Intel/Netflix的编解码器

2018年是AV1出名的一年, 2020年将是AV1变得有趣的一年, 主要是因为三个方面的发展. First, in early 2020, 支持av1的智能电视上市, 就像开放媒体联盟(AOMedia)在2018年宣布的两年计划一样. Second, 在过去的两年里, amediaav1编解码器的编码时间从实时的2500倍下降到比HEVC慢2倍. Finally, 第三方AV1编解码器的出现提高了AV1编解码器的质量和编码速度.

In short, in 24 months, 硬件支持出现, 编码变得负担得起, AV1成为了HEVC更现实的竞争对手.

认识一下编解码器

我审查的重点是开发人员级别的产品，用于集成到现有的编码工作流中，而不是商业云编码或独立编码器. 我测试了四个独立的AV1编码器:

AOMedia的独立aomenc, v2.0.0
Intel/Netflix的SVT-AV1编解码器，v0.8.4与版本0确认.804-22
Visionular的aurora编解码器，v2.0.1
libbaom是FFmpeg v2中的amedia编解码器.0.0

aomenc是AOMedia的独立编码可执行文件，可以使用 here. 在测试过程中, 我把问题和编码字符串发送给谷歌, 是谁好心地提供了帮助.

SVT-AV1是由英特尔和Netflix创建的AV1编解码器实现，可在 GitHub. 当我在测试期间联系英特尔时, 我收到了以下回复:“在这个时候使用SVT-AV1可能会对项目造成误解，因为你评估的编解码器功能目前还没有实现，或者还在进行中。”.这位联系人列举了三个原因，我将复述一下:

流媒体和广播级应用程序的开发工作尚未开始.
英特尔尚未开发针对vmaf的调优功能.
双通道速率控制尚未完成.

在我看来, 第二个原因不是问题，因为我没有用任何编解码器调优VMAF(稍后会详细介绍)。. 我决定在分析中保留SVT-AV1，因为所有编解码器都在进行中, 我已经投入了大量的时间来学习使用编解码器和制作测试剪辑, 这个编解码器在GitHub上是免费的. 我把这些信息告诉英特尔后，它审查了我的命令字符串，并提供了其他指导.

Visionular将自己描述为“下一代视频编码和图像处理技术软件公司”.“它提供了极光AV1编码器对我来说是一个带有指令的可执行文件.

最后，我测试了ffmpeg4.3.1(构建号ffmpeg-20200727-16c2ed4-win64-static)作为 downloaded from Zeranoe，其中包括libaom、x264和x265编解码器.

Test Clips

我上次测试AV1编解码器的时候, 我使用了4个5秒的测试片段，因为编码时间太长了. This time, 我从10秒的剪辑开始，发现AV1的编码时间明显下降了. 因此，我将测试列表扩展为5类16个片段，如下所示 Table 1.

Table 1. 测试剪辑和类型

生成稍后显示的利率失真曲线和BD-Rate统计数据所需的数据, 每个片段需要四个编码. To 选择数据速率, 我把VMAF设定在85到95之间, 在大多数编码阶梯中产生的最高质量流的目标是什么. 唯一的例外是游戏片段, 这些都是60帧/秒的动态画面，需要10mbps以上的速度才能达到同样的画质水平. 所以我在顶部以5,750Kbps的速度编码，然后从那里开始缩减.

在布置命令字符串之前，让我们讨论一下预设和调优.

Presets

几乎所有的编解码器都包含预设，因为流媒体生产商有不同的目标和商业模式. 有些人可能希望通过接受稍低的质量来最小化编码时间和成本. 有些人可能想要最高的质量，而不考虑编码时间或成本. 预设允许每个流媒体生产者优化其特定的要求.

AV1有9个预设通过cpu使用的开关选择. 我的目标是选择大多数制作人都会使用的最具商业合理性的预设, 不是最高质量的AV1预设. 要识别这个预设, 我用FFmpeg/libaom编码了10个测试文件，从5个类型到所有预设，并记录了编码时间, 平均质量, 帧质量低, 最后一项通常用于发现暂时的质量问题. 我把这些值画成百分比 Figure 1, with red signifying encoding time; blue, 平均质量; and yellow, low frame quality.

Figure 1. 选择aomenc、libaom和Aurora1的预设(点击查看大图)

例如，在cpu使用率为3时，编码器平均为99.平均质量的53%，99.低帧质量占39%.4%的编码时间的最高质量预置，cpu使用0. 使用cpu 2进行编码将使编码时间增加三倍，而额外的质量最小, 而使用cpu的4可以在质量损失最小的情况下将编码速度提高约33%.

考虑到即使是最低质量的预设，质量也相当高, 您可能会认为使用cpu的8在商业上是合理的. 然而，Visionular建议使用它的“慢”预设，这与cpu使用的3相对应. 在确认了Aurora1和aomenc编解码器的类似性能之后. 我用cpu使用的3测试了这三种编解码器.

Interestingly, SVT-AV1表现出不同的质量/编码时间权衡, 在cpu使用率为7时出现了意想不到的质量提升, 然后通过cpu使用2(参见 Figure 2). 虽然从cpu使用的3到cpu使用的2的跳转增加了编码时间, 它的质量也从95分提高了.07% to 99.72%，大多数生产商可能会认为这是合理的. 所以我用预设2编码了所有SVT-AV1剪辑, 尽管我在稍后讨论的性能测试中也测试了预置7.

Figure 2. 选择SVT-AV1的预设(点击查看大图)

X264和x265使用预设名称，如超快、超快、中、慢和安慰剂. 通常，我建议使用慢速预设 x265, 比起默认的中等预设，哪一种可以显著提高低帧质量，并且编码时间大约翻倍. However, 在为这些比较而生成的x265文件中, 我使用非常慢的预设来优化质量, 尽管这大大提高了编码时间. 给大家一个感觉, 在稍后讨论的性能测试中，我测试了慢速预设和极慢预设.

由于x264的编码速度比x265或任何AV1编解码器快了几个数量级, 我使用了非常慢的预设, which typically 在编码时间的一小部分内提供比安慰剂稍高的质量.

在进行性能测试之前，让我们先了解一下调优.

调优策略

调优是指将调优参数应用于命令字符串的实践，以去除编码技术，如已知会降低度量分数的自适应量化. 对指标的调优通常是公认的对于x264和x265，虽然不是普遍使用. 例如，在最近的分析中，当将AV1与其他编解码器进行基准测试时，两者都没有 Facebook nor Netflix 调优，更喜欢使用实际的生产参数. Nonetheless, 因为x264和x264默认启用了自适应量化等功能, 我在制作通过客观指标进行评级的文件时进行了调整.

AV1编解码器也有调优机制, 对峰值信噪比(PSNR)和SSIM进行了调整，可用于几个版本, VMAF的调优相对较新. However, 我测试的AV1编解码器都没有默认启用自适应量化, 所以这些调优机制到底在做什么还不清楚. 关于VMAF的调优，一个Google 工程师将其描述为“在标准编码之前对帧进行自适应预滤波(锐化)”. 这将使VMAF在bd率方面的得分提高到30%，但当然，PSNR不会很好."

不像用x264和x265调优PSNR和SSIM disables features that improve 主观品质 degrade 度量分数，VMAF调优 enables features that improve 度量分数，但可能 degrade 主观品质，感觉像是作弊. 所以我没有在任何编码中调优VMAF. 我将在x264/x265讨论之后讨论AV1编解码器的PSNR/SSIM调优.

调优x264和x265

x264提供两种调优机制:PSNR和SSIM. 为了最小化管理复杂性，我想使用一种机制为度量测试生成的所有文件. 虽然这个分析只涉及VMAF和SSIMPLUS, 我可能会加入PSNR, SSIM, 和MS-SSIM在未来的测试. 为每个编解码器选择最优的调谐策略, 我编码了来自四种不同类型的四个文件，启用了SSIM和PSNR调优，以及一个没有调优的文件. 然后我对结果求平均值，在x264中显示 Table 2. 绿色的分数是最高的平均分.

Ozer AV1

Table 2. 我调整了x264的PSNR.

从表中可以看到，调优为 PSNR提供了更高的VMAF和sim - plus分数, PSNR是相等的, SSIM和MS-SSIM的含量也有轻微的下降. 因此，对于x264，我调整了PSNR. 在对x265的类似分析中, 对SSIM的调优为所有指标产生了最高质量的分数, even PSNR. 因此，对于x265，我针对SSIM进行了调优.

TUNING FOR AV1

四个AV1编解码器中的三个, libaom, Aurora1, and aomenc, offered tuning for SSIM and PSNR; SVT-AV1 didn’t. 我对所有提供调优的AV1编解码器进行了相同的分析. 因为在几乎所有情况下，调优方法和不调优方法之间的差异都不大, 我决定简化问题，而不是调整这三种编解码器. SVT-AV1不提供调优，简化了该编解码器的决策.

让我们继续讨论其他编码参数和字符串本身.

通用编码参数和编码字符串

所使用的一般编码参数见 Table 3 而且是相当通用的.

Ozer AV1表

Table 3. 测试编码的一般参数

有了这个背景, 这里是用于不同编解码器的编码字符串，以及我是如何创建它们的.

amedia的libbaom (ffmpeg)

这是一个FFmpeg AV1脚本开发与输入从谷歌和在多个使用 流媒体 articles 测试证明我的流媒体学习中心网站:

[au:.mp4 -c:v libaomm -av1 -strict -2 -b:v 1890K -g 60 -keyint_min 60 -sc_threshold 0 -row-mt 1 -column 1 -row- rows 0 -threads 16 -cpu-used 8 -pass 1 -f matroska NUL &

[au:.mp4 -c:v libaom-av1 -strict -2 -b:v 1890K -maxrate 3780K -bufsize 3780K -g 60 -keyint_min 60 -sc_threshold 0 -row-mt 1 - tile_columns 1 - and - tile_rows 0 -threads 16 -cpu-used 3 -pass 2 football_libaom_2.mkv

AOMEDIA的AOMENC

这个脚本是根据Visionular的输入开发的，并经过谷歌的审查. 这篇文章也发表在了流媒体学习中心的几篇文章中，供大家评论:

aomenc.exe football_10.Y4m -宽度=1920 -高度=1080 -fps=30000/1000 -通过=2 -帧内延迟=25 -最终使用=vbr -目标-比特率=1890——线程数=16——cpu使用率=3——kf-min-dist=60——但是-sz=2000——maxsection-pct=200——kf-max-dist=60 -o football_
aomenc_2.webm

视觉的极光编解码器

这个脚本是由Visionular提供的:

aurora_av1enc.exe Football_10.y4m——fps=30000/1001——pass =2——tile-columns=1——tile-rows=0——end-usage=vbr——target-bitrate=1890——threads=16——kf-min-dist=60——kf-max-dist=60——buf-sz=2000——maxsection-pct=200——preset= slow_football_vs_2.webm

英特尔/ NETFLIX的SVT-AV1

该脚本是根据英特尔可扩展视频技术AV1 (SVT-AV1)编码器用户指南开发的，并由英特尔审查:

SvtAv1EncApp -i Football_10.y4m -w 1920 -h 1080——fps-num 30000——fps-num 1001——keyint 64——forward 64——irefresh-type 2——rc 1——tbr 1890——vbv-bufsize 3780——preset 8 -b Football_SVT_2.Webm——output-stat-file stat_file.stat

SvtAv1EncApp -i Football_10.Y4m -w 1920 -h 1080 -fps-num 30000 -fps- dom 1001 -keyint 64——向前看64——刷新类型2——rc 1——tbr 1890——vbv-bufsize 3780——预设2 -b足球svt_2.Webm——input-stat-file.stat

FFMPEG X264

这是一个由我开发的FFmpeg脚本，并在多个中使用 流媒体 流媒体学习中心记录的文章和测试:

ffmpeg -y -i football - 10.mp4 -c:v libx264 -threads 16 -b:v 1890K -preset verslow -g 60 -keyint_min 60 -sc_threshold 0 -tune ssim -pass 1 -f mp4 NUL &

ffmpeg -i Football_10.mp4 -c:v libx264 -线程16 -b:v 1890K -maxrate 3780K -bufsize 3780k -preset verslow -g 60 -keyint_min 60 -sc_threshold 0 -tune ssim -pass 2 Football_x264_ssim_4.mp4

FFMPEG X265

这是另一个由我开发的FFmpeg脚本，并在多个中使用 流媒体 流媒体学习中心记录的文章和测试:

ffmpeg -y -i football - 10.Mp4 -c:v libx265 -threads 16 -preset veryslow -tune ssim -x265-params比特率=1890:keyint=60:min-keyint=
60: sceneccut =0:open-gop=0:pass=1 -an -f mp4 NUL &

ffmpeg -y -i football - 10.mp4 -c:v libx265 -threads 16 -preset veryslow -tune ssim -x265-params比特率=1890:vbv-maxrate=3780:vbv-bufsize=3780:keyint=60:min-keyint=60: sceneccut =0:open-gop=0:pass=2 -an Football_x265_ssim_4.mp4

性能比较

这就是我选择编码设置的方式. 性能比较如何?? 如前所述，你在 Table 4，它显示了两个独立的10秒编码的平均时间、比特率和质量结果. 它有三个主要部分. The top section, AV1编解码器测试, 显示通过前面所示的编码字符串进行质量比较测试时所取得的性能.

Ozer AV1

Table 4. 性能试验

Here, 我们看到，在相同的质量水平下，Visionular比FFmpeg快30%, 如果您正在运行自己的编码场，这应该转化为编码成本的相应降低. 然而，在使用cpu 2时，SVT-AV1比FFmpeg慢33%，比Visionular慢125%.

第二部分, 经测试的其他编解码器, 显示x264和x265配置的质量比较. 在这里，我们看到Vision-ular和x265编码所花费的时间大致相同, 尽管Visionular的产品质量更高. For reference, 它需要大约6个VMAF点来实现“只是明显的差异”,” or JND, 75%的观众会看到. So the 2.x265和AV1编解码器之间的VMAF点差异可能对大多数观众来说并不明显. However, 而x264是目前最快的编解码器, VMAF质量落后13个VMAF点, 或多于2个jdn, 这当然是有意义的.

第三部分“参考”显示了另外两个数据点. 首先是x265-slow，比veryslow快8倍，只下降了2个VMAF点. 尽管生产者各不相同, 如果你比较AV1和x264最实用的预设, 你应该比较使用慢速预设的x265和使用cpu使用的AV1.

Finally, 我们看到使用cpu的7确实大大加快了SVT-AV1的编码时间, 虽然预测的2%的质量下降实际上被证明是4%.5%，仍然低于JND的门槛，但越来越接近了. 请注意，所有其他AV1编解码器都提供了更快的编码模式, 所以仅仅因为我展示了SVT-AV1的快速编码时间并不意味着它是性能之王. 我运行这个测试的原因是图2中奇特的质量模式，它似乎表明使用cpu的7是一个独角兽，具有高速和卓越的质量. 唉，在这些有限的测试中，情况并非如此.

启动问题

Anyone who’s run structured encoding comparisons will tell you that it’s never a straight line; you don’t know what you don’t know until you finish your analysis, 任何重大的启示都会让你的日子变得毫无意义, if not weeks, 以前的工作. SVT-AV1也是如此, 似乎是在报复英特尔，因为英特尔违背了自己的意愿，在分析中加入了编解码器. 事情是这样的.

作为背景，VMAF和SSIMPLUS等指标为整个文件输出单个分数. 当数字显著变化时, 在视频的持续时间内比较分数是很有用的, 你可以看到 Figure 3 来自莫斯科国立大学视频质量测量工具, 它比较了Visionular(红色)和SVT(绿色)输出的最高质量的sint文件。.

Figure 3. SVT-AV1在16个测试文件中有5个在第一个GOP中出现启动问题(点击查看大图).

不要和自己约会，我从来都不是 Lost in Space fan, 但是当你在文件开头看到这样的质量缺陷时, 你不得不怀疑是否存在只影响前两个GOP的启动问题, then resolve. 即使在一个2分钟的测试文件中，这些问题也是无关紧要的, 但在10秒的片段中非常重要.

我检查了CSV VMAF输出文件，发现46-48帧的评级为88.28, 88.40, and 86.68. 第49帧是新共和党的开始，第49帧至第51帧的评分为93.58, 93.23, and 93.05. 显然，有一个问题.

To resolve it, 我在这些文件的FFmpeg开头添加了一个4秒的存根, re-encoded, 然后提取重新测量VMAF和SSIMPLUS前的4秒. Figure 4 显示修复后的相同sinl比较. 而Visionular则更高, 差别要小得多, 而且分数更加真实. 如果你自己测试SVT-AV1, 或者阅读其他评论, 一定要检查这些启动问题, 哪个可以使较短的片段得分无效.

Figure 4. 修复问题并产生更相关的结果(点击查看大图)

请告诉我该死的分数

好了，够了，我们到达吧. 我用VMAF和SSIMWAVE的SSIMPLUS指标进行了测试. 在VMAF比较中(参见 Figure 5)， Visionular是整体领先者，所有AV1编解码器都优于x265. 请注意，为了更好地呈现图表顶部的聚集数据点，我在速率失真曲线中保留了x264.

Figure 5. VMAF度量的速率失真曲线(点击查看大图)

Table 5 显示了所有编解码器的BD-Rate计算, including x264, 这是我用著名的Excel计算出来的 macro (go2sm.com/slcbdrate). 最简单的阅读方法是选择一个编解码器/行，然后逐列阅读. Negative numbers mean the line/codec is more efficient than the column/codec; positive numbers, the reverse.

表5a

Table 5. VMAF度量的BD-Rate统计信息

所以选择视觉线，极光线编解码器可以产生与FFmpeg相同的质量.数据速率降低41%，质量与x264相同.数据速率降低76%，以此类推. 负数是好的, 如果所有的负数都在一条线上，那就代表着最高质量的技术.

相反，当使用VMAF评分时，您必须将x265编码的数据速率提高23.虽然x265证明了35%，但生产出与libaom相同质量的产品的成本为15%.比x264效率高20%.

Figure 6 显示了SSIMPLUS度量的速率失真曲线. 虽然Visionular仍然是整体领先者，但SSIMPLUS x265已经超过了SVT-AV1.

Figure 6. SSIMPLUS度量的速率失真曲线

BD-Rate出现了 Table 6 提供有价值的附加细节. Again, 拥有所有底片意味着visi - ionular提供了最好的质量, 虽然x265之间的差距缩小了不少. 在这两个指标中, aomenc和libaom的质量差异较小, 随着优势逐渐显现.

Ozer AV1

Table 6. SSIMPLUS度量的bd速率统计

编织不完美的挂毯

每当我完成这样一个数据密集型的故事, 我想到了希腊神话中的阿拉克尼, 雅典娜把他变成了一只蜘蛛，织出了一幅完美的挂毯. 我四年级的时候就知道了, 这就是为什么所有的希腊编织者在每次编织中至少会有一个错误.

这个故事不止2个,000个数据点分布在不同的测试文件中, codecs, data rates, encoding times, quality metrics, preset trials, 调优机制, and the like. 所以尽管我尽力了, 我很确定我不需要故意插入错误来避免阿拉克尼的命运.

[编者注:作者将文章提交到9月份的《百家乐软件》杂志上发表后，一直在进行测试和更新. 因此，本文中的一些数据点与杂志中出现的数据点有所不同. 此版本的数据是最新和最准确的.]