WebRTC自适应网络带宽之联播方案

假设在一个多个用户参与的视频直播系统中，大部分用户的网络都是非常好，但是只有一两个用户用的是3G,4G上网，网络质量不太好。这种情况下对于发布方应该如何处理呢？一种比较容易想到的方案就是降低发布方的视频码流，这样不管网络好还是网络不好的用户都可以流畅观看视频了，这种方案有个致命缺陷，大部分网络好的用户被少数几个网络差的用户给拖累了。

如上图所示，发布方只能发布低于0.5M的码流了，白白浪费的其它 用户的10M带宽。

哪有没有什么方案能照顾到网络好的用户和网络差的用户呢？当然是有的，还不只一种，我们现在先来介绍其中的一种，联播(Simulcast)技术。顾名思义，联播就是发布方同时发布几路不同码流的视频到服务器（SFU)上来，SFU根据接收方的网络状态转发相应的码流给接收用户，上面这种情况如果用联播技术来解决的话，可以给出以下架构图：

上图中发布方同时发布9M视频码流和0.4M的视频码流，这样就可以同时兼兼顾到网络好的用户和网络差的用户了。在这里有些同学可能要问为什么不直接发布10M的码流和0.5M的码流呢？哪是因为我们平时说的多少M的码流只是编码好后的裸数据，在网络传输中还要加上rtp头之类的数据，所有在实际应用中，编码出来的码流一般都要比你的实际网络带宽低一些。

联播技术在WebRTC中是如何实现的呢？WebRTC默认是没有开启联播功能的。想要使用联播功能，首先第一步我们要把他开启起来，我们把生成的Offer SDP修改一下就好了：

原生的Offer SDP中有这么一段:

a=ssrc-group:FID 3383221279 2661971602

a=ssrc:3383221279 cname:Yy4JddEmmT7fHiQO

a=ssrc:3383221279 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:3383221279 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2

a=ssrc:3383221279 label:62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:2661971602 cname:Yy4JddEmmT7fHiQO

a=ssrc:2661971602 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:2661971602 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2

a=ssrc:2661971602 label:62c5c8ff-ad5e-444e-bf2f-135554e4caa3

我们修改成这样

a=ssrc:3383221279 cname:Yy4JddEmmT7fHiQO

a=ssrc:3383221279 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:3383221279 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:3383221279 label:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:728565452 cname:Yy4JddEmmT7fHiQO

a=ssrc:728565452 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:728565452 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:728565452 label:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:700454278 cname:Yy4JddEmmT7fHiQO

a=ssrc:700454278 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:700454278 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc:700454278 label:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3

a=ssrc-group:SIM 3383221279 728565452 700454278

注意红色标记的这行，在WebRTC代码中，这表示同时发布三个视频流，后面跟的是三个视频流的SSRC,我们用wireshark抓包看看有没有生效

从图中可以看到payload为102的数据包有三个不同的ssrc,代表联播生效了。

在WebRTC代码simulcast.cc 中有这样的代码

const SimulcastFormat kSimulcastFormats[] = {

{1920, 1080, 3, 5000, 4000, 800},

{1280, 720, 3, 2500, 2500, 600},

{960, 540, 3, 900, 900, 450},

{640, 360, 2, 700, 500, 150},

{480, 270, 2, 450, 350, 150},

{320, 180, 1, 200, 150, 30},

{0, 0, 1, 200, 150, 30}

};

我来介绍一下这些代码的意思，第一行表示你摄像头最大分辨率为1920*1080时，会产生3个视频流，第一路流分辨率为1920*1080，最大码流为5000kpbs,起始码流为4000kpb,最小码流为800kbps,第二路流为960*540，最大码流为900kpbs,起始码流为900kbps,最小码流为600kbps,第三路视频为480*270，最大码流为450kbps,起始码流为350kpbs,最小码流为150kbps。其余分辨率以此内推。

当你是使用的是Native客户端时，你可以自己修改这些值，配置不同的码流。如果只是用的网页版本，哪就没有办法了，只能用上述已经配置好的码流了。