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

[image]​

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 服务中最复杂的部分——渲染。

[image]​

这也是我们做了很多优化的地方。渲染变得更加高效了,可以确保我们不会在每次更新视频帧时都重新绘制。如果同时有多个视频,我们会把他们同步,再做其他操作。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,并且他在所有浏览器中都可用。

[image]​

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。

[image]​

第一个是可插入媒体流(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 的服务端建设。

本系列相关阅读

2021 技术展望 | 走向未来的实时生成技术

2021 技术展望 | 弱网下的极限实时视频通信

2021 技术展望 | 5G 将会倒逼传输协议、算法做出更多改进

2021 技术展望 |AV1 在 RTC 应用实践中的现状与展望

2021 技术展望 | 实时互动场景下,音频的技术变迁与机遇

[image]

推荐阅读
作者信息
AgoraMarketingTeam
TA 暂未填写个人简介
文章
37
相关专栏
开源技术
74 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和 Agora 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。