深入了解 Google Meet 如何使用 AV1

本文译自webrtchacks，作者 Philipp Hancke。介绍 AV1视频编码在 Google Meet 中的应用情况，以下为全文内容。

上周早些时候，谷歌的一位朋友问我：

“Google Meet 在可扩展性模式（scalabilityMode）方面有什么奇怪的表现吗？”

显然，说到谷歌 Meet 的怪异行为，我是首当其冲的：）。好吧，我确实有十年观察 Meet 实现的历史，所以这是有道理的！

结果发现，这其实是微软 Edge 在 Chromium 的 webrtc-internals 页面中显示 scalabilityMode 统计属性时的怪异行为（为了说明上下文，我在微软工作，所以对 Edge 和 WebRTC 比较了解）。但此时为时已晚，因为我已经启动了 Chrome Canary 和 Edge 来查看 Google Meet。结果我发现了一个意料之中的惊喜–AV1，这足以写一篇博文了！

由于这是我一段时间以来发表的第一篇博文，我将通过对 VP9 SVC 的一些相关评论和 AV1 的屏幕共享优势来结束我对 Google Meet AV1 的调查。

webrtc-internals 中的 AV1 线索

这是我抓取的第一个 webrtc-internals dump（如果你想自己得出结论，可以下载原始 dump）：

在实际阅读之前，引起我注意的是（我将在下文中讨论）图表中的许多尖峰。造成这些尖峰的一个潜在原因是，由于某种原因，许多 getStats 计数器会在编码器重新初始化时重置，这就造成了锯齿状的尖峰。

自 2015 年 12 月我在 Tokbox 工作期间首次报告以来，造成这种情况的错误一直困扰着我，八年过去了，它仍未得到修复：

getStats：切换视频编解码器会重置
ssrc 报告上的packetSent/bytesSent 计数器
https://bugs.chromium.org/p/webrtc/issues/detail?id=5361

虽然在此期间很多事情都发生了变化，但这个问题却一直伴随着我们。这并非意料之外。修复问题需要时间和精力，而这些都是非常稀缺的资源。或者直截了当地说：除非问题是开发人员的问题，而开发人员有报酬来解决这个问题，否则就别指望会有多大进展。

现在，阅读顶部的文字，我们可以看到顶部的编码器实现显示为 libaom，这意味着该调用是使用 AV1 编码视频的。谷歌押注 AV1 并致力于在 WebRTC 中对其进行改进，这已不是什么秘密。但到目前为止，AV1 的大部分使用都是在 Google Duo 中（Meta 也一直在 Messenger 中部署），而这是 Google Meet 作为 “Chrome WebRTC 旗舰应用 “使用的。因此，这值得仔细研究！

深入了解 Meet 如何使用 AV1

从 webrtc-internals 读取原始 JSON 数据转储相当麻烦，但幸运的是，我已经为此制作了 webrtc-dump-importer 工具。我对该工具进行了一些更新，以便可视化 getStats 中的编码器/解码器实现和可扩展性模式属性。

总的来说，调用分为三个阶段：

第一个加入而没有其他人在场，
第二个是当编解码器切换回 VP9 时
之后的阶段。

如下图所示：

那么，我们在截图中看到的到底是什么呢？看来我很幸运，在谷歌进行 AV1 实验时进行了测试，因为我再也无法重现这种行为了。我是在 Chrome Canary 中进行测试的，它对编解码器无缝切换有更好的支持，这可能是它被视为实验性推广的一部分的原因。

最重要的数据系列是实际比特率、目标比特率以及帧宽和帧高。让我们详细了解一下不同阶段的情况：

AV1 是在 “通话前 “期间使用的，当时我独自等待打开第二个标签页。在此期间，AV1（具有时间可扩展性）向服务器发送 320×180 帧。扩展模式为 L1T2，即 AV1 具有时间扩展性。向服务器发送数据对预热传输和获得良好的带宽估计有一定意义，但我不喜欢在实际加入通话之前发送用户流对隐私的影响。十年前我就向 Hangouts 团队的人提出过这个问题，但没有结果。最有可能的是，这样做造成的入站流量也不会产生任何实际的金钱成本。

你需要发送一些 RTP 数据包来估算带宽。使用什么编解码器其实并不重要。在预呼叫期间使用 AV1 可以满足向服务器发送 RTP 数据的要求，即使是最初的低分辨率 AV1 数据也能获得 2.5mbps 的适当带宽估算：

对于 Google Meet 来说，这个次要目的可能更有意义。它可以将任何与 AV1 相关的代码路径应用到生产环境中。此外，它还能让 Google 了解 CPU 使用情况和 AV1 支持程度。请记住，对于像 Google Meet 这样的服务，在 “生产 “环境中部署的标准是非常高的。这样，他们就可以在不实际播放任何视频的情况下试用 AV1。

一旦第二个用户加入（即使该用户也支持 AV1 编解码器），编解码器就会更改为具有扩展模式 L1T1 的 libvpx，编解码器也会更改为 VP9。

由于上文提到的错误，比特率变为负值，没有显示出来。令人惊讶的是，目标比特率在分辨率之后一秒就发生了变化，这可能是一个错误。

在预调用阶段使用 AV1 是一种很好的测试策略，也是我将新编解码器推向生产的方式。AV1 于 2020 年 4 月登陆 libWebRTC。从那时起，它经历了不少调整，这在 2022 年的 rtc@scale 会议上得到了很好的总结。

从编解码器的实现到投入生产之间如此长的时间并不罕见，我们曾看到 VP9 SVC 也有类似的时间表，它于 2014 年底或 2015 年初在 Chrome 浏览器中发布，而我们在 2017 年仍将 SVC 作为 “没有标志的尚未实现 “的东西进行讨论。谷歌通过用 VP8 同步广播 SDP munging 的代码路径启用了 VP9 K-SVC，在这一点上愚弄了所有人，而这也正是 Google Meet 在生产中使用它的方式。

VP9 k-SVC

WebRTC 中的视频编解码器非常复杂。进一步的测试表明，Google Meet 仍在生产中使用 VP9 可扩展视频编码（SVC，即 L3T3_KEY 和类似模式），考虑到硬件加速 VP9 同步广播的工作量，这一点令人惊讶。作为查看 AV1 变化的副产品，dump-importer 现在可以更清楚地显示 Google Meet 是如何根据通话参与者的数量来开启或关闭 SVC 的：

在另一个 dump 中，我们看到在预热期间使用了 L1T1（即无 SVC）和 VP9，在第二个与会者加入后使用了高分辨率的 VP9 L1T1，然后切换到 L3T3_KEY。在此优化行为的原因是，VP9 SVC 目前强制回退到软件解码，因为硬件解码器无法解码。虽然修复这一问题是可能的，但修复措施还没有实现或得到验证。

AV1 屏幕内容编码更好

然而，网络摄像头视频并不是我期待 AV1 首先出现在 Google Meet 中的地方。虽然 Meet 使用 VP9 和 SVC 来处理网络摄像头内容，但屏幕共享（或者说标签共享，更有利于保护隐私）仍在单独的 RTCPeerConnection 上使用 VP8 同步广播。libWebRTC 已经为来自屏幕共享（或内容提示设置为 “细节”）的 MediaStreamTracks 启用这种特殊模式有一段时间了。

今年早些时候，我曾尝试将该功能移植到 WebCodecs 中，以便让 Chrome 浏览器支持的不同视频编码机制保持一致。结果实现的方式与我预想的不同。它现在由 contentHint 属性控制。下面显示的结果令人印象深刻。通过 WebCodecs，我们可以轻松实现可视化。注：在 WebRTC 中进行比较要困难得多，因为我们无法轻松访问帧大小，而编码器比特率是由带宽估算驱动的。

上面的截图是使用 Chrome Canary 和一个 jsfiddle 并行运行两个 AV1 编码器，内容相同–一个共享标签页的幻灯片正在缓慢翻页。结果是帧大小减少了 25%以上，从而降低了比特率。这一点在多方会议中更为重要，因为 SFU 必须将每次更改当前幻灯片时出现的大帧（如尖峰帧）分配给许多与会者。减少帧大小在这方面大有帮助。