webrtc和MilliCast的AV1实时编码

自2020年4月起，独立的webrtc和MilliCast平台中的AV1实时编码已经可用，正如我们在之前的文章中所述。然而，对于那些想在web应用程序中单独使用它的人来说，您必须重新编译Chrome。虽然我们为社区提供了预编译的二进制文件，也有少数勇敢的人早早地进行了测试，但这是单层实现，不支持SVC。

随着编解码器的使用从闭路和专用线路发展到越来越多地在公共互联网上使用，编解码器自身也在不断发展，并采用一些功能来改善公共互联网上的媒体体验。作为H264（附录G）的最新附录，SVC已经发展成为任何现代编解码器必须具备的功能。在默认情况下，AV1是第一个支持SVC的编解码器。对于那些对关于SVC是如何发挥作用的更多细节感兴趣的人，Alex E.博士在2016年写了一篇很好的解释性博文。写的是关于VP9，大多数点对AV1有效的内容。

在过去的一整年中，AOMEDIA的实时组（代码组的一部分）都在努力完成RTP有效负载规范，该规范允许RTP端点利用所有编解码器SVC功能，但也可用于中间SFU变得更好、更强、更快。Cosmo软件率先实现了所有测试和参考SFU。现在，AV1RTP的有效载荷规格现在几乎可以被认为是最终的版本，经过了高达95%+的测试。

现在是一个很好的时机来回顾为什么AV1对于实时媒体来说比仅仅提高效率更重要。与此同时，我们还将提供有关性能预期的详细信息。

1创新不会在隔绝的真空中发生

在我们这个快节奏的世界中，太容易把注意力放在小事上，而忽视大局。但是，没有创新会在像是隔绝的真空中发生的，而对趋势进行分析并对其轨迹进行分析，则更加令人着迷。

Alex Eleftheriadis博士（又名Alex博士）在他最近的一篇文章中非常完美地记录了整个通信系统的发展。它写的很好，被一个不仅从内部经历了进化，而且还不得不教给大学生的人记录得非常好，他创建了这个领域中技术上最有创造力的公司之一：Vidyo。我强烈建议您可以读一读。

在不到两周的时间里，下列三项主要技术已成为标准或可在Chrome中使用：

1月20日（星期三），所有IETF RTCWEB草案最终都成为标准（或参考性文献）并获得了一个RFC编号。这代表了十多年的工作，由全世界一百多位最聪明的人都在研究用作WebRTC基础的协议。辛勤工作中产生的数十个新标准已经公开，可以通过Web平台获得！

1月26日，W3C宣布Webrtc 1.0作为一个标准使用，它巩固了该标准，使人们可以安全地加入并可以开始实施它。1月21日，Google终于在Chrome中启用了AV1 SVC实时编码，几个小时或几天后，该功能便会在Canary版本中可以使用了。

1月21日，Google终于在Chrome中启用了AV1 SVC实时编码，几小时或几天后，该功能就在Canary版本中可以使用了。

这不是偶然。实时媒体需要整合多个元素才能正常工作，所有这些元素都是并行工作和发展的：

具有SVC（可伸缩视频编码）的编解码器

媒体引擎（编解码器，媒体和网络传输的耦合）

SFUs（选择性转发单元），代替MCU（多点会议单元）

这是整体的典例，说明整体大于部分的总和。并行使用这些技术还会具有惊人的优势：

更好的网络弹性

更快的适应性

后端无媒体处理

支持下一代新功能，例如端到端加密。

2RTC创新轨迹

微软首席架构师伯纳德·阿波巴（Bernard Aboba）曾经写过有关AV1的文章（我们添加的链接）：

“史蒂夫·乔布斯曾经说过：“我一直被更具革命性的变化所吸引。我不知道为什么。因为它们更难。”

AV1旨在与下一波WebRTC视频创新集成：端到端加密，SVC和独立于编解码器的转发。因此，这与视频编解码器无关，而与下一代架构有关。

1. 随着WebRTC现在通过可插入流（和SFrame）合并了E2E加密，并且NSA现在推荐E2E安全性，由于有效负载可能是不透明的，因此会议系统需要RTP标头扩展来转发数据包。因此，如果浏览器和编解码器不支持可插入流或与下一代编解码器集成的转发头扩展名，则将无法满足NSA的要求，并且会议供应商将无法提供完整的功能。

2. SVC支持对于会议很重要。AV1内置了SVC；在HEVC中，它是一个扩展。Dependency Descriptor（在AV1 RTP有效负载规范中定义）优于用于空间可伸缩性模式的Framemarking RTP标头扩展。如果浏览器（和下一代编解码器）不支持带有转发头扩展名的SVC，那么它就没有竞争力。

3. AV1包含屏幕编码工具作为基本功能，而不是像HEVC中的扩展。这是会议的主要竞争优势。”

A. 屏幕共享

对于文本内容以及超高动态内容，在对屏幕内容进行编码时，AV1都非常高效。实际上，AV1实时的性能非常优越，以至于像Cisco在Webex中所做的那样，AV1实时可能只部署在单个使用案例中。

在共享屏幕或应用程序时，如果选择了“优化运动和视频”，并且您所在的机器至少有四个内核，则支持传输AV1。任何至少有两个内核的机器都支持接收AV1。只要会议的所有参与者都支持AV1，AV1就会自动用于共享此类屏幕内容，否则它将自动恢复为H.264。

有趣的是，这里分别提到了4和2个内核的约束条件。思科在2019年6月的大苹果大会上进行现场演示时也发表了同样的观点。

我们将在下一个部分中继续讨论性能的问题，但是为了提供相关的背景信息，MacBook Air自2008年以来一直使用具有2个内核的Intel core-2芯片，并且自2011年以来在MacBook Pro中具有4个或更多内核的Intel i7或更高版本。就笔记本电脑和台式机而言，预计拥有4个内核并不是一个大问题。

B. 端到端加密

E2EE是下一件值得关注的问题。也许是因为这是webrtc最初许下的承诺之一。又或许是因为它成为了一个过度使用的营销术语，而Zoom已经变得遍体鳞伤。也许是因为大多数人仍然声称拥有它，实际上却没有。

关于E2EE，对这个问题最好的回应之一是Emil Ivov的这篇演讲。

虽然许多人认为E2EE加密只是一种视频会议或聊天应用程序功能，但它在整个媒体行业中都以缩写“DRM”（数字版权管理）的形式使用。然而，传统的DRM在浏览器和媒体播放器中的实现并不是真正的端到端的，只涵盖了交付这一模块。当人们上传他们的内容到一个平台时仍然需要信任这个平台（以及任何可以合法访问或不合法访问该平台的人）与他们的原始内容。

真正的E2EE要求在对媒体进行编码时在源处对媒体进行加密，并且仅在播放时对其进行解密。它允许内容提供商不信任该平台。

WebRTC可通过插入流API方案来得到了广泛的应用，因为它可以用于很多方面。它是使您能够访问媒体的API，也是启用E2EE的必要步骤。但是，它本身没有加密功能或加密密钥管理功能。

最接近WebRTC兼容的E2EE媒体加密的是提议的IETF SFrame标准。它仍然需要一个外部系统来提供安全的外部密钥管理。至此，苹果公司报告称，在1月18日召开的每月WebRTC临时会议上，他们在Safari中添加了SFrame的初版安全实现。这得到了Firefox的良好反馈，Firefox的团队通常非常重视安全功能和保护互联网用户。网络平台方面也在取得进展。

这里微妙之处在于SFrame的设计是具有前瞻性的。在其前身PERC迫使用户进入旧版RTP媒体传输并且仅限于视频会议用例的情况下，SFrame设计为：

不区分用例（即可用于流媒体）

与协议无关（今天RTP，明天QUIC）

使用更少的带宽开销（比SRTP或PERC）

SVC编解码器兼容。

C. 具有SFUs和现代媒体基础设施的SVC

大多数人关注新编解码器的编码效率：

使用新的编解码器导致带宽使用减少

使用相同的输入，可以在查看器端产生相同的质量。

在下一代媒体体系结构中使用的SVC提供的功能不仅仅是这些。

无需使用ABR

SVC提供了从单个编码器在单个比特流中生成多层次分辨率的能力。换言之，SVC使得服务器端转码和ABR过时了（尽管仍然有其他原因需要为VOD转码服务器端）。

由于低分辨率内容只编码一次，因此编码一层比特流也比目前同播或ABR那样的3、5或7层独立比特流更有效。在以适应为准则的现代媒体传播系统中，它对底线产生了巨大的影响。

更好的网络弹性

对于那些不熟悉媒体传输和部分可靠性概念的人，我们建议阅读我们之前关于该主题的文章。

处理网络故障的方法主要有三种：重传、冗余和前向纠错。每一种都是一种相对折中的方案：

1. 重新传输假设您有时间再次发送数据包，并假设您为每个正在进行的流，保留一个数据包缓存。好处是它实际上很容易实现。

2. 冗余假定您有能力使用更多的带宽。如果您的数据包丢失是由于拥塞（数量问题）而不是质量问题引起的，那将无济于事。

3. FEC可以减少带宽开销，而不必等待重传。但是，这将增加发送方和接收方的复杂性。

在分层编解码器中，只有基本层对呼叫至关重要，丢失其他层只会降低接收端单个帧的分辨率。

因此，您不必保护整个流，而只需保护底层。这使得FEC变得更加有趣，因为复杂性会自动降低。如果在所有数据包上使用RED或FEC，则相对带宽开销也只是它的一小部分。

而且，基本层数据包的时间频率是流时间频率的一小部分，这意味着您有更多的时间来处理丢失的数据包。这也使得RTX更具吸引力。

无论您采用哪种网络弹性方法，SVC都只会使其更加高效。

更快（比光）适应

同样，SFU的作用相对简单：要获取传入的数据包，需要检查哪个数据包应该被代理到给定的目的地，然后推送到该目的地。要决定哪个包应该代理到特定的目的地，首先需要决定代理哪个分辨率/层，然后执行更改。

这个决定通常是根据一些启示方法做出的，这些启示方法部分地基于观看者带宽容量、屏幕大小和执行分辨率/层变化的设备硬件所引起的。

如果使用联播，可以根据流的源ID（SSRC）来确定流的分辨率。提供streamID《=》分辨率映射后，SFU决定停止发送给定的流，并以不同的分辨率发送另一个具有相同内容的流。为了使查看器解码器能够在没有伪影的情况下跟踪更改，它需要在切换之前等待一整帧。

SVC编解码器有一种称为可伸缩性结构的特殊结构，它定义了不同层之间的依赖关系。这是一个编解码器和位流功能。在过去的几年中，一项非常明智的进步是在媒体传输级别复制并扩展了这种可伸缩性结构。

最终的目标是在解码器上即时做出可破译性决策！

由于这些额外的结构，SFU可以在给定目标解码分辨率的情况下，决定接收任何数据包时是否应该丢弃该数据包。这是一个非常强大的功能：

通过不发送非关键数据包的NACK，减少与发送方的带宽使用反馈

通过不发送解码器最终会丢弃的多余数据包来减少前向媒体带宽的使用

将分辨率从一个数据包更改为下一个数据包（在单位毫秒范围内），而不是等待全帧

老实说，这是迄今为止SVC编解码器带来的最有趣的功能。Emil Ivov（again）和他的团队的这个演示演示了一种非常直观的方式来理解它在用户体验方面提供的优势。

这是一项技术性很强的新功能，在此，我不再赘述技术细节。你可以参考我们的媒体服务器技术负责人Sergio的帖子了解技术细节。

3采纳、性能和期望

A. 采纳方面

AV1作为编解码器并不是在技术上非常新鲜的一件事了。它于2018年4月宣布。此解码器自那时以来就一直可在台式机和笔记本电脑上使用。

Netflix和YouTube都采用了这一技术，甚至在2020年初在其移动客户端上启用了AV1播放。

LG和三星在2020年宣布在其智能电视中支持解码器，而索尼刚刚宣布在2021种电视型号中支持AV1。

从2021年3月开始，所有Android TV设备默认都必须支持AV1。

支持AV1 10位HDR的硬件解码器现已批量生产并提供dongle大小！

许多GPU供应商和OS供应商一直在添加AV1的解码支持。

直到如今，现有的新功能包括了可以快速、良好地在Chrome中运行的ENCODER软件，以及支持编解码器所有可扩展性模式的RTP有效负载。

B. AV1编解码器在实时模式下的性能

在2020年中期，我们进行了一项针对实时编解码器的研究，该研究表明，即使在非常有限的硬件上，AV1 RT的性能和速度也足够好，并且在相同条件下肯定比其前代产品好。它经过同行评审并发布在IEEE会议上，并且在ArXiv上提供了扩展版本。本着可重现科学和开放数据的精神，下面的链接中提供了用于测试每个编码器的命令行，供大家自己进行测试。

据我们所知，这是在其实时配置和实时设置（定速输入）中使用的编解码器的唯一基准测试和比较。Phoronix有一个测试套件，似乎可以以6和8的速度测试libaom实时模式，但是我们还没有确切检查使用了哪些命令行（例如，有多少个内核，多线程等），以及输入是否调速或加速从文件读取。如果从文件中读取，结果会比在真实环境中人为地要快。

C. AV1实时编解码在Chrome浏览器中的性能

根据google的说法，chrome的性能目标是720p，每秒30帧对于普通台式机/笔记本电脑，速度为2 Mbps。libwebrtc中编码器的速度配置是根据输入分辨率和内核数来选择的。它使用与Cisco相同的阈值：2个内核为最小可接受值，4个内核为最大值。实际上，仅使用4个内核，我们就能获得比720p更高的分辨率。

对于google来说，选择覆盖Real Time Media网络用例的绝大多数（在数量上）的目标是有意义的。它还符合他们的目标，为下一个10亿互联网用户提供更好的体验，在这些用户无法访问超过2Mbps的带宽的情况下。

对于像MilliCast这样的实时流媒体平台，在分辨率，帧频，位深等方面没有任何限制，本机应用会替换Chrome以提供不同的操作点，例如广播质量（颜色分级）要求。

正如预期的那样，SVC模式将占用更多资源（现下主要取决于所选的可伸缩性模式，目前占用的资源介于30％到40％之间），还有一些性能缺陷需要通过SVC支持解决。Google正在开发的WebRTC中的libaom多线程代码中存在一个已知的回归。我们提供了一些补丁，对于m90的一切都应该是准时的

所以现在，每个人的真正问题应该是：什么时候将会实现呢？

它应该已经在Chrome Canary中了，您可以开始使用它并报告错误（如果有）。不幸的是，提交错过了m89删减，所以除非他们将其移植到m89（非常罕见，但正在讨论中），否则它应该只能在m90稳定版中使用。

Webrtc系统：现在更难，更好，更快，更强大
编辑：lyn