WebRTC多人视频通话分析

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

一、Mesh架构

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

Mesh架构

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

二、Mixer架构

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


Mixer架构

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

现有方案:

三、Router架构

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

Router架构

该方案优点:
1.1,与Mixer相比服务端压力比较小,而且容易扩展。
1.2,低延迟
该方案缺点:
1.1,不同客户端能够接收的媒体流不尽相同,服务器端需要适配

四、基于Mesh架构的例子

目前我们实现了一个基于Mesh架构的多人视频通话Demo应用,基于这个应用测试了在不同情况下多人视频通话的情况。
WebRTC不同Sent分辨率下的最大码率:
webrtc\media\engine\webrtcvideoengine2.cc
// The selected thresholds for QVGA and VGA corresponded to a QP around 10.
// The change in QP declined above the selected bitrates.
static int GetMaxDefaultVideoBitrateKbps(int width, int height) {
if (width * height <= 320 * 240) {
return 600;
} else if (width * height <= 640 * 480) {
return 1700;
} else if (width * height <= 960 * 540) {
return 2000;
} else {
return 2500;
}
}
最大默认码率的意义在于:在特定分辨率下,只要视频流的发送码率达到最大默认码率,视频质量已经足够好,再增大发送码率对视频质量的影响已经不大。

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分辨率越低。

1、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带宽自适应算法
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,222评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,455评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,720评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,568评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,696评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,879评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,028评论 3 409
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,773评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,220评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,550评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,697评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,360评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,002评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,782评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,010评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,433评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,587评论 2 350

推荐阅读更多精彩内容