2021 技术展望｜开源十年，WebRTC 的现状与未来

WebRTC 在今年 1 月被 W3C 和 IETF 发布为正式标准。从开源至今，十年的时间，倾注了众多开发者的贡献。本文由 Google WebRTC 产品经理 Huib Kleinhout 基于在由声网举办的 RTE 大会上的分享汇总整理，并增加了其近期对于 WebRTC 前景的看法。

声网 Agora 开发者社区联合 InfoQ 共同策划，邀请了声网 Agora 开发者社区中的多位技术专家，从视频传输、计算机视觉、编解码标准发展、WebRTC、机器学习、音频技术等角度，共同撰写「2021 实时互动技术展望系列」，一窥技术新趋势。本系列内容由声网 Agora 开发者社区 与 InfoQ 联合策划，并由 InfoQ 审校，首发于 InfoQ。

2020 年，WebRTC 发生了很多变化。WebRTC 其实就是一个客户端库。大家都知道它是开源的。尽管 Google 大力地在支持 WebRTC，但社区的力量同样功不可没。

WebRTC 对于桌面平台、浏览器端实现音视频交互来讲十分重要。因为在你可以再浏览器上运行任何一种服务，并进行安全检查，无需安装任何应用。这是此前开发者使用该开源库的主要方式。

但 2020 年，浏览器的发展方向变了。首先讲讲 Microsoft，它将自研的浏览器引擎替换为基于 Chromium 的引擎，同时它们也成为了 WebRTC 的积极贡献者。Microsoft 贡献之一是 perfect negotiation，它使得两端以更稳妥的形式协商。而且，它们还改良了屏幕捕获，使其效率更高。

另一方面，还有 Safari。苹果的 Safari 还在继续改进他们 WebRTC API。激动人心的是，最新一版的 Safari Tech Preview 中已支持了 VP9，而且还支持硬件加速，大家可以在 Safari 的“开发者设置”中启用它。

火狐浏览器增加了重传以及 transport-cc，这有助于更好地估计可用带宽，从而改善媒体质量。

另一方面，Project Zero——Google 负责产品安全性的团队，通过寻找漏洞，帮助提高 WebRTC 的安全性。这意味着如果你的库不基于浏览器，及时更新 WebRTC 库、遵守说明就更加重要了。

另一件激动人心的事情就是，2020 年，云游戏已经上线了。它的实现有赖于 WebRTC。Stadia（Google 的云游戏平台）已于 2019 年底推出，但 2020 年初才正式在浏览器得以支持。其云游戏搭载 VP9，提供 4k、HDR 图像和环绕声体验。这些都会通过 WebRTC 进行传输。

数月前，NVIDIA 也发布了适用于 Chromebook 的 GeForce Now，同样使用了 WebRTC。最近，Microsoft 和亚马逊也宣布支持基于浏览器的云游戏开发。这确实促使 WebRTC 从数百毫秒延迟降低到了数十毫秒延迟，同时开启了全新的应用场景。但最重要的是， 2020 年，实时通讯（RTC）对于每个人来说都是必不可少的一部分。因此，许多网络服务的使用率暴涨，涨幅从十倍到几百倍不等。大家打语音电话的次数更多了，时间更久了，群组数量和成员人数也增加了， 线上交流越来越多。所以我们需要更丰富的互动方式。

从 Google 的角度来看， 在疫情爆发的头 2、3 个月内，我们的最大需求容量增长了 30 倍。所以即使是 Google，要确保后端和所有系统功能都可以应对这么大的增长，我们也付出了很多努力。

在变化面前， WebRTC 和实时通信使用量激增。大众的日常习惯也在变化。现在不只在公司能工作， 自己的卧室、厨房里都是工作场所了。由于“社交距离”，面对面交流变得不再现实，我们需要其它与他人社交的方法。我们只能通过视频，依据别人的表情猜测他的意图，此时高清的视频质量就显得更加重要了。

每个人协作的方式不同，可能是因为我们用的设备不一样。如果你在公司， 你用的可能是台式机，那你可能会用它在会议室里开会。而下班之后，你可能会带你的笔记本电脑回家。但现在人们都在用笔记本处理各种事宜，比如同时运行应用、视频会议和文字聊天。这种场景下，电脑的使用率非常高。我们看到学校里的孩子们也在用笔记本电脑，比如 Chromebook， 但他们电脑的性能相对差一点。社交、学习线上化之后，电脑的任务处理量突然增大， 所以开展该 WebRTC 项目的意义在于我们需要帮助扩展 WebRTC，确保其运行良好。

其次，我们需要为 Web 开发者和实时通讯开发者提供更大的灵活度，让他们可以在当下开发出新的互动体验。当疫情爆发时，它阻碍我们了在 Chrome 中开展的所有实验，于是我们所做的一件事情就是专注于服务的扩展、维护。但这远远不够，特别是在提高性能方面，我们需要做得更好。

大家可以猜一猜，如果你要在任何使用 WebRTC 的浏览器中开展实时服务， 最耗性能的部分会是什么呢？是视频编码？音频编码？网络适配？（因为你会考虑到可能会有丢包和网络变化）又或者是渲染？

当你想在屏幕显示摄像头采集的画面时，我们可以来看看浏览器中发生了什么。我们假设你有一个通过 USB 驱动程序输入的摄像头， 驱动运行，开始处理，摄像头可能还会进行人脸检测、亮度调整等操作。这要经过浏览器内的系统，Chrome 和其它浏览器都是多进程的。多进程有助于浏览器的稳定性和安全性，比如一个组件或一个页面崩溃，或存在安全漏洞，那么它就会与其他沙盒中的组件隔离。但这也意味着进程间有大量的通信。所以如果你有一帧视频数据从摄像头被采集，它可能是 MJPEG 格式。当它开始渲染你定义媒体流的页面时， 格式可能为 I420。当从渲染进程转到 GPU 进程（需要实际在屏幕上绘制）时，需要提供最高质量的数据，此时数据可能是 RGB 格式。当它再次进入操作系统，在屏幕上进行合成时， 可能需要一个 alpha 层， 格式又要变。这中间涉及到大量转换和复制步骤。由此可见， 无论内容来自摄像头还是某一终端，仅仅把它放到屏幕上的视频帧中就要花费大量的处理时间。所以这就是 WebRTC 服务中最复杂的部分——渲染。

这也是我们做了很多优化的地方。渲染变得更加高效了，可以确保我们不会在每次更新视频帧时都重新绘制。如果同时有多个视频，我们会把他们同步，再做其他操作。Chrome 团队优化了内存分配，确保每个视频帧都以最有效的方式得到分配。我们还改进了 Chrome OS 上的操作系统调度，以确保视频服务即使负载过重也能保证交互和响应。接下来的几个月里，我们将致力于从摄像头采集到视频帧渲染到屏幕这个过程的“零拷贝”。我们希望不会出现一次拷贝或转换，但所有信息都会以最高效的方式保存在图片内存里的。

同时，我们也致力于使刷新率适应视频帧率。所以在没有任何变化的情况下，我们不需要 60Hz 的屏幕刷新率，但要适应视频的帧速率，例如 25 秒一次。以下是我们觉得有用的建议：

1、避免耗时耗力的扩展操作，在 incongnito 模式下进行测试。

避免耗时耗力的扩展操作很难，它可以干扰你的服务进程，减缓你的服务速度。

2、避免安全程序干扰浏览器运行

杀毒软件若要做深度数据包检查或阻止数据包，会占用大量 CPU。

3、通过 Intel Power Gadgets 来测试

我们建议你用 Intel Power Gadgets 看看你的服务用了多少能耗。它会比只看 CPU 百分比直观的多。

4、花哨的视频效果会占用更多性能

如果你用一些花哨的动画， 比如会动的圆点来装饰你的视频帧，就会占用更多性能。尽管看起来不错，但它可能会导致视频帧卡顿一番才能渲染在屏幕上。

5、摄像头分辨率设置与传输分辨率一致

如果你使用摄像头采集，请确保打开摄像头时将其分辨率的设置，与你调用 getUserMedia 时的设置保持一致。如果你打开摄像头，设置了高清画质，格式为 VGA，那么势必需要转换很多字节的信息都会被扔掉。

6、要留意 WebAudio 的使用

WebAudio 可能比预期需要更多 CPU 来处理。

 关于视频编解码

视频编解码器可用于构建更高性能服务器。因为不仅 CPU 资源很重要， 若你构建网络相关的服务，视频编解码器就显得重要起来了。如果你要把业务拓展一百倍， Google 提供一款免费的编解码器，VP8、VP9、AV1，并且他在所有浏览器中都可用。

VP8 是目前为止浏览器内部使用最多的版本，所有浏览器都支持它。VP9 同样在市场中流通很多年了，也一直在改进。它具备 30%-50% 的节约率，以及如支持 HDR 和 4K 的高质量功能。同时，它广泛应用于谷歌内部，支持 Stadia 及其他内部服务。因为它有 VP8 中没有的功能，即能帮助你更好地适应高低带宽连接的转换。然后是 AV1。AV1 也即将在 WebRTC、一些开源实现和浏览器中使用。大多数浏览器已经可以使用它进行流式传输。希望明年能正式启用它。实际上，微软刚刚宣布他们的操作系统将支持硬件加速 AV1。性能的提升给予了开发者更大空间。

 WebRTC NV（Next Version）

发布 WebRTC 1.0 之后，我们就和社区一起研发下一个版本, 该版本叫“NV”。该版本意在支持当前 WebRTC API 不可能或很难实现的新用例，比如虚拟现实。对于虚拟现实特效，就像前面提到过的笔记本电脑和机器学习的例子一样， 为了能够使用 WebRTC API 运行，我们需要更好地掌握媒体处理的技能， 比如更好控制传输和拥塞，使用编解码器进行更多自定义操作等等。

在以上这些目标上，WebRTC NV 的思路是不定义全新 API。目前已经有两个 API 和 WebRTC，PeerConnetion 和 getUserMedia 了。我们不会重新定义它们，从头开始研发。相反，我们正在做的是：允许我们使用称为“HTML 流”的接口访问端对 peer connection 内部，以及允许访问浏览器中的编解码器的接口。再加上诸如 Web Assembly 和 workers threads 的新技术，你可以在浏览器，以及集成的端对端连接中使用 Javascript 进行实时处理。

如果看一下现在的 WebRTC 的内部，你会发现媒体流就像是从网络传入时一样被拆包（depacketized）。这里会有一些丢失或延迟的适配。因此，我们对此进行了重构。

另一方面， 摄像头输入或麦克风输入已经经过编解码器如 Opus 或 VP8，去除了回声。比特率已经根据网络情况进行了适配，然后将其打包为 RTP 数据包并通过网络发送。我们想做到在 WebRTC NV 中拦截该管道，所以要从媒体框架开始。因此，我们希望能够在媒体帧从网络到达显示器，以及从摄像机麦克风到网络回到媒体帧时对其进行监听。我们希望能够更好地管理这些流。目前我们提出两个流方案，也正是我致力研究的两个 API。

第一个是可插入媒体流（Insertable Media Stream）。当前的 Chrome 浏览器 86 中已提供此功能。Google 服务和其他外部服务已使用了此功能。你可以使用它来实现端到端加密，或者可以使用它向框架中添加自定义元数据（meta-data）。你要做的是在 PeerConnection 中定义此编码的可插入媒体流，并且你也可以创建流。之后，当你从摄像头获取视频帧时，它首先被编码，比如 VP8 格式，之后你可以访问它并进行流式处理。你还可以对其进行加密或标记其中一些元数据。

另一个是原始媒体流 API（Raw Media Stream）。这是标准委员会正在讨论的标准工作。目前已经有一些确切的建议了。从 Google 的角度来说，我们正在尝试这种实现。该 API 允许我们访问原始帧。它意味着，当原始帧从摄像头采集后，在还未进行视频编码前，你就可以访问这些数据了。然后你可以对其进行处理，比如实现 AR 效果。你还可以运行多个滤镜来删除背景，然后应用一些效果。比如我想把我现在的视频背景设成一个热带岛屿。这还可以应用到自定义的编解码器中，比如你此前使用的一些编解码器与现在的浏览器不兼容，那么你可以利用这个接口将数据直接传给编解码器来处理。原始媒体流 API 可以提供一种非常有效的方式来访问此原始媒体。

总结一下。虽然 WebRTC 作为 W3C 正式标准已经发布，但仍在继续改进。新的视频编解码器 AV1 可节省多达 50% 的带宽，正在 WebRTC 和网络浏览器中使用。开源代码的持续改进有望进一步减少延迟，提高视频流的质量。WebRTC NV 收集了创建补充 API 的倡议，以实现新的用例。这些 API 包括对现有 API 的扩展，以提供更多对现有功能的控制，例如可扩展视频编码，以及提供对 low-level 组件的访问的 API。后者通过集成高性能的定制 WebAssembly 组件，为网络开发者提供了更多的创新灵活性。随着新兴的 5G 网络和对更多交互式服务的需求，我们预计在未来一年内，持续增强在 WebRTC 的服务端建设。

点击了解更多实时互动信息～

​