基于WebRTC音视频实时交互系统概述

一、WebRTC 简介

近些年来，音视频技术发展逐步趋于成熟，一方面，视频编解码技术不断发展，如H264/H265、VP8/VP9以及AV1编解码器等，使得视频压缩率越来越高；另一方面，音频压缩率也因OPUS、AAC等宽带音频技术的应用有了很大提高。此外，随着移动通信从3G到4G，再到5G的发展，移动网络的带宽和质量越来越高，为音视频数据的网络传输提供了保障。因此，音视频技术逐渐进入到越来越多的领域，如视频会议、在线教育、远程医疗、直播等。但是以往的音视频服务都是基于APP，不利于使用和开发。Google在2011年推出基于浏览器的开源项目WebRTC（Web Real-Time Communication，网页即时通信），帮助实现各种音视频编解码器，解决了跨平台等问题，可以通过浏览器可以快速地实现音视频通信，大大降低了音视频使用和开发的技术门槛，加速了音视频技术的应用与推广。目前主流浏览器如Edge、Chrome、Firefox等都已支持WebRTC。可以预见，未来音视频技术将会作为一种基础技术应用到更广泛的场景中。本文主要介绍几种基于WebRTC的音视频实时交互系统。

二、WebRTC 1V1音视频实时交互系统

基于WebRTC的1V1系统主要由两个 WebRTC 终端、一个 Signal（信令）服务器和一个 STUN/TURN 服务器四部分组成，架构如图1所示。其中WebRTC 终端主要负责音视频采集、编解码、NAT 穿越、音视频数据传输；Signal 主要负责信令处理，如加入、离开房间等；STUN/TURN 主要负责获取 WebRTC 终端的IP，以及 NAT 穿越失败后的数据中转，通信时如果终端不能通过 P2P 直接进行通信，则会使用STUN/TURN 服务器来进行中转。

WebRTC 1V1系统通信的主要过程如下：

（1）WebRTC终端检测音视频等相关设备是否正常。

（2）如果正常，则进行音视频数据采集，采集的数据一方面可以用做预览，另一方面，也可以存储用于回看和进一步处理。

（3）在获取音视频数据就绪后，WebRTC 终端会发送加入信令到 Signal 服务器。

（4）Signal 服务器收到该消息后会创建房间。另一端则会加入房间。

（5）在对端成功加入房间后，终端将创建媒体连接对象，将采集编码后的音视频数据通过P2P/STUN发送给对端。

      （6）对端端接收后，将收到的音视频数据进行解码，展示或者存储等。

三、WebRTC多人音视频实时交互系统

除了上述1V1即时通信系统外， 基于WebRTC还可以构建多人音视频实时交互系统，目前，多方通信架构主要有Mesh、MCU（Multipoint Conferencing Unit）、SFU（Selective Forwarding Unit）三种。

3.1 Mesh 多方音视频交互系统

Mesh方案多个终端中通过每个节点都与其他所有节点建立连接，同时还分别与STUN/TURN服务器进行连接，组成一个网状结构，如图2所示。假如有三个终端B1、B2、B3进行多方通信，当B1想要共享音频或者视频时，它需要分别向B2、B3发送数据。同理，当B2 想要共享信息时，就需要分别向B1、B3 发送数据，这样就实现了多人通信。

Mesh由于终端之间可以利用客户端的带宽资源直接传输数据，因此其优势是不需要额外的数据中转服务器（STUN/TUTN 只是负责NAT 穿越），节省了服务器资源，可以很好地控制成本。当然，有优势自然也有不足之处，当共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，这样对上行带宽、CPU、内存等资源的占用很大。而且会随着参与人数线下增加，导致多人通信的规模非常有限，目前的实践来看，Mesh方案在多余4个链接时，就会有很大的问题。另一方面，在多人通信时，如果有部分人不能实现NAT穿越，但还想让这些人与其他人互通，就显得很麻烦，需要做出更多的可靠性设计。

3.2 MCU（Multipoint Conferencing Unit）多方音视频交互系统

MCU是由一个服务端和多个终端组成的一个星形结构系统，如图3所示。终端将各自要共享的音视频流发送给服务端，服务端接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混合好的音视频流发送所有终端。

假如B1与B2同时共享音视频，它们首先将音视频数据流传到MCU服务器，MCU 服务器收到两路数据流后，分别进行解码，之后将解码后的两路流进行混流，然后再编码，最终再分发给B3和B4。对于B1来说，因为它是其中的一个共享者，所以MCU推给它的是除了它本身以为的其它方的共享流数据，也就是B2的流数据。同理，对于B2来说MCU给它发的是 B1的音视频流数据。因此随着共享人数的增加，数据的量会呈几何级增加。服务端的处理流程如图4所示。

接收端在收到音视频数据流后首先进行解码，然后对于视频流，要进行重新布局，混合处理。对于音频流，要进行混音、重采样处理，而后进行音视频混合、编码、最后推送给各接收端。

MCU由于需要对数据进行重新解码、编码、混流等，因此会有一定的延迟，而且这些数据处理都需要大量的CPU运算，非常消耗CPU资源，所以MCU所提供的容量有限，一般也就能支持十几路视频。但是通过解码、再编码可以屏蔽不同编解码设备之间的差异，能够支持更多不同类型的设备，且多路视频混合成一路，人们看到的画面相同，可以带来更好的用户体验和产品竞争力。

3.3 SFU（Selective Forwarding Unit）多方音视频交互系统

SFU也是由一个服务器和多个终端组成的星状结构，但与MCU不同的是，SFU不对音视频进行混流，就像一个媒体流路由器，在接收到终端共享的音视频流后，就会根据需要直接将此音视频流转发给房间内的其他终端，如图5所示。

如图5中，B1、B2、B3、B4 表示4个不同的终端，每个终端都会将自己的音视频数据流发给SFU，SFU将接收的每一路流转发给其它的3个终端，处理流程如图6所示。

相比Mesh和MCU，SFU在结构上较为简单，不需要对数据进行编解码等处理，接收音视频数据流直接转发给其他终端，因此系统的灵活性很好，可以根据终端的下行网络状况做一些流控，如根据带宽、网络延时等来判断是否要丢弃一些数据来保证流畅性。此外，由于直接转发不需要编解码，因此对CPU资源消耗也很小，减少了延迟，提高了实时性。而目前很多SFU实现都支持SVC模式和Simulcast模式，用于适配4G、WiFiX以及Phone、Pad、PC等不同的网络和终端情况。同样，由于是直接转发数据包，可能会导致不同的终端之间画面不一致，多路视频流对窗口显示、渲染等也会有一定的影响，不利于回放和后期处理。

四、小结

本文主要介绍了基于WebRTC 构建的1V1和三种多方通信系统 Mesh、MCU 和 SFU。目前由于使用场景、技术、成本等各方面限制，1V1和Mesh 架构很少有人使用。MCU 架构比较成熟，但是硬件成本高，目前通常应用于视频会议中，且随着互联网与音视频技术的发展，硬件 MCU 可能会逐步被淘汰。SFU 由于架构灵活，性能也非常高，是目前最流行的架构，也是未来各个公司应用和研发的主要方向。

作者：霍振坤