如何基于WebRTC搭建一个简单的视频会议

WebRTC&＃xff0c;它是由谷歌推广的实时音视频技术栈&＃xff0c;是音视频领域搜索热度最高的技术。它有多重身份&＃xff0c;既是W3C的标准&＃xff0c;也是一个开源项目&＃xff0c;还有一个对应的IETF工作组(RTCWEB)。在WebRTC出现之前&＃xff0c;音视频通信是高不可攀的领域&＃xff0c;需要大量的专业积累才能入门&＃xff0c;而现在&＃xff0c;越来越多的开发者通过WebRTC来深入了解RTC技术。

WebRTC技术的本质是构建点对点的实时通信&＃xff0c;目前主流的浏览器&＃xff0c;包括Chrome, Firefox, Edge等&＃xff0c;天然就支持WebRTC协议。对入门开发者来说&＃xff0c;选用这几款浏览器&＃xff0c;连开发客户端的时间都省了。最简单的Web视频会议&＃xff0c;只需要架设一个Web服务器&＃xff0c;服务器兼具信令交换的能力(信令服务也可以独立部署)&＃xff0c;两个浏览器通过Web Server交换会话信息&＃xff0c;就能建立P2P通道来传输媒体流&＃xff0c;进行1v1的视频会议。如下图所示&＃xff1a;

两个浏览器向Web服务器请求页面&＃xff0c;并进行SDP交换&＃xff0c;然后在浏览器之间直接建立P2P Transport&＃xff0c;进行媒体流传输。这是最简单的WebRTC应用形式。这种简单的媒体流直联的方式&＃xff0c;线上有很多教程&＃xff0c;也可以参考WebRTC的demo (https://webrtc.github.io/samples/)&＃xff0c;这里不展开。

如果拓展到多方的视频会议&＃xff0c;架构是这样的&＃xff1a;

可以看到&＃xff0c;这种”简单”的视频会议&＃xff0c;有两个风险点&＃xff1a;

1. P2P在两个客户端之间建立&＃xff0c;不可避免的涉及到NAT穿透的问题&＃xff0c;打洞的成功率直接影响P2P的可用性&＃xff0c;在会议场景是不能接受的。

2. 在多人场景下&＃xff0c;本地的媒体流以拷贝的形式发送给每个对端&＃xff0c;对网络带宽是个极大的浪费&＃xff0c;上行网络的带宽瓶颈决定了会议的方数上限&＃xff0c;影响体验&＃xff0c;也不利于扩展。

    

要解决这两个问题&＃xff0c;就要引入媒体服务器。看下面的架构图&＃xff1a;

加入媒体服务器后&＃xff0c;每个浏览器只和服务器建立媒体传输通道。

• 媒体服务器架设在公网&＃xff0c;P2P的可用性有保障。

• 每个浏览器只向服务器发送一路本地媒体流&＃xff0c;由服务器负责转发给远端&＃xff0c;避免了带宽浪费。

对于视频会议来说&＃xff0c;这是更优的架构选择。

常用的媒体服务器主要分为SFU(Selected Forward Unit)和MCU(Multipoint Control Unit)&＃xff0c;SFU只负责媒体流转发&＃xff0c;不做太多复杂的媒体处理&＃xff0c;并发能力会强一些。MCU除了媒体流的接收/发送&＃xff0c;还会进行转码和混流&＃xff0c;对服务器的性能要求比较高&＃xff0c;在实时传输系统中&＃xff0c;转码会带来额外的延时&＃xff0c;在选型时也必须考虑。多人视频会议场景下的SFU/MCU架构示意如图&＃xff1a;

SFU对接入的媒体流进行全网转发&＃xff0c;MCU对接收到的媒体流做转码后&＃xff0c;只转发一路合成后的媒体流。它们的优势和劣势总结如下表&＃xff1a;

WebRTC的生态中&＃xff0c;有许多优秀的开源媒体服务器&＃xff0c;下面列出部分关注度高的项目&＃xff1a;

大家可以根据自己的需求&＃xff0c;选择合适的项目来搭建媒体服务器。对于实时性和高并发有强要求的会议场景&＃xff0c;笔者还是推荐采用SFU架构&＃xff0c;下面的进阶篇中也会基于SFU展开介绍。

另外&＃xff0c;如果不满足于浏览器入会&＃xff0c;有扩展客户端覆盖的需求&＃xff0c;上述的开源项目中&＃xff0c;也有相应的native的客户端库&＃xff0c;比如mediaSoup&＃xff0c;有提供一个libmediasoupclient的C&＃43;&＃43; library&＃xff0c;这个库本身是基于libwebrtc的&＃xff0c;大家可以基于这个库来搭建iOS/Andriod/PC的客户端&＃xff0c;需要一定的时间摸索编译环境&＃xff0c;但不会太复杂。

这还不是WebRTC生态的全部&＃xff0c;在客户端扩展方面&＃xff0c;WebRTC是一直走在路上的&＃xff0c;各种前沿的混合开发框架项目中&＃xff0c;都能看到它的身影&＃xff0c;比如RN/Flutter/Cordova等等&＃xff0c;在Github上都有WebRTC开发库&＃xff0c;愿意实践的开发者可以尝试&＃xff0c;不过&＃xff0c;要用这些开发框架做到产品化&＃xff0c;还是需要一定积累的&＃xff0c;需要踩一些坑。

到这里&＃xff0c;我们完成了基础的视频会议搭建&＃xff0c;或许在通话时会面对这样那样的质量问题&＃xff0c;但至少实现了听得见、看得到&＃xff0c;浅尝辄止的目标已达成。下面的进阶篇&＃xff0c;就留给打算深入学习RTC的小伙伴(需要一些音视频基础)。

视频会议的基础是实时音视频通信(RTC)技术&＃xff0c;在上一篇解决了听得见、看得到的问题之后&＃xff0c;在接下来的进阶篇中&＃xff0c;我们重点关注下如何能让音视频通信稳定、流畅、可靠&＃xff0c;也就是关乎视频会议的质量体验问题。

大家可能都会有这样的体会&＃xff0c;视频会议总是很难保持稳定&＃xff0c;偶尔会视频卡住&＃xff0c;或者声音断续&＃xff0c;或是今天可以正常完会&＃xff0c;改天就不好。其实实时音视频通信的原理就是信号的采集&＃xff0c;处理和传输&＃xff0c;而其中传输部分是最难把控的&＃xff0c;为了做到实时性&＃xff0c;我们要摒弃长时延、可靠的TCP&＃xff0c;选择不可靠&＃xff0c;但有可能做到实时的UDP。在公共互联网上用UDP搭建传输网络&＃xff0c;它的不可靠的因子会被放大&＃xff0c;比如时延&＃xff0c;抖动&＃xff0c;丢包等&＃xff0c;都有可能影响视频会议的体验。

下面的章节中&＃xff0c;我们重点介绍实时音视频通信中的Quality of Service(QoS)。QoS可以狭义地理解为链路分组数据传输的质量指标&＃xff0c;相对的另一个指标是Quality of Experience(QoE)&＃xff0c;它是用户对设备&＃xff0c;网络和系统总体的端到端主观体验。

 QoS那些事 

WebRTC中已经具备了一些保障QoS的策略&＃xff0c;比如ARQ&＃xff0c;FEC&＃xff0c;Jitter Buffer&＃xff0c;Congestion Control等&＃xff0c;让我们结合前面的SFU架构来展开探讨。

QoS策略的主要任务是对抗影响数据传输的网络变量&＃xff0c;比如时延&＃xff0c;抖动&＃xff0c;丢包&＃xff0c;带宽等。我们简单介绍下QoS的常规武器。

• ARQ&＃xff1a;自动重传请求&＃xff0c;是数据链路层的错误纠正协议之一&＃xff0c;WebRTC中用到是协议中的NACK机制&＃xff0c;即接收端监测到数据包SeqN丢失后&＃xff0c;发送对该数据包的重传请求&＃xff0c;由发送端执行重传。

• FEC&＃xff1a;前向纠错&＃xff0c;是增加数据通讯可靠度的方法&＃xff0c;利用原始数据编码进行冗余信息的传输&＃xff0c;当传输中出现丢包&＃xff0c;允许接收端根据冗余信息重建。WebRTC利用UlpFEC进行数据保护&＃xff0c;冗余系数由链路上的丢包率决定。

• Jitter Buffer&＃xff1a;抖动缓冲&＃xff0c;通过在接收端维护一个数据缓冲区&＃xff0c;可以对抗一定程度的网络抖动&＃xff0c;丢包和乱序&＃xff0c;需要考虑的是接收延时和卡顿之间的平衡。

• Congestion Control&＃xff1a;拥塞控制&＃xff0c; WebRTC利用GCC算法来控制传输&＃xff0c;通过兼顾丢包和时延的算法来估计网络可用带宽&＃xff0c;并以此估算值来控制源端发送码率&＃xff0c;避免网络拥堵。

在典型的SFU传输链路中&＃xff0c;媒体流(RTP数据包)由Sender发送到Receiver&＃xff0c;媒体控制流(RTCP包)由Receiver反馈给Sender。控制流中包括了NACK, PLI, REMB, Receiver Report等反馈信息。这些反馈信息是配合QoS策略的辅助手段。

有了这些QoS策略的加持&＃xff0c;WebRTC的视频通话能够对抗一定程度的网络状况&＃xff0c;正常情况下的通话质量可以保障。但是&＃xff0c;这种默认的策略也存在明显的改进空间&＃xff0c;比如&＃xff1a;

• QoS的策略是在端到端之间生效的&＃xff0c;接收端发现丢包后&＃xff0c;才会向发送端发送NACK请求重传&＃xff0c;全链路的路径(rtt)过长&＃xff0c;影响数据重传和恢复的效率。

• 接收端在发现无法恢复视频帧后&＃xff0c;才会发送PLI(Picture Lost Indicator)向源端请求关键帧&＃xff0c;直到下一个关键帧到达前&＃xff0c;所有链路上的视频帧都无法正常解码&＃xff0c;影响接收端的视频帧率&＃xff0c;较大概率造成卡顿。

• 针对这两个典型的问题&＃xff0c;我们可以分别尝试改进。

如上图所示&＃xff0c;在改进的SFU传输架构中&＃xff0c;重传请求不再是全链路反馈&＃xff0c;而是在客户端和服务器之间进行。一方面&＃xff0c;服务器具备了NACK请求的能力&＃xff0c;及时发现上行链路的丢包&＃xff0c;及时向发送到请求重传。另一方面&＃xff0c;服务器能够及时响应接收端的NACK请求。丢包重传的效率提升&＃xff0c;有助于减少端到端延时&＃xff0c;改善音视频体验。

对于弱网下视频帧率较低的问题&＃xff0c;除了优化传输过程中的FEC&＃43;NACK策略之外&＃xff0c;还可以从源端编码器入手调整。

常规的RTC系统中的编码GOP是IPPP…P&＃xff0c;每一个P帧都作为参考帧&＃xff0c;一旦某一帧有数据包缺失&＃xff0c;其后的所有P帧都无法正常解码&＃xff0c;抗误码扰动的能力比较差。

一种改进的思路是&＃xff0c;改变编码器的参考帧选择&＃xff0c;采用长参考帧Long-Term Reference (LTR) frames机制&＃xff0c;比如&＃xff1a;

可以看到&＃xff0c;引入LTR后&＃xff0c;P帧不再是单一的前向参考&＃xff0c;而是会有选择性的参考一些固定的帧&＃xff0c;只要这部分固定的参考帧能够完整被接收&＃xff0c;就能确保其他的完整帧能够正常解码&＃xff0c;提高接收端的视频帧率&＃xff0c;保障流畅。这种编码方式是比较适合于RTC系统的&＃xff0c;能够对抗更大的网络抖动。

应用在视频会议中&＃xff0c;需要接收端实时反馈的配合。接收端借助于RTCP&＃xff0c;实时反馈能够正常解码的帧信息&＃xff0c;发送端可以利用收集到的这些信息&＃xff0c;选择合适的参考帧序列(需要兼顾编码效率)&＃xff0c;这样端到端的配合&＃xff0c;能够最大程度的提升实时传输系统的体验。

这种反馈与编码协同的机制&＃xff0c;同样适用于多人的会议场景。只不过&＃xff0c;在多人场景中&＃xff0c;我们要面对更加棘手的多端拥塞控制问题。

前面介绍过WebRTC自带的端到端拥塞控制&＃xff0c;在会议场景下&＃xff0c;拥塞控制需要综合考虑各个客户端的情况&＃xff0c;如下图所示&＃xff1a;

在多人会议情况下&＃xff0c;各个接收端的带宽能力是不相同的&＃xff0c;每条链路的带宽估计值都会反馈到发送端&＃xff0c;由发送端来统一决策&＃xff0c;控制编码和发送码率。这会带来两个潜在的问题&＃xff1a;

• 多条链路的带宽反馈导致发送端的决策困难&＃xff0c;编码/发送码率容易抖动。

• 某一个接收端的网络带宽不足(如图中的300k下行)&＃xff0c;发送端就会降低码率以适配当前带宽&＃xff0c;导致每个接收端的体验都会下降&＃xff0c;这显然是不合理的。

解决这些问题&＃xff0c;我们就要来改进拥塞控制模型。大致的思路是&＃xff0c;在SFU上实现带宽估计反馈&＃xff0c;以及下行的拥塞控制。将端到端的拥塞策略&＃xff0c;演进为分段的拥塞控制策略。

理想情况下&＃xff0c;发送端会根据上行的带宽估计值控制源端编码和发送码率&＃xff0c;SFU则会利用下行的带宽估计值&＃xff0c;来控制下发给各接收端的最高码率。

然而&＃xff0c;现实问题是&＃xff0c;当SFU只有一路视频可以转发时&＃xff0c;如何根据各链路的带宽情况进行下发控制&＃xff0c;有点巧妇难为无米之炊的感觉。

这里要借助于两种源端编码策略 - Simulcast和SVC。

Simulcast&＃xff1a;同步广播&＃xff0c;指的是同时编码/发送多路视频流&＃xff0c;比如常规发送一路720p&＃xff0c;外加一路180p的流&＃xff0c;这样在SFU下发给接收端的时候&＃xff0c;可以根据下行带宽的限制&＃xff0c;选择下发不同分辨率的流&＃xff0c;照顾到每个端的体验。应用Simulcast的系统示意&＃xff1a;

SVC&＃xff1a;可伸缩编码&＃xff0c;使用基于层次的方法&＃xff0c;提供时间或空间可伸缩编码组合。在RTC的应用中&＃xff0c;通常会选用时域SVC&＃xff0c;通过改变帧率来实现伸缩性。SFU可以根据下行的实际带宽&＃xff0c;从同一路SVC视频流中解析出不同的时域分层&＃xff0c;分别传输给各个接收端&＃xff0c;同样可以实现差异化的视频流转发。

Simulcast和SVC在实际应用中各有优劣&＃xff0c;Simulcast多路流的分辨率跨度大&＃xff0c;主观体验不佳&＃xff1b;SVC的时域分层会影响帧率&＃xff0c;容易出现卡顿。

 实时传输网络 

前一节重点介绍了WebRTC QoS的基本配置&＃xff0c;以及进阶的实践方向。有了这些武器&＃xff0c;可以在上下行网络质量有波动时&＃xff0c;还能保障较好的音视频体验。

在视频会议的搭建过程中&＃xff0c;QoS策略的保障是一方面&＃xff0c;传输链路的选择也同样重要。

到目前为止&＃xff0c;我们介绍的视频会议架构还是中心服务器转发&＃xff0c;摆在我们面前有几个显而易见的问题&＃xff1a;

• 用户远距离接入&＃xff0c;尤其是跨国、跨地区时&＃xff0c;传输链路质量没有保障。

• 国内的跨运营商之间接入&＃xff0c;网络抖动大&＃xff0c;影响会议质量。

• 单点服务器的容量和负载受限制。

   

如果希望我们的视频会议是稳定、可靠的&＃xff0c;解决上面的所有问题&＃xff0c;必须构建一个具备智能调度的实时传输网络。

整体网络传输的调度见上图&＃xff0c;几点简要的说明&＃xff1a;

• 分区域/分运营商部署SFU服务器&＃xff0c;用户通过接入服务实现就近接入&＃xff0c;保障了最后一公里的质量。

• 灵活/按需部署路由节点&＃xff0c;通过路由分配服务&＃xff0c;能够根据实时网络质量选择最优的传输路径。

• 分布式的SFU更有利于会议方数的扩展和服务扩容

• 需要保障传输s网络内部的数据传输质量&＃xff0c;可以尝试QUIC。

   

结合上述两点&＃xff0c;有了可靠的传输网络&＃xff0c;加上QoS保障的上下行质量&＃xff0c;才能实现让人放心的视频会议体验。

 其    他 

除了网络传输和QoS之外&＃xff0c;视频会议的质量体验也和客户端的表现相关&＃xff0c;一些端侧的疑难杂症&＃xff0c;比如设备可用性&＃xff0c;回声消除&＃xff0c;双讲抑制等等&＃xff0c;一定程度上决定了会议产品的成败。