Webrtc 简单实用的Qos优化 - 草稿

WebRTC有非常多的Qos策略,NACK, PLI, FEC等,在产品实践中,BAT对每个环节都有优化,以达到最优效果,实现70%抗丢包。原来x265对应x264节省25%带宽,通过自研编解码器,实现H265节省带宽56%。问题是对于小公司,即有自研RTC系统和优化Qos的需要,同时研发投入又非常有限,本问探讨了WebRTC最简单实用的Qos优化策略。


音视频传输的挑战

图片引用自:https://mp.weixin.qq.com/s/ElxkvOAZpp_sDCsNaJ9FmQ

网络传输和播放缓存,贡献了78%的延时。无线传输相较于有限网络,更加复杂多变,Wifi信号干扰,4G用户移动造成的信号不稳定,拥塞,运营商带宽限速,造成丢包、拥塞、延时抖动,以及各种复合状况。

现有Qos策略的弊端

对抗丢包,WebRTC的Qos策略有,音频RED、NACK,FEC,PLI,FIR,这些策略再某些情景下能发挥很好的作用,例如:

NACK:延时低,带宽够,少量随机的丢包

FEC:冗余带宽够,低于FEC算法能力上限的丢包

PLI(Picture Lost Indication):带宽够,延时低,超过NACK上限的大量丢包,或者SPS参数解析失败

FIR(Full Intra Request):切换视频源,用用户加入多人会议,需要同学各方发送key frame。Intra是指帧内编码,而不是需要依赖其它帧的inter frame B或P帧。

同时,在某些情景下,上述的策略会失效,或加剧问题。

NACK: 延时较大,例如传输延时200ms+NACK消息返回200ms+RTP重传200ms,重传之后延时增大到600ms,缓存队列增大。重传的流量,也可能加速带宽消耗,拥塞恶化。

PLI:由于key frame较大,重传I帧会加剧带宽消耗。

FEC:因带宽有限,FEC冗余占用了宝贵的带宽

阿里GRTN的Qos策略

简单高效的Qos优化策略

  Qos优化可以无极限的追求,对于研发实力薄弱的小公司,在Qos优化的巨坑里面,如何简单高效的取得成果呢?

1,音频流的动态RED冗余

    连续的音频是重要的用户体验,流的码率小,常用语音码率为20kbps~60kbps?。音频RED的原理,就是将码流冗余发送,例如30kbps,冗余发送1份就是60kbps,RED发送2份就是90kbps。这样在丢包率50%情况下,用户仍然能听到连续的音频,实现增强用户Qos体验。

2、视频LTR

对于静态画面,LTR能显著抵抗丢包画质,减少I帧请求。

如何实现?

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • 渐变的面目拼图要我怎么拼? 我是疲乏了还是投降了? 不是不允许自己坠落, 我没有滴水不进的保护膜。 就是害怕变得面...
    闷热当乘凉阅读 4,505评论 0 13
  • 夜莺2517阅读 128,225评论 1 9
  • 版本:ios 1.2.1 亮点: 1.app角标可以实时更新天气温度或选择空气质量,建议处女座就不要选了,不然老想...
    我就是沉沉阅读 7,524评论 1 6
  • 我是一名过去式的高三狗,很可悲,在这三年里我没有恋爱,看着同龄的小伙伴们一对儿一对儿的,我的心不好受。怎么说呢,高...
    小娘纸阅读 3,915评论 4 7
  • 那一年,我选择了独立远行,火车带着我在前进的轨道上爬行了超过23个小时; 那一年,我走过泥泞的柏油路,在那个远离故...
    木芽阅读 1,979评论 4 5

友情链接更多精彩内容