WebRTC頻寬估計__webrtc

作者：Gustavo Garcia（原文連結）

翻譯：劉通

 

         頻寬估計可能是WebRTC視頻引擎中最重要的一部分了。頻寬估計（BWE）模組的任務是決定你可以發送多大的視頻流且不會造成網路擁塞，以此來保證不會降低視頻品質。

         在以前的頻寬估計演算法還是十分基礎的，大體上是基於丟包而設計的。通常我們在開始慢慢的增加視頻的位元速率，直到我們檢測到丟包為止。為了檢測丟包，你使用標準的RTCP反饋，其中接收端使用RTCP接收端報告（RR）資訊來周期性的報告丟包。

         現在的頻寬估計演算法變得更加先進，嘗試在擁塞嚴重到了路由器開始丟棄資料包之前就檢測出來。這些演算法通過分析資料包之間的延時來預測擁塞情況。想法是當你開始遇到擁塞時，資料會開始流入路由器中的緩衝區，延時也會變得更多樣。這些演算法中比較出名的幾種是Google Congestion Control（就是WebRTC中用的），SCReAM以及SPROUT。如果你想要瞭解更多有關擁塞控制標準的曆史發展和現狀，你可以看一下Randell Jesup寫的這篇很有趣的博文。

         從WebRTC的最初級階段開始，媒體引擎（由Google搭建，但是Firefox和Chrome都在使用）就是基於遠端頻寬估計理論而搭建的。正像我之前說的那樣，接收端會分析包間延時，並且會對可用頻寬產生一個估計值，然後使用RTCP資訊報回給發送端，其中RTCP資訊使用了一種被設計來完成這項工作的資訊類型：REMB。另一個關於WebRTC實現的細節是，發送端不會只使用這個在REMB包中接收的頻寬估計值，也會使用反饋的丟包來決定最終發送的目標視頻位元速率。

         這個實現的好處是它可以在檢測到使用過度的時候迅速的降低位元速率，即使此刻還沒有探測到擁塞的時候。

         但是在最近版本的Chrome中這點發生了改變，現在頻寬估計的所有的邏輯都是發生在發送端。擁塞的基本檢測跟以前沒有什麼大的差別，且發送端需要從接收端傳來的延時資訊來估計可用的頻寬。這是用兩個全新的機制/協議來完成的：

         #1 傳輸寬序號的前序擴充：所有視頻RTP資料包都在前序處有額外的4位來包含一個序號。這是通過下面語句與SDP協商得來：

         注意：這種新的序號的思想是可以對音頻和視頻只使用一個計數器，但是Chrome還沒有將其在音頻領域中使用，所以我認為它現在還並不是很有用。

         #2 傳輸反饋：接收端會周期性地將包含有關已接收資料包和包間延時的資訊反饋給發送端。為了完成這項工作，接收端使用了新的RTCP包（傳輸反饋）。這是通過下面這條包括了新RTCP反饋資訊的語句在SDP中協商得來：

         當你在觀察這些傳輸反饋資料包是什麼樣子的時候，有意思的是你會意識到其中有Google建議的規範，以及官方標準化方案，但是真正使用的是在源碼之中的實際實現。

         這個RTCP反饋預設100ms發送一次，但是實際上是動態適應的，只會使用5%的可用頻寬（最小值是50ms，最大值是250ms）。

         為了將大小控制在最小，這種新的RTCP包的格式十分簡潔，包括塊內的分組包，以base+diff的形式儲存數字，或者將粒度降低到0.25ms為間隔。我做了一個簡單的測試，有了這些改進方案，其依舊會使用16Kbps來每50ms發送一次反饋資料包。

       

         你可以在remote_estimator_proxy.h以及transport_feedback.cc中查看相關實現。

        

         發送端頻寬估計的好處是什麼。Google給出的解釋是，這樣做的話，所有的決定邏輯都會在一個地方（發送端），而且這會讓測試新演算法變得更簡單，因為你不需要同時取決於兩個端點。說實話，由於瀏覽器的自動更新，我看不出來這點改變可以帶來什麼大的好處，但是其確實更加的整潔，即便會在頻寬使用方面更貴一點。另一項好處是，發送端可以知道自己所發送的資料流是什麼類型的，也可以在發送普通視頻，而不是做例如螢幕廣播這種事情的時候使用不同的演算法。

         我們會受到實際影響嗎。如果你搭建了一個需要進行頻寬估計的媒體伺服器，在某種程度上你需要更新你的實現。好訊息是Chrome還會支援舊機制（REMB）一段時間，至少會持續到Firefox支援它之後。但是REMB可能不會再有新的進展了，而且現在出現bug的可能性會更高，所以我認為延遲更新太久並不是一個好主意。

         發送端頻寬估計真的就更好嗎。我做了一個快速的測試（這是測試頁面，你可以嘗試一種，或者通過改變布爾值來進行別的測試），其中在Chrome中同時用了兩種演算法（老的REMB和新的傳輸反饋），其中新演算法的表現要好的多，至少在串連開始階段的上升部分要好的多。我不認為對於這種結果，除了Google現在全新投入在新演算法中，而不管老演算法，且所有的趕緊都只會發生在新演算法中，這個原因以外還存在著什麼技術上的解釋。很顯然在新演算法中，頭兩秒內肯定是有什麼特殊的方法來處理頻寬估計，但是我也沒有太深入的研究。

         現在什麼人在做這件事情，以及現況是什麼。發送端頻寬估計是Chrome55版本中預設使用的演算法，但是其還在開發過程中，所以我們應該做好還有很多改變的預期。官方的標準化工作在RMCAT工作群組 IETF中進行，但是現在Chrome中大多數的可用實現都是Google自己的版本，都是Google自己的在建演算法和反饋協議的規範。

 

*Chrome打算也在決定發送的音頻位元速率上使用頻寬估計演算法（計劃在58版本中加入）。