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

如何实现？