WebRTC多人视频通话分析

https://www.jianshu.com/p/f6a80e873764

基于WebRTC的多人视频概括来讲有三种架构模式:Mesh、Router和Mixer。

一、Mesh架构

这是最简单的多人视频通话架构模式,所有媒体流都不需要经过服务端,客户端直接P2P,可通过WebRTC建立多个PeerConnection,结构图如下:


Mesh架构

该方案优点:

  1. 服务端压力最小,大多数情况下不需要用到流媒体服务。
    该方案缺点:
  2. 客户端负载太大,不事宜扩展,特别是移动端,编解码压力会非常大.

二、Mixer架构

视频会议基本上就是种结构,他的最大特点就是服务端做了很多事情,包括转码,混音,合屏,所以服务端负载非常大,结构图如下:


Mixer架构

该方案优点:

  1. 客户端负载最小,与一对一负载一样,所以理论上可以支持很多人同时视频。
    该方案缺点:
  2. 服务端负载很大,建设成本很高。
  3. 延迟问题,因为服务端做了很多动作(解码,合屏,混音,编码),所以会带来延迟。

现有方案:

三、Router架构

该方案最大特点就是服务端只负责包转发,不负责转码,结构图如下.


Router架构

该方案优点:

  1. 与Mixer相比服务端压力比较小,而且容易扩展。
  2. 低延迟

该方案缺点:

  1. 不同客户端能够接收的媒体流不尽相同,服务器端需要适配

四、基于Mesh架构的例子

目前我们实现了一个基于Mesh架构的多人视频通话Demo应用,基于这个应用测试了在不同情况下多人视频通话的情况。

WebRTC不同Sent分辨率下的最大码率:

webrtc\media\engine\webrtcvideoengine2.cc

  1. // The selected thresholds for QVGA and VGA corresponded to a QP around 10.
  2. // The change in QP declined above the selected bitrates.
  3. static int GetMaxDefaultVideoBitrateKbps(int width, int height) {
  4. if (width * height <= 320 * 240) {
  5. return 600;
  6. } else if (width * height <= 640 * 480) {
  7. return 1700;
  8. } else if (width * height <= 960 * 540) {
  9. return 2000;
  10. } else {
  11. return 2500;
  12. }
  13. }

最大默认码率的意义在于:在特定分辨率下,只要视频流的发送码率达到最大默认码率,视频质量已经足够好,再增大发送码率对视频质量的影响已经不大。

1、H264软件编解码

(目的是观察CPU对视频流Sent分辨率的影响)
参与方
A - We45
B - 小米Note
C - 红米
发送端Input分辨率都设为1280x720
1.在只有A和B的情况下,各Sent分辨率如下:
A->B 640x360
B->A 640x360
Sent分辨率降低都是由CPU导致的。
2.C加入后,各Sent分辨率如下:(Sent分辨率实际上是会变化的,下面的数据是一段时间之后基本稳定的数据,视频通话继续进行Sent分辨率还有可能进一步降低)
A->B 480x270
A->C 480x270
B->A 320x180
B->C 320x180
C->A 320x180
C->B 320x180
Sent分辨率降低都是由CPU导致的。
由此可以得出如下结论:使用软件编解码,影响Sent分辨率的主要因素是CPU负载;参与多人视频通话的参与方越多,WebRTC Sent分辨率越低。

H264硬件编解码

(目的是排除CPU对视频流的影响,方便观察带宽对视频流的影响)
参与方
A - We45
B - 小米Note
C - We45
1.在只有A和B的情况下,各项数据如下:


A和B

2.C加入后,各Sent分辨率和导致分辨率降低的原因如下:


A、B和C

由此可以发现如下现象:
1.目标码率由发送端估算带宽和分辨率对应的默认最大码率决定,但实际码率不一定与目标码率一致。如果实际码率低于发送端估算带宽,则Sent分辨率会降低。如果实际码率等于发送端估算带宽,Sent分辨率不会降低。
疑问1:实际码率是由什么决定的?
实际码率除了收到发送端目标码率的影响,还有可能收到接收端接收码率的影响。按照目标码率发送数据,但因为接收端的接收能力的限制,接收端并不足以即时接收数据,发送端收到接收端的反馈信息后,会做出相应的调整,降低实际的发送码率。这就是WebRTC的带宽自适应算法:
WebRTC中的带宽自适应算法分为两种:
1.发端码率控制, 原理是由rtcp中的丢包统计来动态的增加或减少码率,在减少码率时使用TFRC算法来增加平滑度。
2.收端带宽估算, 原理是收到rtp数据,估出带宽;用卡尔曼滤波,对每一帧的发送时间和接收时间进行分析,从而得出网络带宽利用情况,修正估出的带宽。
两种算法相辅相成,收端将估算的带宽发送给发端,发端结合收到的带宽以及丢包率,调整发送的码率。


WebRTC带宽自适应算法

作者:MaxLiao
链接:https://www.jianshu.com/p/f6a80e873764
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。