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帧请求。

如何实现?

你可能感兴趣的:(Webrtc 简单实用的Qos优化 - 草稿)