AV1编码器的优化及其在流媒体和实时通讯中的应用

编者按：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是一个开源的代码库，欢迎大家使用、测试，如果可以的话，欢迎大家的参与和贡献。

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