WebRTC有非常多的Qos策略，NACK, PLI, FEC等，在產(chǎn)品實(shí)踐中，BAT對(duì)每個(gè)環(huán)節(jié)都有優(yōu)化，以達(dá)到最優(yōu)效果，實(shí)現(xiàn)70%抗丟包。原來x265對(duì)應(yīng)x264節(jié)省25%帶寬，通過自研編解碼器，實(shí)現(xiàn)H265節(jié)省帶寬56%。問題是對(duì)于小公司，即有自研RTC系統(tǒng)和優(yōu)化Qos的需要，同時(shí)研發(fā)投入又非常有限，本問探討了WebRTC最簡(jiǎn)單實(shí)用的Qos優(yōu)化策略。

音視頻傳輸?shù)奶魬?zhàn)

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

網(wǎng)絡(luò)傳輸和播放緩存，貢獻(xiàn)了78%的延時(shí)。無線傳輸相較于有限網(wǎng)絡(luò)，更加復(fù)雜多變，Wifi信號(hào)干擾，4G用戶移動(dòng)造成的信號(hào)不穩(wěn)定，擁塞，運(yùn)營(yíng)商帶寬限速，造成丟包、擁塞、延時(shí)抖動(dòng)，以及各種復(fù)合狀況。

現(xiàn)有Qos策略的弊端

對(duì)抗丟包，WebRTC的Qos策略有，音頻RED、NACK，F(xiàn)EC，PLI，F(xiàn)IR，這些策略再某些情景下能發(fā)揮很好的作用，例如：

NACK：延時(shí)低，帶寬夠，少量隨機(jī)的丟包

FEC：冗余帶寬夠，低于FEC算法能力上限的丟包

PLI（Picture Lost Indication）：帶寬夠，延時(shí)低，超過NACK上限的大量丟包，或者SPS參數(shù)解析失敗

FIR（Full Intra Request）：切換視頻源，用用戶加入多人會(huì)議，需要同學(xué)各方發(fā)送key frame。Intra是指幀內(nèi)編碼，而不是需要依賴其它幀的inter frame B或P幀。

同時(shí)，在某些情景下，上述的策略會(huì)失效，或加劇問題。

NACK： 延時(shí)較大，例如傳輸延時(shí)200ms+NACK消息返回200ms+RTP重傳200ms，重傳之后延時(shí)增大到600ms，緩存隊(duì)列增大。重傳的流量，也可能加速帶寬消耗，擁塞惡化。

PLI：由于key frame較大，重傳I幀會(huì)加劇帶寬消耗。

FEC：因帶寬有限，F(xiàn)EC冗余占用了寶貴的帶寬

阿里GRTN的Qos策略

簡(jiǎn)單高效的Qos優(yōu)化策略

? Qos優(yōu)化可以無極限的追求，對(duì)于研發(fā)實(shí)力薄弱的小公司，在Qos優(yōu)化的巨坑里面，如何簡(jiǎn)單高效的取得成果呢？

1，音頻流的動(dòng)態(tài)RED冗余

? ? 連續(xù)的音頻是重要的用戶體驗(yàn)，流的碼率小，常用語音碼率為20kbps~60kbps?。音頻RED的原理，就是將碼流冗余發(fā)送，例如30kbps，冗余發(fā)送1份就是60kbps，RED發(fā)送2份就是90kbps。這樣在丟包率50%情況下，用戶仍然能聽到連續(xù)的音頻，實(shí)現(xiàn)增強(qiáng)用戶Qos體驗(yàn)。

2、視頻LTR

對(duì)于靜態(tài)畫面，LTR能顯著抵抗丟包畫質(zhì)，減少I幀請(qǐng)求。

如何實(shí)現(xiàn)？