拍乐云基于AV1的实时视频系统技术实践

Posted 2021-12-09 LiveVideoStack_

点击上方“LiveVideoStack”关注我们

实时视频系统对于时延的要求极高，视频编码器必须满足实时性的要求。新一代视频标准AV1相比主流H.264在Rate-distortation性能的提升上是以复杂度的上升为代价的，当前应用设备的碎片化非常严重、设备的运算能力差异巨大，这些都是新技术落地实时系统面临的挑战。本次分享将围绕拍乐云在设计Pano Venus实时AV1通信系统时的一些技术实践展开深入分析与讲解，期望和大家共同探索实时视频技术的未来。

文 | 章琦

整理 | LiveVideoStack

     

我是章琦，英文名是Volvet，从事视频开发20年了，目前就职于拍乐云，曾就职于Cisco WebEx和网易。拍乐云致力于提供音视频的PaaS云服务，我们的核心团队主要来自Cisco WebEx。

今天的分享包括六个部分，第一部分简单介绍AV1的背景，包括视频编解码的历史和编辑码器最基础的概念。第二部分介绍Pano Venus产品和我们为什么开发基于AV1的实时通讯系统。第三部分简单分析AV1的复杂度，AV1的复杂度非常高，这也就表示将AV1落地于实时系统的挑战非常大，所以复杂度分析是设计AV1系统的基准和前提。第四部分是基于复杂度分析介绍拍乐云的AV1实时系统设计。第五个部分介绍AV1 Scalability，视频的可伸缩编码是非常热门的主题，但实际上可伸缩编码一直没有得到广泛的应用，借助于AV1，我认为它会迎来自己的机会。最后一部分我会分享拍乐云基于AV1的后续计划。

1. Introduction

视频编码标准的发展已经有近40年的历史了，在视频编码标准的发展中，国际电信联盟(ITU)和运动图像专家组(MPEG)这两个组织具有举足轻重的地位。

最早是视频编码标准H.120和H.261就是国际电信联盟在上个世纪80年代所制定，然后运动图像专家组制定了MPEG-1，MPEG-1是以VCD之名被大家所熟知的编码标准。

接下来两大组织联手成立了联合视频专家组(JVET)，联合视频专家组定了MPEG-2中的视频部分，也被称为H.262。MPEG-2是以DVD之名被大家所了解，可以说MPEG-2是迄今为止最成功的视频标准之一，绝不逊色于现在的H.264-AVC。

后来国际电信联盟又制定了H.263标准，运动图像专家组制定了MPEG-4，这两个标准都没有取得像MPEG-2这样的成功。然后两大组织再次联手（JVET）制定了H.264-AVC标准。H.264制定于二十一世纪初，到现在已经近20年，却依然在行业应用占据了绝对的领先地位，独领风骚二十年。

联合视频专家组在2014年制定了H.265-HEVC，其技术值得称道，但是专利费用的混乱和昂贵，阻碍了H.265在行业内的应用，无法撼动H.264的地位。JVET后续又制定了H.266-VVC，其专利授权问题依然需要被关注，如果H.266能提供比较友好的专利授权方案，未来会是充满期望的。

另一个重要的视频标准组织是以Google为代表的开放媒体联盟(AOM)，AOM制定的AV1标准，展示出超过H.265-HEVC的编码性能，拥有丰富的编码工具支持，可以极大地提高视频的压缩比，节省大量带宽。同时，AV1 作为开放媒体联盟 AOM 制定的第一代标准，除了有非常好的生态支持，还提供了免费的专利政策，相比 H.265 / H.266 等知识产权政策不明确的视频标准，有巨大的优势。清晰明确的专利政策也是 AV1 在产业界被推崇的一大优势。

除了上述三家标准组织，AVS也值得一提。AVS是我国自己的标准组织，它定义的AVS标准迄今已经发展到AVS-3，从AVS分享的数据来看，AVS-3具备了优秀的编码性能，不过要建立AVS的生态，依然非常困难。

虽然编码标准的发展经历了多个迭代，新的编码工具令人眼花缭乱，不过编码器的基本框架却没有大的变化。

从H.261到现在的H.266和AV1,  都依然是混合编码框架，其核心模块包括：块的分割(16x16~128x128)、基于块的预测（intra and inter prediction)、基于块的变换(transform)、量化(quantization)、熵编码(entropy coding)。对于开发视频应用的同学来说，不需要了解编码器和解码器的技术细节，不过需要了解一些最基本的概念，比如说关键帧(Key-frame/I-frame)。

所谓关键帧，就是它的块预测仅使用帧内预测(intra prediction)，这就意味着，关键帧并不依赖于它之前或者之后的帧，只需要关键帧的数据是完整的，就可以被正确解码（这个描述忽略了SPS/PPS等参数集, 参数集的重要性可以被认为是等同于关键帧），这就是在实时系统中，当解码遇到错误的时候，会采用关键帧请求的技术来恢复解码的原因。

另一个需要了解的概念是P-frame（实时系统中一般不使用B-frame, 因此本文避免提及）。P-frame也就是使用了前向预测的帧，它的解码会依赖于前面的某一帧或者某几帧，在编码器的实现中，可以采用非常灵活的前向预测结构，根据条件的不同，可以参考最近的前一帧(latest frame)，也可以选择稍微远一些的前向帧，利用long-term-reference技术，甚至可以选择非常早的帧，编码器的时间分级技术，本质上就是参考结构的选择。灵活的前向参考结构，可以结合实际使用场景和拥塞控制算法，衍生出丰富的变化。

2. Pano Venus

Pano Venus是拍乐云基于AV1推出的实时通信视频引擎，相比H.264码率平均降低40%~70%，并且可以在主流手机端实时运行，这也是国内AV1在实时系统中的首次落地。

众所周知AV1虽然性能好，但复杂度非常高，应用AV1对技术的挑战非常大。那么Pano为什么会选择AV1呢？早在我就职于思科时，曾经推动HEVC项目的落地，就遇到过这类问题，当时一位同学问我，基于H.264的系统运行的很好，还有必要做HEVC吗。HEVC复杂度很高，很多设备可能无法落地。基于H.264的codebase，引入更复杂的算法和更高级的工具集也可以对性能进行优化提升，相比于做HEVC是不是更容易看到收益，更容易落地。当时我没有能很好的回答这个问题，只是觉得拥抱新标准、新技术是理所当然的事。但现在想来，做新标准是一个具有挑战性的长期过程，新的标准意味着能够提升编码器的性能上限，所有新标准的性能提升都是for future的，也许在当下无法立竿见影地得到收益，但在未来一定有无限可能。

由于AV1的复杂度很高，它在实时领域的应用一直受到很大限制。我们早期使用AOM做编码的时候，在大分辨率下编1帧需要耗时好几秒，远远没有到产品化的条件，但是近几年Google的AOM Codec经历多次迭代后各方面性能都获得了提升，这也推动了AV1的落地可能性。

Pano Venus的研发过程中面临两大挑战：

1、低端设备：目前市面上有很多低端设备，比如IoT在设计低端设备时基于成本考虑会选择廉价的CPU和内存等，在这些设备上不说AV1，就是264都无法跑起来，所以AV1在这些设备上运行时一定会遇到很大挑战。

2、设备过热：虽然手机CPU计算能力有了很大改进但依然面临着严峻的手机发烫降频问题，用户手机上运行Codec的同时，还会运行美颜或其它高级算法，这些算法需要协同工作。AV1也是如此，即使在手机性能足以运行AV1时，依然可能会出现手机发烫降频，影响AV1的最终体验。所以我们在为AV1设定设备可以运行的条件时必须要考虑因长时间使用而出现的手机过热问题。

3. Complexity Analysis

一个新的Codec和旧的Codec，比如AV1和H264相比，复杂度的提升至少来源于两方面。一方面是AV1的coding tool，在AV1的标准中可以明显发现它的复杂度高于264，但具体高了多少需要进行实际测试分析。另一方面是模式的选择，新的Codec会增加很多可选模式，举个例子，Intra编码在H264中，16×16有4种预测模式，4×4有9种预测模式，而AV1有48种，可以想象在做最优选择时复杂度将会上升很多。另外H264中最大块是16×16，而AV1最大块是128×128，其树形分割比H264更复杂，综合来看AV1的复杂度相较于H264高出非常非常多。所以如果H264在设备上运行都会出现性能问题，那么AV1的运行只会更加困难。

AV1有几个非常好的Open source都可以作为我们的benchmark，如AOM的encoder、decoder、VideoLAN的Dav1d。

图中是用AOM Encoder做的分析，编码参数来自AV1 Team的工程师Jerome在LVS中分享的AV1在Real-time档的性能，speed设置为9，是目前AOM Encoder实现的最快的一档，codebase是它的3.1。

首先来看解码器的复杂性测试，解码器用的是Dav1d，我的设想是对编码工具集的测试可以从解码的复杂度中得到一定体现，它们的量级应该是相当的。测试设置为会议场景下的码流，AV1的码率大概是H264的60%。264的码率由OpenH264编码，AV1是由AOM Encoder编码。720p时，用Dav1d解码AV1需要230.94fps，用OpenH264解码同样场景的序列需要644.57fps；1080p时，Dav1d是63.61，OpenH264是160.54，对表中数据进行分析得到AV1解码速度比H264慢了接近3倍，大致推测编码工具的复杂度相比H.264大概上升了3倍左右，另一方面反映的问题是性能较差的设备甚至无法支持AV1的解码。

编码的复杂性测试中使用AOM和OpenH264进行对比。720p时，AOM在普通PC上的编码速度是64.59fps，OpenH264是344.74fps，1080p时，AOM是19.75fps，OpenH264是82.19fps，数据显示AV1编码速度比H264慢了将近五倍。从这个测试结果来看， AOM Encoder各方面的优化已经相当出色，即使不做任何修改优化在某些设备上做Real time的应用也是完全OK的。由于测试在PC端进行，而测试结果中它的编码速度比H264慢了5倍，所以AOM Encoder 在移动端落地是会有很大困难的。所以我们在自研Pano Venus编码引擎时需要做的更好。

这是我们在做自研AV1编码器时给自己定的目标，严格来说， 其实这是三个问题：

如果要提升速度，除了做优化之外的方法可能是对算法、编码工具集做裁剪优化，而这些优化在提升速度的同时势必会造成RD性能的损失。那么是否可以做一个基于AV1的语义做编码速度和RD性能跟H.264相当的Codec？

如果对编码器的速度有要求，比如希望在某一点的速度损失和H264相比是某个比例，那么在此要求下，RD性能可以做到多好？

能否实现可伸缩RD性能，如0~70%或更高，在此限制条件下，编码器的速度能做多快？

如果大家熟悉优化理论的话，可以发现这个很像优化问题，在给了限制条件下能否求出最优解。但是无论是算法的选择还是编码工具的取舍都很难用简单的数学模型来衡量。

最终我们还是落地了比较满意的结果，在主流设备包括ios、android都可以运行AV1。

4. System Design

基于以上角度的分析，可以看到AV1落地是非常有挑战的。我们对于Venus的性能做了很多创新优化，但目前我们还无法将其优化到和H264一样，AV1的性能和H264相比，复杂度有不少的提升。目前市场上存在海量的设备，设备间的性能差异性很大，部分设备即使支持H264都是吃力的，更何况支持AV1，我们对设备做了分类。

第一行是（Lowest）最差的设备，不能运行Video，只能运行Audio。第二行是旧SDK（Old SDK without AV1），第一版SDK上线的时候并没有AV1，当时只有H264。第三档（LOW）和第二档类似，性能较弱，甚至不能支持AV1解码，所以只能运行H.264。第四档是旧SDK（Old SDK with AV1 Decoder），事实上在releaseAV1之前，我们已经release了AV1的decoder，所以早期版本中已经包含了一个decoder，这个版本可以和现在的SDK通信，新的SDK发送AV1到此版本，然后可以进行解码，这档设备性能还可以，能够支持AV1decoder。第四档（Medium）是中等复杂度，能支持H264的编解码及AV1的解码。第五档（High）性能比较好的设备能够支持AV1的收发，编解码都能够使用AV1。

对设备进行以上区分后， Pano Venus实现了在最大范围的场景下支持AV1，基于Venus的极致性能优化，也实现了在主流设备上支持AV1。

5. AV1 Scalability

[L|S] [Number] [T] [Number] [h] [KEY] [SHIFT]用来描述Scalability。

[L|S]，“L”、“S”任选其一，代表空间分级，Special Scalability，“L”指空间分级包含不同空间层的预测，增强空间层可以预测基本空间层，“S”指不同空间层之间没有任何预测。simulcast是这个结构中的子集，simulcast指不同空间层是完全独立的。

[Number]，指空间层的层数，比如L2、S2代表只有两个空间层。

[T]，代表时间分级。

[Number]，指时间层的层数。

[h]，常见的空间分级中两个相邻层的空间分辨率关系是1：2，比如基本层是180p，增强层是360p，而[h]代表关系从1：2变为1：1.5，基本层是180p，增强层是270p。

[KEY]，key frame相关。如果不同空间层中有层间预测，优点是在编码增强层时可以参考基本层的信息，对编码有所帮助，缺点在于解码时需要基本层存在，而[KEY]是尝试在两者之间取一个平衡，key是在空间分级的时候，对是否要采用层间预测做了权衡，[KEY]表示只在key frame做层间预测。对key frame的编码来说会带来一些编码增益，对下行来说非关键帧只需要接收增强层，而无需接收基本层， 仅在关键帧需要接受基本层。

[SHIFT]，和时间分级相关，通常出现在不同空间分级时。以L2T2为例，它有两个空间分级，两个时间分级，两个空间分级上的时间分级关系一一对应，比如基本层是[T0]，增强层也会是[T0]，基本层是[T1]，增强层也是[T1]，但[SHIFT]会试图改变这一情况，当使用[SHIFT]后，不同空间层的[T0]和[T1]会交错。虽然有些奇怪，但标准决定技术时背后一定有理由，这个技术一定在某些场景下是有增益的。我个人认为对于SFU的Server有增益，当一个源是L2T2时，25%用户订阅L0T0，25%用户订阅L0T1，25%用户订阅L1T0，剩下25%用户订阅L1T1，结构如果没有[SHIFT]，那么对所有用户来说，处于T0时必须转发所有数据，处于T1时会有50%用户无需转发数据，这样Server的load是不均衡的，有的时间很忙，有的时间点很空。当有了[SHIFT]之后，它对不同时间分级进行交错，最大限度balance了Server要转发的数据量。

从上文的介绍可以看出，simulcast只是scalable的一种最简单形式，未来scalable有很大机会，可以利用scalable更大的灵活性设计更能适应应用场景的技术。现在WebRTC也在实现这个技术。

以下是几个实例。

这是一个L1T2的例子，它有一个空间层，两个时间层，横坐标的0指T0，1指T1。

这是L2T2的例子，L2T2h的示例也完全相同，可以看到两个空间层都有向上的箭头，这表示上面的是空间增强层，会参考下面的基本层。

这是S2T2的例子，和L2T2相比没有箭头，代表两个空间层完全独立。

这是L2T2 Key的例子，箭头只存在key frame之间，当不是key frame时，不会使用层间预测技术。

这也是L2T2 Key的例子，和前一个例子差不多。

这是L2T2 Key Shift的例子，会更加复杂，在编码的时候特已引入时间分级的交错，使增强层的T0和基本层的T1处于同一条时间流。

以下列举了关于AV1 Scalability的基本概念。

最重要的是Chain，视频编码存在帧间预测，Chain指解码当前frame，这个frame会依赖前面的某一帧或某几个帧，而被依赖的帧又会依赖它之前的帧，整个依赖关系连成Chain。

DTI（Decode target indication），scalability灵活的可伸缩结构可以引申出多种不同的订阅如不同分辨率及不同帧率的订阅，所以DTI能够为单元场景增加更多分辨率或帧率的可伸缩性。

Switch indication指当切换DTI时，除了在关键帧进行切换，其它的某一帧上也可以完成切换，而这个帧在chain中，某个T0可能也是一个切换点。

Discardable indication，有些frame不在chain中，可被丢弃。

这是60fps，两层的序列。它可以延伸出多种DTI。

这是一种DTI，只需要HD的15fps。

这是另一种DTI，需要SD的30fps。

这是第三个DTI，需要SD的60fps。

这是第四个DTI，所有帧都要，就需要HD的60fps。

6. Future Work

Pano Venus已经正式上线，但是我们对它的期望不止于此，未来我们希望继续提升它的性能：

• 更灵活的编码复杂度伸缩方案， 覆盖更多设备

• 主观视觉编码， 进一步提升编码性能

• 支持桌面编码工具集， 支持桌面编码

• 并行编码框架， 充分利用多核处理器的性能， 提升编码效率

AV1技术虽然早已加入到WebRTC，但由于算法复杂度比H.264高很多倍，实时性一直是大家特别担心的问题。拍乐云对AV1在实时通信方面做了积极的商业化探索，相信Pano Venus的落地应用能够推进AV1在RTC领域的应用，进一步推进AV1生态发展。我们坚信技术的创新能为多媒体生态的发展创造更大的想象力。

这是参考文献， 本文的大多数内容都来自这三篇文献。

以上是本次分享的内容，谢谢大家！

---

讲师招募

LiveVideoStackCon 2022 音视频技术大会 上海站，正在面向社会公开招募讲师，无论你所处的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的。欢迎通过 [e-mail] 提交个人资料及议题描述，我们将会在24小时内给予反馈。

喜欢我们的内容就点个“在看”吧！