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}
};

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

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

作者:rtc8_com
来源:CSDN
原文:https://blog.csdn.net/onlycoder_net/article/details/77189613
版权声明:本文为博主原创文章,转载请附上博文链接!

WebRTC应用中如何检测回音

在WebRTC应用开发中,我们可能需要知道某个通话过程中是否有回音产生,传统的做法是通过人工去听才能知道。从WebRTC56版本开始,WebRTC提供了一个接口可以让我们知道是否有回音。

有两个办法可以观察,一是如果是使用网页版本的WebRTC,你可以在浏览器中输入chrome://webrtc-internals,在打开的网页中关于音频的统计项目中有googResidualEchoLikelihood这一项,googResidualEchoLikelihood取值范围是0~1,0代表完全没有回音,1代表回音特别大。一般这个值超过0.5代表人耳可以很明显的听出有回音了。另外一种方法是调用GetStats接口拿到这个值,这样你就可以你在的应用中提示用户有没有回音了。另外一个相关联的值是googResidualEchoLikelihoodRecentMax,这个代表前10秒内回音的最大值

作者:rtc8_com
来源:CSDN
原文:https://blog.csdn.net/onlycoder_net/article/details/77479268
版权声明:本文为博主原创文章,转载请附上博文链接!