WebRTC QOS概念簡述

webrtc用於提升QOS的方法有:
NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR(動態幀率調整策略)。

帶寬預測 or REMB Sender Side BWE

1. RTCP: transport cc
  • Delay Based Control 基於延時的策略
  • Loss Based Control 基於丟包的策略
    ----帶寬預測爲Over use 後,sender自己更新碼率.
  • 優點:sender 在於無需依賴於兩個端點
  • 缺點在於浪費了一定的帶寬,同時Firefox目前還不支持
2. REMB
  • 增加abs-send-time 在擴展頭
  • REMB的優點在於碼率的控制權在服務端(接收端),沒有額外的帶寬浪費。
  • 在採用TCC方案後,接收端也可以利用REMB來通知發送端碼率發送上限。
  • GCC

NACK 丟包重傳

  • RTP Retransmission(NACK) 報文丟失重傳RTPFB (205)
    How to build NACK feedback, dependent on Video Jitter Buffer Status.
  • PLI/SLI/RPSI 指定淨荷重傳 PSFB(視頻幀丟失重傳、slice丟失重轉、參考幀丟失重傳)

FEC 前向糾錯

FEC是發送端在發送報文的時候,將之前的舊包也打包到新包裏面,若接收端有丟包,就用新包裏面冗餘的舊包恢復數據。

webrtc實現該冗餘功能,有三種方式:

  • RED就是RFC2198冗餘。將前面的報文直接打入到新包裏面,在接收端解析主包和冗餘包。

  • ULPFEC,目前webrtc僅將SVC編碼的Level 0視頻幀打包成FEC。其餘層有丟包,就逐步將幀率,保證視頻相對流暢。用到的協議是:RFC5109。

  • FLEXFEC根據接收端反饋回來的丟包信息,總結一些規律,把預判丟失概率比較大的包,冗餘打包出去。

[SVC] Scalable Video Coding

VP9/openH264 支持SVC,通過改變一個GOP內幀的線性參考關係。防止網絡丟包對視頻傳輸造成的影響

JitterBuffer 防抖動buffer

JitterBuffer實現原理是,在收到網絡上的RTP報文後,不直接進行解碼,需要緩存一定個數的RTP報文,按照時間戳或者seq的順序進行重排,消除報文的亂序和抖動問題。JitterBuffer分動態JitterBuffer和靜態JitterBuffer兩種模式。靜態JitterBuffer緩存報文個數固定。動態JitterBuffer是根據網絡環路延時的情況,動態調整緩存報文個數。

IDR Request 關鍵幀請求

關鍵幀也叫做即時刷新幀,簡稱IDR幀。對視頻來說,IDR幀的解碼無需參考之前的幀,因此在丟包嚴重時可以通過發送關鍵幀請求進行畫面的恢復,當會議中有新的訂閱的時候也需要publisher重新發送關鍵幀。關鍵幀的請求方式分爲三種:RTCP FIR反饋(Full intra frame request)、RTCP PLI 反饋(Picture Loss Indictor)或SIP Info消息,具體使用哪種可通過協商確定

PACER

pacer 是wenrtc的一種平滑發包策略,防止一幀數據把網絡壓垮,pacer會根據獲取的擁塞情況進行改變發包間隔,pacer肯定會引起延遲,但延遲不嚴重,pacer有幾個關鍵技術:pace queue、padding、budget,詳情請看: https://yq.aliyun.com/articles/606053, webrtc中的PacerSender :https://www.jianshu.com/p/3fde9b8d77f6

VFR(動態幀率調整策略)

WebRTC幀率調整策略

Reference

https://www.jianshu.com/u/102fafe8c6b9 weizhenwei的簡書
** http://ec.ctiforum.com/jishu/qiye/wenzhai/535765.html WebRTC的擁塞控制和帶寬策略 袁榮喜

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章