我想知道這條SDP線路的含義是什麼，因爲我試圖獲得5％至10％數據包丟失的最平滑幀率。WebRTC'goog-remb'和'transport-cc'SDP lines
我知道鴕鳥政策的線是： 一個= RTCP-FB：100 goog-remb 一個= RTCP-FB：100運輸-CC
我不知道爲什麼火狐（例如）正在移除「transport-cc」功能，即使我不得不解碼不完整的視頻幀，我是否還想讓流幀率保持平滑？
最好成績的問候，我希望有人能幫助我在這:)
古斯塔沃·加西亞寫了一篇博客文章關於這家名爲Bandwidth Estimation in WebRTC (and the new Sender Side BWE)。
總結：goog-remb和運輸-CC均爲擁塞控制機制，goog-remb爲一個較舊的方法和trasnport-cc是一個較新的方法。
我最好的猜測是，Firefox是剔除運輸-CC因爲Firefox有沒有采用運輸-CC尚未變化。根據我的經驗，Chrome瀏覽器在webrtc更改中始終領先於Firefox。
在有損網絡中，這些擁塞控制算法可以告訴發送方降低發送比特率。降低發送比特率可以減少損失（以質量爲代價）。但是，如果網絡總是有10％的損耗，就像嘈雜的WiFi網絡一樣，您仍然可能會遭遇視頻幀解碼問題。
處理視頻解碼失敗是vp8/h264視頻編碼參數的一個功能，而不是擁塞控制。正如我所說的，擁塞控制可能有助於減少丟失（如果您使用WebRTC數據包壓倒了您的網絡），但是如果您只是有損網絡（例如，較差的無線網絡），擁塞控制算法將會降低質量而不會改善解碼失敗。