编者按：AV1 视频压缩格式是由开放多媒体联盟 (AOMedia) 开发，并于 2018 年初最终确定。AV1 具有功能强大的编码算法，与其前身 VP9 相比，AV1 的压缩性能提升了 30% 以上。但是，AV1 编码器的复杂性也远高于 VP9 编码器。对此， LiveVideoStack 特别邀请到了来自 Google 的王云庆老师，为我们分享介绍 AV1 编码器的优化以及其在流媒体和实时通讯中的应用。

文 / 王云庆

整理 / LiveVideoStack

大家好，我是王云庆，从清华毕业后到美国获得 Computer Science 的硕士。我从 2007 年开始做视频压缩有关的工作，在 Google 工作了十多年。现在的主要工作是 AV1 编码器的优化。

我今天要分享的题目是 AV1 编码器的优化及其在流媒体和实时通讯中的应用。

我们分四个部分来讲：首先简单介绍一下 AV1；然后讲一下 VOD 的 encoding，也就是在视频点播中的编码；第三，我们讨论实时通讯中 AV1 的编码；最后，我们做一个总结。

01 Introduction：libaom AV1

我们先简单看一下 AV1。AV1 是由 AOMedia（开放多媒体联盟）开发的，就是由多家公司联合起来开发一种开源且没有版税的视频编码格式，AV1 就是其第一代编码格式。AV1 于 2018 年完成，在那个时候，AV1 的编码器复杂程度是非常高的。但是 AV1 与它的前身 VP9 相比，如果在同样的视频质量条件下，它能够提供超过 30% 的 bitrate 的节省，所以它的压缩率还是非常高。Libaom AV1 是 AV1 的参考代码，我把它的 link 放在了上图，大家有兴趣可以测试一下。

AV1 增加了很多功能强大的压缩工具，复杂性非常高，所以我们的目标就是优化 AV1 的编码器，使得它能够真正用在产品线上。优化工作着重于以下两个应用方面：第一个是 VOD 的 encoding。像 YouTube 这种编码器一般都是离线进行，所以它对编码器的速度要求没有那么高，但是它对压缩率的要求非常高；第二种就是实时通讯的编码。大家都知道实时通讯中要求非常快的实时编码器，而 AV1 的优势就在于它能够允许在非常低的字节率的情况下进行视频通讯，比如说 Google 的 Duo 是一个手机上面的视频应用程序，它可以在 20-30kbps 这么低的字节率情况下实现手机上的视频通讯。这对一些新兴市场的用户来说是非常有用的，Duo 在 2020 年就已经开始使用了。现在，我们下一个目标是 Google 的 Chrome。WebRTC 也是开源的，有兴趣大家可以看一看。

02 VOD encoding

第二部分我们介绍 VOD 的编码。

这是一个简单的 AV1 编码器概述，第一个是预处理阶段，其主要目的是 rate control，就是怎么选择 frame 或者 block 的 quantizer；第二个阶段是真正的编码阶段。主要任务就是决定每一个 block 要选择用什么样的 partition，mode，以及 transform 等等；之后会对 frame 进行滤波，AV1 支持三种 In-loop 的滤波器；最后一个阶段要把 Bitstream 打包写到一个文件中。编码器的整个过程中，绝大多数的时间花在了编码阶段。下面，我们就主要讲一下这个阶段的技术优化。

首先是 Partition 搜索。在 AV1 中，最大的块尺寸是 128x128，最小块的尺寸可以到 4x4。对每一个尺寸的块，可以选择 10 种 partition 的类型，例如：None，Split，Rectangular，及 AB partition 类型。所以说搜索空间是非常巨大的。我们主要用的方法是机器学习，就是建立 ML 模型，对每一种 partition 的尺寸和类型，我们可以决定是否要去评估它，还是可以略过它。这样就大大减少了搜索空间，达到非常好的优化结果。

下一步就是我们提到的 mode，即 prediction mode 的决策。在 AV1 中，一个 block 的 prediction mode 选择有超过 150 种。理论上，评估一个 mode 的好坏要基于它的 RD 成本，成本越低则越好。mode 决策，我们采用一个多级的方法。在初始快速评估级，因为 RD 成本计算非常慢，我们就不去精确计算 RD 成本，而是用一个近似模型来估计出 RD 成本。虽然 RD 成本的精度不高，也能够快速排除一些非常不适合的 mode。第二级评估中，我们进行 RD 成本的简化计算，进一步排除很大一部分不适合的 mode。所以，只有几个候选 mode 留下来。在最后一级，我们仔细评估每一个候选 mode，最后通过它们的 RD 成本找出最好的 mode。

AV1 支持多种变换类型。我们在优化中间采用了机器学习的模型。基本思路是分析 prediction 之后的 residue 信号，通过分析找到有用的 feature。如果这些 feature 跟最后变换的类型相关的话，就可以利用它们估计哪一种变换类型是比较适合的。通过这样做优化，达到一个加速的结果。

我们简单看一下 AV1 跟 VP9 的性能比较。对产品线上的应用，我们推荐 AV1 用 speed2 到 speed6。对 VP9，我们推荐用 speed1 到 speed4。这些编码速度足够快，而且提供很好的速度与压缩率之间的平衡。上表中给出了 AV1 的 speed2 跟 VP9 的 speed1 的比较。我们用不同分辨率的一些视频来做测试，采用了四种指标，即：AVG PSNR，Overall PSNR，SSIM 还有 VMAF。可以看到 AV1 的 speed2 相比较于 VP9 的 speed1，平均可以给到超过 30% 的 BD-rate 的节省，在所有四种指标上都有这样的表现。

在上图中，我们把编码器的速度也考虑进来，这里给出的数据都是单线程的结果。竖轴是 BD-rate 节省的百分数，是由前面提到的四种指标平均得到的。而横轴是相对的编码器时间。可以看到，上面这条曲线是 VP9 的 speed1 到 speed4，下面的曲线是 AV1 的 speed2 到 speed6。AV1 speed2 的 BD-rate 的节省超过 30%，但它的编码时间差不多是 VP9 speed1 的六倍多，比较慢。再来看 AV1 的 speed 5，它跟 VP9 的 speed2 的编码时间基本上是一样的，而且比 VP9 speed2 提供 22% 的更多的 BD-rate 节省。从这点上也可以看到，相比于 VP9 来说，AV1 潜力更大，它能够带来的 BD-rate 的节省更多。

在编码器中，为了能够更好地加速，多线程的支持也是必不可少的。现在 AV1 编码器中，我们有三级多线程的实现。首先，最直接的，是基于 tile 的多线程。在 AV1 中，tile 都可以独立的编码和解码。每一个 tile 中间，我们还有基于行的多线程。行之间的编码不是独立的。比如说，下面一行中的块要开始的话，它上面一行右边的块应该先完成，所以有依赖性存在，在实现中要正确处理。上图给出了一个简单的多线程例子，这幅图里一共有两个 tile，每一个 tile 有四行。我们会建一个 job queue，把所有 job 放进来依次处理。“Tile + 行” 的多线程性能比单纯只基于 tile 的多线程要好很多。

最近我们完成了 frame 并行处理 （FPMT）多线程。如果在 “tile + 行” 的多线程之外，还有更多的线程可以用的时候，你可以再打开 FPMT，这样可以达到更好的效果。要使用 FPMT，用户要在编码命令设置中打开它，即：“--fp-mt=1”。这样，如果你设置的可使用线程足够多的话，它就会启动。

大家可能知道，在 AV1 编码中，一个编码单元是一组 frame（即：GOP）。FPMT 实现是基于 AV1 GOP 结构。比如，AV1 里比较常用的就是 16 个 frame 一组的 GOP 或者 32 个 frame 一组的 GOP。这里我给了一个 GOP=16 的例子，我们来看表中最下面的一行，从 frame 0 开始，0 是 Key frame，下一幅是 frame 16，叫做 Alt-ref frame，然后再到 frame 8、frame 4。接下来，我们稍微改变了一下编码的顺序。本来 frame 2 下来是 frame 1，frame 3，然后，frame 6，frame 5，frame 7。现在为了能够并行处理这些 frame，我们把 frame 顺序改成 2，6 然后再做 1、3、5、7。因为 1、3、5、7 都是 leaf frame，可以被设置为 non-reference frame，即：这些 frame 不会被用来作为别的 frame 的参考 frame，所以对它们的编码质量要求不高。这样的话，这四个 frame 可以并行处理，然后下一层的 2 和 6 也可以拿来并行处理。这样的顺序调整允许更多 frame 的并行处理，达到的效果会更好。

这里我们给出一个应用实例，来显示编码器多线程的 scaling ratio。这是一个 1080p 和 4K 的视频测试结果，我们用的 tile 是 8 个（2 rows x 4 columns）。对于 4K 视频，可以看到，如果线程数足够多，比如说 16 或者 24 的时候，多线程的速度是单线程速度的 10 倍，达到了很好的加速效果。如果没有 FPMT 的话，在线程到达一定数量的时候，scaling ratio 就饱和了。有了 FPMT，在有更多线程可以利用的时候，scaling ratio 还可以提高。这就进一步提高了多线程编码器的性能。

03 RTC encoding

下面我们看一下实时通讯中的 AV1 编码。就像我们开头讲的，在实时通讯的应用中，为了保证正常的视频通话，编码器的速度一定要非常快而且不能有延迟。所以，实时编码不可能像 VOD 情况下可以用两个甚至三个 pass 的编码来达到好的压缩效率，在这种时候，只能用一个 pass 的编码，不能用任何 lookahead frame，所以，基本上来一个 frame 就得立刻去处理它。现在 AV1 的实时编码器的速度范围是 speed5 到 10。Speed 5 和 6 共用了一些 VOD 代码，压缩率高，但也复杂一点。Speed 7-10 是专用的实时代码，所以会更快一些。

在多线程的支持上，主要是基于 tile 和基于行的多线程。因为不允许延迟，所以 frame 的并行在这里不实用。还有，AV1 RTC 编码器中支持 scalable video coding（SVC），主要是 spatial layers 和 temporal layers。

Rate control 方面的话，对于 RTC 来讲，因为没有太多关于视频 frame 的信息，所以多用 constant bitrate（CBR），而且在 AV1 RTC 编码器中还会支持一些 adaptive quantization mode，比如：Background cyclic refreshing。因为在视频通话中，为了保证通话的平稳，单一 frame 编码后的 bitstream size 不应该比平均 frame bitstream size 大太多。所以，这种情况下，我们采用了一个周期性的 refreshing。比如，在每一个 frame 中选定某一个百分比的一些块，而且这些块会是后续的 frame 的参考。这样，我们就可以增加这些块的 bits，提高压缩性能，但不会增大单一 frame 的 bitstream size。这也是实时通讯编码器与 VOD 编码器设计上的不同。

这里给出 AV1 和 VP9 实时通讯编码器的速度和 BD-rate 节省的一个比较。因为 Google Meet 使用了 VP9 speed7，所以我们这里用 VP9 speed7 作为 baseline。可以看到，AV1 的 speed6 能够提供 37% 的 BD-rate 节省，但是相应的话，它的编码器的时间会到五倍多，比较慢。AV1 speed9 和 10 已经跟 VP9 编码器的时间类似，而且还可以提供 13% 到 16% 的 BD-rate 节省，所以从这里也能够看出 AV1 的潜力还是更大一些。

下面就是一个简短的总结。经过这几年的优化，Libaom 的 AV1 给 VOD 的应用提供了一个非常优秀的解决方案，希望我们的工作能够促进 AV1 的广泛应用，满足用户的所有需求。AV1 RTC 编码器优化还在持续地进行中，如果你对 libaom AV1 代码熟悉的话，应该会看到最近编码器性能有很大的提高。从去年到今年，我们的目标是继续优化，希望能够提供一个非常快的实时编码器，而且这个编码器还能提供良好的视频压缩率。最后，libaom AV1 是一个开源的代码库，欢迎大家使用、测试，如果可以的话，欢迎大家的参与和贡献。

以上就是我的全部分享内容，谢谢大家！