WebRTC SFU中發送數據包丟失反饋

WebRTC SFU的職責之一是接收和發送RTCP數據包。RTCP數據包包括關於音頻和視頻流的不一樣類型的反饋，而且最重要的RTCP數據包是接收器報告(RR).

RR數據包從媒體流接收器發送到該媒體流的發送者。在SFU的狀況下，RR由SFU產生，併發送到媒體流發送器，而且還從每一個流接收器發送到SFU。(如圖1)。

RR數據包內發送的反饋包括用於計算網絡引入的往返時間延遲，抖動和信息丟失。

這些RR數據包中報告的數據包丟失很重要，由於發送的音頻和視頻將根據該參數進行調整：

在音頻流的狀況下，網絡中的數據丟失修改了OPUS編解碼器的強度級別。在存在不少數據丟失的狀況下，發送器增長包括在音頻分組中的前向糾錯(FEC)的冗餘級別。 在視頻流的狀況下，數據丟失修改編碼和發送的視頻比特率。在存在大量數據丟失的狀況下，發送方下降發送比特率以減小網絡中可能的擁塞。 基於該行爲，問題是……SFU如何計算從SFU發送到發送方的RR報文中報告的丟包，以得到最佳用戶體驗？

在接下來的部分，您能夠找到有關如何在三種不一樣類型流中處理此問題的建議:音頻，帶有聯播的視頻，和沒有聯播的視頻。

音頻

Opus FEC是帶內發送的，由於FEC是端到端的(不能在SFU中添加/更新)，而且會議室中的每一個人將得到相同等級的FEC。

若是咱們但願音頻FEC可以很好地爲具備最弱連接的參與者工做，那麼咱們必須確保向發送方報告最糟糕的數據包丟失。

所以，從SFU向發送方報告的丟包應該是接收方的較差分組(max(PL1, PL2)).

例如，若是其中一個接收參與者在下行鏈路中遇到20%的數據丟失，則報告給發送方的數據丟失將會是20%,即便發送方和其他接收方處於完美的網絡狀態。

帶有聯播的視頻

使用聯播時，SFU可以向每一個參與者發送不一樣的視頻質量，所以不須要使發送流適應任何特定參與者。

所以，從SFU向發送方報告的丟包應該是該鏈路(發送方-SFU)的丟包，不管收到的丟包是什麼，對於接收方1和2都是如此。

例如，若是發送方上行鏈路良好，即便接收方在下行鏈路中遇到大量丟包，報告給發送方的丟包也將爲0.經過選擇要轉發給那些參與者的較低分辨率/層，能夠經過在SFU中完成的從新傳輸和比特率自適應來糾正這一點。

無聯播的視頻

無聯播時，SFU必須向每一個參與者發送相同的視頻質量。所以，發送者使用最弱的連接調整發送比特率併發送給參與者(和/或禁用某些參與者的視頻)。

該比特率自適應主要由REMB RTCP數據控制，其中SFU包括在較差接收器中可用的帶寬。可是丟包也會對REMB數據包中報告的比特率產生影響，所以咱們須要肯定要在RR數據包中包含哪些數據包丟失。

在這種狀況下，我認爲前面幾節中描述的兩種方法均可以很好的工做。或者a)SFU報告最差的接收器的丟包率，或者b)使用每一個接收器的丟包估其帶寬，並僅報告RR數據包中的發送方一側丟包。

注意：若是您在房間中有2個參與者時使用P2P鏈接，而且當房間中有3個或更多參與者時，切換到具備聯播的SFU，那麼你應該從不在此視頻中使用No-Simulcast和多個參與者案例。

本文首發於由聲網 Agora 贊助運營的 WebRTC 中文網