本文來自Jitsi Videobridge SFU的后端開發(fā)人員之一Brian Baldino，他過去在思科和Highfive工作過，擁有豐富的視頻會議產(chǎn)品研發(fā)經(jīng)驗(yàn)。他分享了在Jitsi實(shí)現(xiàn)自動(dòng)減少轉(zhuǎn)發(fā)視頻層，從而降低客戶端CPU和帶寬使用。

對高流量的流控制（來源：usbr.gov）

大多數(shù)人可能都熟悉典型的SFU風(fēng)格的用戶界面，該界面最初是在Google Hangouts的消費(fèi)者市場中推廣的，并由Jitsi Meet和其他服務(wù)部門使用。絕大多數(shù)屏幕空間的正面和中心是當(dāng)前活躍的演講者的視頻。所有其他參與者都可以在他們自己的縮略圖中看到，通常在右側(cè)或底部。我們想讓活躍的演講者的視頻在中間看起來很棒，因此分辨率很高。底部/右側(cè)的縮略圖會很小，因此高分辨率會浪費(fèi)帶寬。為了優(yōu)化這些不同的模式，我們需要每個(gè)發(fā)送者視頻的多個(gè)分辨率。值得慶幸的是，這已經(jīng)是一個(gè)用聯(lián)播解決了的問題！

通過聯(lián)播，所有發(fā)送者編碼3種不同的分辨率并將其發(fā)送到SFU。SFU決定將哪些流轉(zhuǎn)發(fā)到每個(gè)接收器。如果參與者是活躍的發(fā)言者，我們會嘗試并將他們發(fā)送給其他人的最高質(zhì)量的流轉(zhuǎn)發(fā)到他們的主界面上。如果要在右側(cè)的縮略圖中看到參與者，那么我們就會轉(zhuǎn)發(fā)他們的最低質(zhì)量的流。

聯(lián)播權(quán)衡

聯(lián)播是優(yōu)化下載帶寬的絕佳機(jī)制。然而，與生活中的大多數(shù)事情一樣，聯(lián)播涉及權(quán)衡——編碼3個(gè)流比編碼單個(gè)流需要占用更多CPU。您可以在下面的chrome：// webrtc-internals統(tǒng)計(jì)信息中看到這一點(diǎn)，其中使用聯(lián)播的CPU使用率提高了幾個(gè)百分點(diǎn)：

沒有聯(lián)播的CPU使用率

使用聯(lián)播的CPU使用率

它還涉及發(fā)送更多比特?cái)?shù)：

在沒有使用聯(lián)播時(shí)的發(fā)送比特率（~2,5M比特/秒）

使用聯(lián)播時(shí)的發(fā)送比特率?（3M比特/秒）

這些圖表是由chrome：// webrtc-internals自動(dòng)縮放的，因此請注意y軸刻度可能不同。請查看實(shí)際的y軸值。

流暫停

那么這是否意味著聯(lián)播對用戶來說效率較低呢？相反，由于我們可以單獨(dú)控制聯(lián)播的流，因此聯(lián)播使我們有機(jī)會通過關(guān)閉不使用的層來節(jié)省CPU和比特?cái)?shù)。如果你不是活躍的發(fā)言者，則根本不需要3層中的2層！

讓我們看看當(dāng)我們關(guān)閉前2層時(shí)的使用率：

CPU使用率

沒有使用聯(lián)播的CPU使用率基線

具有3個(gè)聯(lián)播流的CPU使用率

禁用前兩個(gè)層的聯(lián)播的CPU使用率

每秒比特?cái)?shù)

沒有使用聯(lián)播的發(fā)送比特率基線

使用3個(gè)聯(lián)播流的比特率

禁用前兩個(gè)層的聯(lián)播的比特率

對于客戶端和SFU上的負(fù)載來說，這是一個(gè)巨大的勝利！

實(shí)施暫停

現(xiàn)在讓我們看看我們是否可以將其集成到實(shí)際代碼中。這里有兩個(gè)問題需要解決：

1.在SFU上——弄清楚何時(shí)沒有使用流并讓客戶知道

2.在客戶端——在不使用流時(shí)關(guān)閉流，并在需要時(shí)再次啟動(dòng)它們

SFU

第一個(gè)問題很容易解決——當(dāng)客戶成為活躍的發(fā)言人時(shí)，客戶端會明確地請求參與者提供高質(zhì)量的流，這樣我們就可以告訴發(fā)送者何時(shí)使用高質(zhì)量的流以及何時(shí)不通過數(shù)據(jù)消息通道。

客戶端

第一次嘗試

我們也想到了第二個(gè)問題。我們知道Chrome會在可用帶寬下降時(shí)暫停聯(lián)播流的傳輸，那么如果我們只限制可用帶寬會發(fā)生什么呢？我們可以通過在遠(yuǎn)程SDP中設(shè)置帶寬限制來實(shí)現(xiàn)此目的：

使用SDP限制最大發(fā)送帶寬

在 b = AS 的那一行將可用帶寬限制到200kbps。讓我們試一試，看看會是什么樣子：

SDP限制帶寬后的CPU使用率

SDP限制帶寬后的發(fā)送比特率

太棒了！這正是我們所希望的：它與我們之前的測試結(jié)果相匹配！現(xiàn)在讓我們移除上限以模擬某個(gè)人成為活躍的發(fā)言者并且我們想要他們的高質(zhì)量流：

移除上限的CPU使用率

移除上限的發(fā)送比特率

移除上限的發(fā)送幀的高度

話說回來，還有一個(gè)問題......整個(gè)過程需要30秒才能恢復(fù)到高質(zhì)量。這意味著當(dāng)某人成為活躍發(fā)言人時(shí)，他們在主舞臺上的低視頻質(zhì)量將至少持續(xù)30秒。這不行，那么為什么這么慢呢？

如果你曾經(jīng)使用Chrome進(jìn)行過網(wǎng)絡(luò)損傷測試，那么你知道它會應(yīng)用大量邏輯來防止監(jiān)控。由于擔(dān)心丟失數(shù)據(jù)包，因此提高發(fā)送比特率是非常謹(jǐn)慎的。我們基本上通過我們的SDP參數(shù)完成的工作是讓Chrome認(rèn)為網(wǎng)絡(luò)的數(shù)據(jù)包容量非常低（200 kbps），因此當(dāng)我們刪除它時(shí)，Chrome會小心地提高比特率，同時(shí)計(jì)算實(shí)際發(fā)送的數(shù)量。當(dāng)網(wǎng)絡(luò)出現(xiàn)問題時(shí)，這很有意義，但對于我們的用例，這是一個(gè)阻礙因素。

Google Meet測試

我們注意到當(dāng)Google Meet正在使用時(shí)，我們首先開始討論聯(lián)播流暫停。我們來看看Google Meet電話會議的圖表：

Google Meet上的CPU使用率上升

Google Meet上的發(fā)送比特率上升

Google Meet上的發(fā)送幀的高度

哇！它們下降并且非常快速地增加。他們是如何做到的呢？我們看了他們的SDP，他們正在使用b = AS上限。我們知道這不會讓我們快速上升（正如我們在第一次嘗試中看到的那樣），所以他們肯定還做了其他事情。

我們看了一下chrome：// webrtc-internals并注意到了這一點(diǎn)：

使用webrtc-internals調(diào)查Google Meet

這個(gè)addStream可能看起來沒有什么作用，但它不是在調(diào)用的開始，它在中間的位置，當(dāng)我們希望流恢復(fù)時(shí)，那么這里發(fā)生了什么呢？正在添加另一個(gè)視頻流，但沒有一個(gè)被刪除，這是如何工作的呢？它與比特率快速上升有關(guān)嗎？

所以我們仔細(xì)看了一下，發(fā)現(xiàn)了一些細(xì)節(jié)。這是參與者首先將其媒體流添加到 peerConnection的位置：

以下是當(dāng)我們想要提高比特率時(shí)的addStream：

所以我們在這里可以看到軌道ID是相同的但是流ID是不同的。這讓我們想起了Chrome如何為新創(chuàng)建的流提供一個(gè)免費(fèi)的時(shí)間段，其比特率可以很快提升; 這樣，當(dāng)你加入通話時(shí)，你可以快速開始發(fā)送高清視頻。我們懷疑，新流的自由上升期是這里所利用的，當(dāng)參與者成為活躍的演講者時(shí)，讓流看起來是新的。

嘗試2

根據(jù)對Meet的調(diào)查，我們開始使用獨(dú)立的WebRTC演示應(yīng)用程序嘗試重現(xiàn)其中的行為。通過這樣做，我們能夠在我們的測試環(huán)境中重現(xiàn)相同的行為：

復(fù)制媒體流

將復(fù)制的媒體流添加到對等連接

Munge SDP從新流中刪除新的ssrcs / stream信息并將其替換為原始信息。

但我們還沒有在實(shí)際的Jitsi調(diào)用中嘗試它，測試環(huán)境是點(diǎn)對點(diǎn)的，并沒有使用聯(lián)播，所以我們不確定它能移植到Jitsi并工作。曾經(jīng)我們嘗試或，我們發(fā)現(xiàn)我們沒有得到快速上升。它很慢，就像以前一樣只有帶寬上限。我們開始對此進(jìn)行調(diào)試，并認(rèn)為它可能與我們在SFU上的速率控制中的某些因素有關(guān)，這會阻止比特率快速上升。

在我們進(jìn)一步發(fā)展之前，出現(xiàn)了一種新的可能性。

嘗試3

WebRTC團(tuán)隊(duì)最近推出了關(guān)于RTCRtpSender的PSA。支持修改登陸Chrome 69的編碼參數(shù)。這有一個(gè)API，可讓我們控制各個(gè)聯(lián)播編碼，包括它們是否已啟用！所以，當(dāng)我們發(fā)現(xiàn)我們不能進(jìn)入主界面時(shí)，客戶端可以這樣做：

應(yīng)該禁用前2層，讓我們看看它的表現(xiàn)：

CPU通過RtpSender參數(shù)丟棄沒有使用的層

通過RtpSender參數(shù)丟棄沒有使用層的發(fā)送比特率

我們沒有像以前那樣下降，但它仍然是一個(gè)很大的進(jìn)步！但是，讓我們看看當(dāng)我們重啟它們時(shí)如何提升：

CPU使用率上升

發(fā)送比特率上升

發(fā)送幀高度上升

哇！比特率立即上升了！這將完全適用于有源揚(yáng)聲器切換。我們不會在Chrome 69之前獲得此功能，但它是一個(gè)好的解決方案，并為我們提供了我們想要的東西：當(dāng)流不使用時(shí)快速降低比特率，并在我們再次需要時(shí)快速恢復(fù)。

今天就試試看Jitsi Meet，將＃config.enableLayerSuspension = true添加到你的URL（只要你使用Chrome v69 +）或查看Jitsi Github中代碼。