2022年9月8日
By Jan Ozer 特约编辑
专题文章

AOMedia兑现了SVT-AV1的承诺

I2020年8月, 开放媒体联盟(AOMedia)成立了一个软件工作组，“使用英特尔开发的可扩展视频技术AV1 (SVT-AV1)编码器” ... 创建AV1编码器实现，在应用程序之间提供出色的视频压缩，以消除计算复杂性的方式，为不断增长的视频传输市场进行权衡.“当时发布的测试表明，SVT-AV1要在其他AV1编解码器中脱颖而出，还有很长的路要走.

例如, 在一个月后发表的对比中，我发现在我测试的四个AV1编解码器(amedia的lib - om)中，SVT-AV1是最后一个, Visionular的Aurora1, aomenc, 和SVT-AV1), 虽然效率只比FFmpeg / libaom-AV1低3%左右. At the time, SVT-AV1有几个严重缺陷, 包括一个不完整的二次通过率控制. 在2020年的报告中, 莫斯科国立大学(MSU)发现，SVT-AV1比libaom落后4个百分点，比aurora落后25个百分点.

随着最近版本1的发布.0, SVT-AV1在质量上似乎已经赶上了libaom, 具有非常明确的性能优势. 它的双通过率控制经过了测试和验证. 如果你今天正在创建一个AV1编码工作流程，强调编码速度和质量, SVT-AV1绝对应该在你的候选名单上.

关于可扩展视频技术

让我们首先简要介绍一下可扩展视频技术(SVT)是什么以及它是如何工作的. 根据英特尔最近的一份白皮书, “SVT架构旨在最大限度地提高英特尔至强可扩展处理器上SVT编码器的性能. 它是基于三维平行的.其中最重要的是基于段的并行性, 哪一种“将每张图片分割成片段，并并行处理一张图片的多个片段，从而在不损失视频质量的情况下更好地利用计算百家乐软件?.”

这种技术与对每个帧进行完整编码可以提供最佳质量的观点相反. 例如，Avidemux的编码指南说，“H.264允许编码器将每个帧分割成几个部分. 这些部分被称为“切片”.使用多个切片(每帧)的优点是，这些切片可以独立地并行处理. 这允许在H中轻松实现多线程.264编码器和解码器. 不幸的是，使用多个切片会损害压缩效率! 切片用得越多，效果越差!”

So, SVT尝试做的很大一部分是分割图像，以在保持质量的同时获得处理效率. 早期的努力并不令人鼓舞. 如图所示 Figure 1 从前面提到的密歇根州立大学的报告中, SVT-HEVC比x265落后51个百分点, 而SVT-VP9则比VP9落后129个百分点, 是什么让SVT-AV1和amedia之间4%的差异看起来像是一个突破.

AV1

Figure 1. 根据莫斯科国立大学2020年的研究，早期的SVT表现并不令人鼓舞.

测试参数

现在你已经熟悉了SVT-AV1, 让我们探索一下用于测试和质量比较的编码参数. 声明一下，我测试的是版本1.0.由英特尔SVT-AV1开发团队成员提供的SVT-AV1的0. 我测试了FFmpeg版本2022-06-09-git5d5a014199，下载自 www.gyan.dev. 我在一台运行Windows 7的40核HP Z840工作站上执行了所有编码测试，该工作站安装了两个运行速度为3的英特尔至强E5-2687W v3 cpu.10ghz, 32GB内存.

选择预设

编解码器开发人员创建预设来配置控制编码时间/编码质量权衡的编码参数组. 这允许编解码器用户选择适合其特定应用的成本和质量水平. 每当您开始使用新的编解码器或编码器时, 您应该用自己的源素材对编解码器进行基准测试，以探索这些权衡并为您做出最佳决定. To do this, 您应该选择几个有代表性的测试片段, 使用所有预设和其他一致的设置对它们进行编码, 编码时间, 测量质量. With FFmpeg, 使用-cpu-used开关控制AV1预设, 设置范围从0到8，默认设置为1.

Table 1 显示了使用FFmpeg和libaom-AV1编码时两个10秒测试片段的平均结果. 预设0, 最高质量的预设, 编码一个10秒的测试片段平均需要3:24:33(小时:分:秒)(这就是为什么用更长的片段进行测试具有挑战性的原因). 使用最快/最低质量预设，用时1:06(分:秒). 这告诉你在这个测试台上, FFmpeg / libaom-AV1 isn’t capable of encoding a live stream; in fact, 最佳性能接近7倍实时.

AV1 table 1

Table 1. 用FFmpeg和libaom-AV1编码时间和质量

为了衡量整体质量，我使用了视频多方法评估融合(VMAF) 调和平均法. 评估暂态质量, 我使用了低帧VMAF, 测试文件中哪一帧的VMAF分数最低.

在表1底部的Delta行中, 时间增量将最慢的分数除以最快的分数，显示最慢的得分为185分.是最快的95倍. 您还可以看到最快和最慢预设之间的总体VMAF差为3.77. 为视角, 奈飞公司表示，6分的差异代表观众会感觉到的明显差异(JND), 尽管其他研究人员发现3个VMAF点构成了JND. Either way, 特别是在最高质量和最低质量的预设之间没有明显的区别, 你会看到, 与SVT-AV1比较.

可视化时间/质量之间的权衡, 我画了三个因子，时间, VMAF, 和低帧vmaf -为每个预置从0(最快预置/最低质量)到100(最慢预置/最高质量)的刻度. 你可以在 Figure 2.

VMAF

Figure 2. 绘制libaom-AV1编码时间与质量的关系

每个应用程序都是不同的，每个制作人都有自己独特的风格. 戴上我虚构的视频点播内容制作人的帽子, 我认为预设4是逻辑上的起点, 在VMAF和低帧VMAF中都有实质性的跳跃. 我是否需要增加大约50%的编码成本来实现0.4 . VMAF改进与预设? 可能不是. 除非我的流量非常大，否则我不会考虑预置2、1或0.

As an aside, 虽然我们在这个分析中只关注编码时间和质量, 第三个因素, bandwidth, 也在发挥作用. That is, 所有的发行商都应该从选择预设和比特率所能达到的目标质量水平开始分析. 预置2, 达到目标质量水平所需的比特率将低于预设3, 因此，随着观看量的增加，带宽节省将越来越多地抵消编码时间成本.

相对较低的音量, 选择更快的预设和节省编码时间可能是最好的策略. 如果你的流媒体将被观看数十万次或更多, 为编码支付更多的费用并节省带宽可能是有意义的. (我在一篇题为选择一个x265预设- ROI分析.)对于大多数生产者, 我认为预设4或预设3是FFmpeg / libaom-AV1最相关的选择.

选择预设:SVT-AV1

现在我们来看看SVT-AV1. Table 2 显示了SVT-AV1预设0-12的相同数据点, 实际范围为-2-13，默认值为10. 研究结果揭示了几个显而易见的问题.

SVT-AV1

Table 2. 用SVT-AV1编码时间和质量

首先，VMAF和低帧VMAF的编码时间范围要大得多. 特别是, 三个预设(10), 11, 12)能够进行实时编码, 与预设非常接近, 尽管质量差距很大, Netflix的数字扩展到2 JND，低帧接近3 JND.

Figure 3 绘制编码时间/质量权衡图. 从视频点播的角度来看, 看来预设6是起始点, 大多数制作人选择在2到4之间. 如前所述, 随着预期的视图计数为您的视频增加, 您应该倾向于使用高质量的预设.

编码时间/质量

Figure 3. 绘制SVT-AV1编码时间与质量的关系图

从更大的角度来看, 性能和质量的范围使SVT-AV1比力宝- av1更有用, 甚至支持实时AV1应用程序. 我不知道libaom-AV1中有哪些配置选项可用, 但如果它的开发人员探索如何扩大编码时间和质量的传播，使这种编解码器像SVT-AV1一样灵活，那将是有帮助的.

选择支数

现在我们已经选择了一个预设，让我们来讨论线程. 此分析将帮助您了解命令字符串中应该包含哪些线程计数，并帮助您在多核计算机上选择最佳的云实例或编码策略.

FFmpeg / libaom-AV1

FFmpeg / libaom-AV1, 您可以使用-threads命令控制应用于编码的CPU线程数. Table 3 展示了我在试图确定任何配置选项的最佳设置时所进行的分析. 基线列显示命令字符串中没有设置时的结果, 哪一个调用默认设置. 随后的每一列都显示了将原本相同的命令字符串配置为使用命令字符串的结果, two, four, eight, 16, 在40核HP工作站上有32个线程. Delta列显示了最高分和最低分之间的差异.

找到最佳的线程设置

Table 3. 寻找FFmpeg / libaom-AV1的最佳线程设置

您可以在编码速度上看到结果, bitrate, 三个质量变量-谐波平均VMAF, 低帧VMAF, 还有标准偏差——最后一个是衡量水流质量可变性的指标. 绿色背景代表最好的分数，黄色背景代表最差的分数.

就性能而言，毫不奇怪，我们看到一个线程是迄今为止最慢的选项. 我们还看到16个线程是最快的设置, 16和8 /32之间的性能差异可以忽略不计. 由此，我猜想libaom-AV1可以使用的最大线程数是8个.

令人惊讶的是, 单线程编码在所有三个度量中质量最低, 尽管Delta列表明差异是无关的. 几乎所有其他替代品的质量结果都是相同的, 因此，生产效率应该成为重点. Clearly, 任何超过8个线程的设置都没有意义, 如果您正在配置云实例, 8也应该是最大值. 但是八根是最理想的线程数吗? Table 4 讲述故事.

编码工作站最佳线程数

Table 4. 为FFmpeg / libaom-AV1的编码工作站寻找最佳线程数

使用表3所示的平均编码时间, 表4计算了使用每个线程数编码一个小时的AV1视频所需的小时数. 然后，它添加了Amazon Web Services (AWS)计算实例的小时成本 go2sm.com/awspricing 并计算所示的四种线程数的每小时成本.

有趣的是，使用单线程机器可以获得最便宜的每小时成本. 为什么会这样?? 因为正如 Figure 4, 编码成本呈线性增长, 当额外的线程提供越来越低的速度增加时. 从一个线程增加到两个线程的成本增加了一倍，但编码速度只增加了1.8x. 从一个线程增加到八个线程，成本增加了8倍，但吞吐量只增加了2倍.99x.

speed vs. 实例的成本

Figure 4. 绘制编码速度的增长与实例成本的关系

Of course, 该分析假设，供应和管理更多编码站所涉及的工作不会超过所节省的成本. Either way, 配置超过8核的编码站可能没有经济意义, 更低的线程数可能更具成本效益.

多核编码站的高效工作

同样的逻辑也适用于在多核上分散生产编码 workstation. 例如，在16核工作站上例如，您可以实现更快的吞吐量使用四个编码，每个线程使用四个线程与使用八个线程的两个编码相反. 当然，运行多个编码会增加一些开销，从而降低整体操作速度. 例如, 在我的40核工作站上, 10秒的足球测试片段的单次编码耗时4:23(分:秒). 当我同时编码8个文件时，平均时间增加到5分49秒，大约高出32%. Still, 如果您有能力在单个工作站上部署多个实例, 一些不同线程值的实验将提供有用的指导.

用SVT-AV1选择最优支数

鉴于之前共享的SVT的解释, 线程数越多，性能越好, 和SVT交付. Still, 你会看到, 同样的分析对销售多核至强处理器的影响可能比您想象的要小.

Table 5 显示了与SVT-AV1的-lp开关相关的编码速度/质量权衡, 哪一个控制分配给任何编码任务的逻辑处理器的数量. Baseline是最快的，因为它似乎将所有逻辑处理器分配给任务, 虽然基线只比32个线程快一点.

svt-av1的最佳线程设置

Table 5. 寻找SVT-AV1的最佳线程设置

从质量的角度来看, 在这里，一根线的质量最好, 但是这个无关紧要. 这使得编码吞吐量和成本成为选择线程数(和-lp值)时最重要的因素。. 在这方面, 额外线程的速度回报惊人地递减，这决定了中所示的结果 Table 6.

svt-av1的最佳线程数

Table 6. 寻找SVT-AV1编码工作站的最佳线程数

如表6所示, 从一个线程跳到八个线程所带来的吞吐量略高于AWS对cpu的收费, 使8个线程成为最便宜的编码选项. From there, however, 速度增加的减少意味着线程数越高，每小时的成本就越高. 这些发现表明，超过8个线程的编码配置可能不具有成本效益.

These results come with all of the usual caveats; your findings may certainly vary. 我在1080p 8位内容上进行了这些测试, 4K和8K HDR镜头的结果可能完全不同. I’m also predicting cloud throughput from results posted by an older desktop machine; results on newer versions may be different. 英特尔对AMD是另一个潜在的差异化因素.

高级点是lib - om- av1和SVT-AV1, 您不应该假设更多的内核提供最经济有效的吞吐量. 如果您准备扩展AV1编码，并且需要确定购买哪些工作站或提供哪些云实例, 用你的简单素材和目标输出进行一两天的测试，应该能提供非常清晰的方向.

这是我们的优质烘焙大赛.

比较质量

这是我用于FFmpeg / libaom-AV1的编码字符串，默认选项为绿色. 这意味着如果您删除它们，您将得到相同的结果. 我喜欢保留它们，因为它简化了字符串与其他比较中使用的字符串的比较.

ffmpeg -y -i football - 10.mp4 -c:v libaom-av1 -b:v 1500K -g 60 -keyint_min 60 -cpu-used -auto-alt-ref 1 -线程8 -栏1 -栏0 -row-mt 1 -lag-in-frames -pass 1 -f matroska NUL & \

ffmpeg -y -i football - 10.mp4 -c:v libaom-av1 -b:v 1500K -maxrate 3000K -g 60 -keyint_min 60 -cpu-used -auto-alt-ref 1 -线程8 -瓦列1 -平铺-行0 -row-mt 1 -lag-in-frames 1 .足球.mkv

请注意，我在第一次测试中使用-cpu-used 8，在第二次测试中使用-cpu-used 4. 这是因为第一次使用的质量不会影响整体质量. 在我的工作站上，我将线程设置为8以获得最大的单编码实例吞吐量.

下面是用于SVT-AV1的命令字符串. 对于这些测试，我希望两种编解码器的编码时间尽可能接近相同.

SvtAv1EncApp -i输入.4万日元——1万日元——1万日元 1500 -mbr 3000 -键值2s -预设 3——pass 3——lp 8——tile-columns 0——tile-rows 0——enable-tf 1 -b output.ivf

With -cpu-used 4 in the second pass, FFmpeg delivered the files in 4:24 (min:sec; see Table 1). 我对SVT-AV1使用预设3，因为它以略快的3:48的速度传递文件(见表2). 注意，我使用三通道编码对本文生成的所有SVT-AV1输出进行编码, 虽然第一和第二关都很, very fast. 我还使用-lp 8来提高吞吐量和匹配libham设置.

Overall, 我测试了17个文件，时长从1分钟到4分钟不等, 有四个编码，每个编码产生输出，呈现在速率失真图中，并用于计算BD-Rate结果. 有人告诉我，将结果添加到合成图中在数学上是不正确的, 但我发现它对整体结果的总体衡量很有用. 所以请不要出现 Figure 5 给你那些擅长数学的同事.

17个测试文件的平均结果

Figure 5. 17个测试文件的平均结果

如图5所示，SVT-AV1在较低比特率下获胜，而libaom在较高比特率下获胜. Overall, 根据BD-Rate复合计算, SVT-AV1产生的质量与力宝- av1相同, 比特率节省为1.36%.

感觉有点失望，因为你一直读到最后, 结果发现SVT-AV1只节省了很小的带宽? Well, 我上次复习SVT-AV1的时候, 编解码器需要增加4%的带宽才能达到libaom-AV1的质量，并且在测试中实际上速度较慢.

现在，在支持基于软件的实时AV1编码的同时，SVT-AV1的质量略高于libaom-AV1. 对于版本1来说还不错.0. 虽然这可能不会引发从libaom-AV1向SVT-AV1的大规模迁移, 它确实能够实现一套完全不同的潜在AV1应用程序, 这只会加速AV1的采用.

展望未来

在我的测试中, 我必须将源MP4文件转换为Y4M格式，以便使用SVT-AV1独立编码器进行编码. Obviously, 在FFmpeg中的操作将消除这一点，并简化将SVT-AV1编码集成到现有的基于FFmpeg的工作流程中.

虽然您可以在某些FFmpeg构建中访问SVT-AV1, 这是单程票, 不是两三个及格, 哪一种能更好地控制硝酸盐含量和提高质量. Apparently, 为FFmpeg添加三通道功能需要大量工作，至少在2022年底之前可能不会实现. 所以，大多数开发人员都会使用我使用的ACT-AV1应用程序.

另一个悬而未决的问题是FFmpeg中libaom-AV1编解码器的持续生命力, 鉴于amedia已将其软件工作组的重点放在SVT-AV1上. 我给amedia的一位联系人发了一个问题，问他是否计划继续更新libaom-AV1及其独立编码器(aomenc)。, 但截至发稿前还没收到回复. Check the website 如有任何更新.

看看著名的AV1发行商，YouTube多年来一直在使用FFmpeg / libaom-AV1制作AV1. 因为在YouTube基于ffmpeg的编码农场中切换到SVT-AV1将需要大量的百家乐软件来获得适度的VOD生产收益, 似乎amedia将继续支持libaom-AV1(和它最大的用户)，至少在SVT-AV1完全使用之前, 包括三道编码, 在ffmpeg中是可用的，而且可能要长得多.