Web 中文兴趣组会议

大家好，我分享的题目是Web下一代RTC技术实践。首先自我介绍一下，我叫高纯，现在主要从事Web引擎和音视频技术的研究工作。

近年来随着AI、5G等技术的快速发展，催生了很多新的应用场景，比如云游戏、元宇宙等，这些应用场景会涉及很多前沿、新颖的技术。这些技术在native平台基于原生技术上已经得到了广泛应用和普及。

而在Web平台上，受限于Web平台的能力和标准，很多事情比较受限，或者即使能够实现，实际体验也比较差。好在最近几年WebRTC NV相关的标准逐步在浏览器上落地，使得这样的局面大为改观。

谈到RTC，在Web上就不得不提到WebRTC，WebRTC有两层含义，一是项目，它是Google收购了GIPS之后演化而来的开源项目。另一方面，它又是一个标准，是W3C定义的技术规范。

在标准层面，它涉及的Spec主要包括《WebRTC 1.0: Real-Time Communication Between Browsers》，主要定义PeerConnection等和传输相关的API，另一个Spec是《Media Capture and Streams》主要定义媒体的采集以及媒体流的表达形式。在项目层面，Web RTC提供的功能如图所示[多媒体演示]，这是标准的RTC应用典型流程。从媒体的采集、前处理、编解码、拆装包，以及网络传输、加密解密、能力协商等，WebRTC提供了完整的能力。

Web RTC项目主要提供C++的接口，当然不同的平台上也有不同的API，在移动端有Java、OC的API。在Web平台，以Chrome为例，则是基于Blink通过V8将C++ API转化成了W3C定义的JS API。

由于Web平台架构比较特殊，WebRTC的部分能力是被浏览器自身能力覆盖的，由于时间关系就不展开介绍。

我们知道目前为止WebRTC流行了大概七八年，然而在WebRTC诞生前，行业内有很多厂商有自己的一套架构以及协议。在Web平台，WebRTC作为长期以来唯一的一个RTC应用解决方案，厂商就必须要解决自有架构和Web互通的问题。而通常的做法就是在服务端通过边缘节点做协议转化或者是媒体转发。

RTC技术发展到今天，WebRTC面对一些新的应用场景已经显得有一些力不从心了。主要问题是哪些呢？首先，刚才提到产商自有协议、自有的编解码器，无法与WebRTC协同工作。另外，对于一些新的应用场景比如云游戏、元宇宙等，会涉及到一个能力，就是应用数据和媒体内容的数据同步。比如在上在线钢琴课时，弹下去的音需要和弹下哪个键的值同步；玩游戏是，VR坐标要和游戏画面强同步等。由于Web平台的WebRTC尚未开放SEI等类似的接口，这就使得这项需求实现起来比较困难。这些问题在一定程度上能通过一些Workaround解决，但目前体验还不好。

从WebRTC自身能力来讲，它提供了够用但却不是最好的能力，比如降噪、回声消除、自动增音控制等等，很多企业有非常好的基于AI的算法，这些算法要和WebRTC整合相对比较麻烦，开发体验也不是很好。

还有一种场景，就是发送端通过AI算法对背景做一些消除，只保留人像。将透明的背景信息设置成α数据，这样接收端可以接收多路不同的人像，把不同的人放在不同的舞台上，实现虚拟的舞台效果。这样的场景由于WebRTC不支持Alpha数据传输，在Web上实现也比较困难，所以大多数实现会走服务端MCU合成的模式。此外还有其他的问题不一一列举，都是Web RTC目前无法满足的。

既然有问题，就会有解决方案。于是就有了Web RTC NV的概念。WebRTC NV并不是具体的标准，W3C通过WebRTC NV Use Cases文档定义了一系列的应用场景。为满足这些场景，列出了一系列的功能需求。要实现这些功能需求，又对应了一系列的需要实现的API，这其中就包括Mediacaputre Insertale Streams，WebCodecs，以及最近比较火的WebTransport等。

从Chrome M94以来，这些功能已经逐步落地，开发者可以直接使用了。但是，任何事物的发展总是曲折前进的，目前这些API还有很多问题需要解决。

首先看看它们带来的好处是什么。[多媒体演示]这是我们虚拟背景的demo，它的功能是对实时背景进行虚化、替换。在使用Mediacaputre Insertale Streams方法之前，运算部分基本是放在主线程处理，从图中可以看到主线程CPU的开销比较高，对页面响应都有比较大的影响。使用了新的API以后，把计算密集型的工作留到worker，对JS的线程的影响就大大降低了，这是很直观的提升。

要对媒体内容进行处理，通常要将其传输到worker里处理。这首先要解决的问题就是怎么把媒体数据放到worker里去，长时间以来常规的方法是直接通过postMessage将每帧媒体数据发到worker上。

我们经过测算，发现使用postMessage()方法传输不同大小的ArrayBuffer的时间是线性增长的，而对于1080p的视频画面，基本上一帧的传递开销需要几十毫秒，这对实时RTC应用来讲基本是不可接受的。

我们找到了一篇来自Google的Surma写的文章，他对postMessage()时间开销进行了详细地分析，在不同的平台上进行传输时得出的结论基本和我们的测算结果一致。

有了Mediacaputre Insertale Streams，就可以比较容易地解决这个问题。Mediacaputre Insertale Streams的输入输出是ReadableStream和WriteableStream，它可以在主线程和worker直接建立一个处理通道，直接传递ReadableStream和WriteableStream对象。这种实现方式带来的好处就是浏览器内部实现了主线程和worker线程之间的数据共享，而不是通过worker的消息机制进行传输，性能能够得到很大提升。

它带来的问题是什么？这是我们要主要介绍的。在使用Mediacaputre Insertale Streams的MediaStreamTrackGenerator创建新Track之后，我们遇到了和H264硬编的兼容性问题。

这个问题不仅仅在MediaStreamTrackGenerator上存在，通过HTMLMediaElement.captureStream()产生的track或远端发过来的Track在向外发送出去的时候硬编都会失败。通常浏览器在工作时，硬编失败会fallback到软件，但这个case在很多情况下并没有发生fallback，就会导致应用的不可用了。

关于WebCodecs，问题主要是VideoFrame对48 bit image的兼容性问题，如果将VideoFrame的数据源设置成48bit图像，它会创建失败，这个问题可以理解为是一个Web引擎的bug。

还有一个和颜色空间相关的问题，这个问题也让人比较困惑。我们通过buffer给Video Frame写入蓝色RGBA数据时，如果把VideoFrame写到Mediacaputre Insertale Streams里去然后通过Video元素渲染，它渲染的结果和我们的预期并不一致，我们定义是蓝色的色块，而渲染出来是红色的色块。

这个问题是怎么发现的呢？我们用Mediacaputre Insertale Streams结合WebGL来做音视频处理，并将应用处理算法之后的结果送回通道里去。在实际应用过程中，我们会发现本地渲染时上图中本应该是黄色的星星，实际渲染结果R和B通道发生了交换。但是，把如果把这个媒体流发到对端，在远端渲染又是正常的。当然这个问题也有workaround能够解决，我们可以使用WebGL把RGBA的R和B通道交换，然后在输出结果中把VideoFrame的format定义成BGRA，这样就可以解决这个问题，但对于开发者来讲试错的成本就比较高了。

关于WebTransport，由于时间关系，不介绍它的具体特性了。HTTP/3对Web带来的体验提升是重大的，但我想说WebTransport对于RTC应用带来的意义没有想象那么大。我们知道Web Transport提供了可靠传输和不可靠传输，如果使用可靠传输意味着和TCP相似的重传逻辑，以及拥塞控制的算法，这对实时性要求比较高的RTC应用来讲并不合适。如果纯粹基于WebTransport不可靠传输实现RTC应用，那我们又有另一方面的需求，虽然传输是不可靠的，但我们还是希望尽量做到高质量的传输，在丢包的时候有相应的机制找保证媒体数据的传输质量。这就需要QoS算法来补足不可靠传输通道这方面的能力。

我们知道WebRTC功能已经很丰富，包括QoS、带宽估计在内的技术都很成熟。但是，由于Web平台的WebRTC实现在浏览器内，这些能力不能单独使用。而WebRTC NV新的API也有自己的不足。看到这些问题之后，我们就有了一个想法，就是能不能把WebRTC port到WebAssembly上。再结合NV新的API来解决上述问题。比如Web RTC内部的VCM、ADM音视频采集模块可以bridge到Media Capture，传输通道可以bridge到WebTransport。

在编码器方面，虽然WebAssembly性能很强大，但编解码器的实现实际会使用平台相关的汇编和SIMD指令来进行优化，而Wasm编译出来的版本只能基本的C语言版本的实现，性能就比较有限了。所以，我们希望把编解码部分bridge到WebCodecs上，这样就可以充分利用WebCodecs的硬件加速编解码特性。

这样整体的实现就能充分将WebRTC NV API的灵活性以及WebRTC算法的成熟性进行融合。

这个项目目前在声网还处于早期的阶段，目前实现的状态是完成了WebRTC基本的WebAssembly的移植，所有的线程、网络、媒体、设备采集都能正常工作。但是接下来的工作重点主要是完成WebRTC内部各模块到WebRTC NV API的bridge。

最后，总结一下。首先Web RTC还是Web平台构建一个高效RTC应用非常好的工具。但是，它并没有办法满足新的应用场景的独特需求，Web RTC NV引入了很多强大的功能API，可以覆盖更多的应用场景。声网这两年基于WebRTC NV API交付了很多有意思的功能，比如空间降噪、AI降噪、虚拟背景等。其中一部分功能都已经落地到声网的Agora Video Call产品上，大家有兴趣可以试用体验。

WebRTC-Wasm项目我们希望融合WebRTC的算法和Web RTC NV/API为Web平台的RTC应用开发带来更好的体验。谢谢大家！

提问：您好！我想问一个问题，针对短视频、直播方面，比如对时延要求比较高，时延方面有什么优化的机制吗？

高纯：时延方面吗？其实，主要改进时延的重点是在网络传输层面，就是后端的大网上。这里面会涉及很多网络的复杂算法，比如声网大后端有自己的实时传输协议，叫AOT。它在可靠传输和不可靠传输之外，还有一种半可靠模式，它是基于媒体的网络传输协议，可以确保媒体传输的时候尽量减少时延。