Web 中文兴趣组会议

大家好！我是来自英特尔的诸剑俊。我们组主要是做和Web平台有关的设计、开发和优化的一些工作。今天和大家分享的主题是通过WebTransport、WebCodecs 和 WebAssembly实现在实时音视频系统。

因为刚才来自声网的专家已经对WebRTC有了比较具体的介绍，所以我这里可少花一点时间。现在WebRTC已经比较成熟，在所有的主流浏览器上都可以很好的支持。我记得第一次来W3C中文兴趣组，应该是2018年组，介绍 WebRTC 的时候，那时候WebRTC1.0还是即将发布的状态，现在WebRTC 1.0协议已经可以很好的被支持了。比较简单的流程就是媒体的获取，送到PeerConnection，包括编解码、RTP处理，WebRTC几乎可以做掉所有的工作，最终呈现在HTML的video 标签上。

因为WebRTC可以提供高效、低延时的通信和实时通信，但是在WebRTC 1.0上难以做自定义的事情，比如音频、视频的处理比较难做，所以WebRTC 1.0标准发布之后，下一代加上了一些自定义的处理，加了两组API，也就是捕捉了音视频之后，可以把数据取出来做一些自己的操作，发送数据的时候也可以做一些端到端的加密等事情。

其实，这已经过了WebRTC 1.0，进入WebRTC NV的状态。

我们做了很多年的开源项目Open WebRTC Toolkit。包括P2P的模式，最开始是开源项目，我们是基于WebRTC做的。

后续考虑到很多用户希望支持WebRTC之外的常规协议，所以我们也作一些支持。除此之外，在服务器上，也支持一些会议管理、转码以及视频分析的功能。整体来说，整个方案是基于WebRTC进行开发的。

既然WebRTC已经可以在浏览器上支持音视频的实时通信了，还需要做什么样的事情呢？也就是说还有什么其他的需求？首先，WebRTC最初的设计是基于P2P设计。因此需要解决连通性。两个客户端可能都是在内网或者有一个客户端是手机网络，这样的环境非常复杂，需要一个ICE的模块。如果是一种会议模式，比如说是会议服务器，有客户端网上连着，或者是一种广播、直播模式，那么它更接近客户端/服务器C/S的模式。

像这样的模式ICE网络发现就不太需要了，它需要的是原生支持C/S模式的网络结构，像HTTP一样，客户端往上连，连上之后可以进行传流，这是比较期待的网络模型。另外有很多应用程序开发商可能已经有自己的自定义算法和协议，但是一旦用了WebRTC之后，这种协议就很难被用上去了，因为WebRTC已经在下层把整套逻辑处理完了，这是我们希望做到增强的地方。

一个自定义的方案可能会像这样获取媒体数据以后，经过处理，编码，打包以后发送给服务端，另一端会把数据下载之后，做解包，然后做解码，这样会用很多Web API，除了WebRTC之外，还有WebAssembly、WebCodecs，还有WebTransport等标准，其实要做一套真正可自定义的Web系统，需要很多的Web API，不仅仅是WebRTC就可以做好的。

说一下Web Transport，因为刚才说了WebRTC主要是基于P2P，我们就考虑能不能有一个新的标准实现客户端服务器架构的一种网络模型。WebTransport比较好的适应了这种模型，首先它是基于QUIC和HTTH/3，同时它支持有序可靠的传输，也支持无序和不可靠的传输，最近它也支持不同的拥塞控制，以及多路复用，但是目前只有Chrome支持。不过最近WebTransport受到了不少关注，应该会被广大浏览器支持起来。还有WebCodec等其他Web技术，如果需要用WebCodecs做音视频系统之外，还需要和其他技术配合，也会用到Media Capture。

WebCodecs支持普通的编解码，也支持低延迟的编解码，只要浏览器支持的，它能够被比较快的支持起来。它能够支持硬件加速，我们也会积极的增强WebCodecs的API实现，让它支持硬件加速。

在WebTransport上，因为它有两种模式，一种是可靠有序，一种是不可靠、不有序的方案，这两种方案在这里做了简单的对比。可靠有序的就是WebTransport Stream，这种比较容易开发，接受端也一样，直接收下来，WebCodecs解码就可以了，比较简单，容易开发。

WebTransport Stream是可靠有序的话，丢包以后，传输层会自动做传输恢复，如果丢包的话就会增加延时，这是无法避免的，因为传输层必须保证丢到的包是有序并且可靠的。

如果是用Datagram的方式，它可以实现自己的算法，自己的丢包逻辑都可以被实现进去。

从客户端角度来说，这是比较简单的，通过WebTransport Stream，是实现可靠的音视频系统[多媒体演示]，接受端也是类似，其实这套方案做起来也比较容易。基本上通过Web API，不需要WebAssembly就可以实现出来。但是这套方案有比较大的延迟，特别是网络状态不太好的时候，延迟有点大，但是网络状态好或者内网环境，用这套方案已经能够完成音视频的上传和下载了。

我们测试的话，如果丢包率小于3%，也能够达到50毫秒左右屏幕到屏幕的延迟，我们用的方案是在一个浏览器上发屏，往另外一端送过去，屏幕到屏幕的延迟是指用照相机拍，两端看到的延迟时间戳的区别。因为屏幕本身也会有延迟，所以实际的延迟可能会比50毫秒略大一点。但是，这种方案对于弱网环境有丢包的话，性能会差一点。所以我们会考虑到网络环境不好，丢包比较多的话，是不是要考虑直接把过时的数据包丢弃掉，不要重传了。另外WebRTC已经有比较好的技术，可以考虑重用起来。

所以，[多媒体演示]这个方案是用WebTransport Datagram，通过一些数据处理送到Web的系统上，编码之后有一些打包的操作，之前我提过希望把WebRTC的暴露出来，但是也考虑在目前没有这组API的情况下，暂时需要通过WebAssembly实现WebRTC的打包器和解包器，因为WebRTC已经有了，需要直接编译。

接收端是类似的流程，但是解包和打包器除了解包和打包之外，还需要通过RTP计算延时，能够反馈给编码器大概可用带宽有多少等等。

刚才提到了我们在做的开源项目，是一个会议模式的系统。所以它还有一个服务器端的实现，在服务器端，因为整套是开源的方案，所以我们也希望尽量应用已有的开源软件，在服务器上，WebTransport的实现，是基于Chromium，在上面封装了一层SKD，上面是C++的SKDI，尽量用新的API保持兼容性。

因为有QUIC的SDK之后，上层应用可以C++，像云游戏的服务器都可以用这套C++的SDK来做。

这是性能上的优化。因为我们尝试做这一套基于WebCodecs、WebAssembly、WebTransport的音视频系统，但是做的时候碰到了很多挑战，而且到目前为止这套系统的延迟应该不能比得过WebRTC。虽然我们考虑这套方案能够解决WebRTC P2P的模式，但是，从延迟上来说，有不少同事或者不少这方面业界的同学问过我，我们大概跑下来，应该说它的性能延迟上还是比不过WebRTC。所以，我们会尝试做性能上的优化，另一方面我们会考虑怎么样促进标准，能够让它比得过或者接近WebRTC的这套方案。

WebRTC为什么性能高呢？其中很重要的原因是WebRTC下层基本都是在C++上完成，很容易优化。但是，因为这套方案好多都是Web API，会有比较多的延迟。针对这些问题，我们组会做积极的优化，并且贡献给浏览器，贡献给Chromium这样的开源项目。

[多媒体演示]这里列举了我们正在做或者已经做的事情，包括增加分层编码的硬件支持，H.264硬件支持以及VP9 kSVC的硬件支持，同时我们希望减少数据拷贝，减少延迟的同时也降低功耗。

另外，目前我们正在支持Chromium WebCodecs HEVC的支持，这样对减少延迟也有好处。另外，多套WebCodecs编码器同时工作的时候，需要减少延迟，我们正在做优化。因为WebTransport用的时候可能会增加一层数据拷贝，所以我们会尝试把BYOB的Reader实现好，减少一些数据拷贝。

好的。我的分享就是这些，看看大家有没有问题。

提问：您好！我看到你们最近在实现WebCodecs HEVC的支持，我看目前只实现了解码的支持，后续有计划做编码的支持吗？

诸剑俊：目前我们正在做，我记得好像大部分的代码已经合并了，所以在Chromium里应该有。但编码的计划需要问一下同事，因为也需要和Chromium做一些沟通，看什么代码合适放进去、什么功能不适合放进去。

提问：你们是一个小组的？

诸剑俊：对。和我们是一个组。

提问：如果后续需要社区提供Chromium，大家可以一起去支持一下。

诸剑俊：好的。谢谢！

提问：WebTransport不可靠，有发现乱序问题吗？

诸剑俊：不可靠本身就有乱序的问题，因为它本身就是不可靠而且无序。既然说起了WebTransport会有的问题，因为用了WebTransport，并且用了不可靠传输以后，基本上我们需要自己处理打包和解包，打包和解包目前比较可能通过WebAssembly，我们把WebRTC的模块通过WebAssembly编译以后，多线程可能会用Web worker。因为Web worker切换的时候，可能有一些上下文的切换，会有比较大的开销，这样的开销可能会用到拥塞或者带宽预测算法的运行。如果是C++的实现，可以比较快的得到一些反馈。如果拿到的数据本身有一些延迟，可能不太准。正好提到这里的问题，我也说一下Web worker可能会带来额外的开销或者不准确。