在Google Chrome WebRTC中分層蛋糕式的VP9 SVC

來自專欄 即構科技Zego實時語音視頻技術專欄

作者 / Sergio Garcia Murillo,Gustavo Garcia

編輯 / Chad Hart

翻譯 / 小極狗

多方呼叫架構是一個常見的話題，主要是因為多方呼叫很難實現和理解，卻同時被廣泛需要。絕大多數的人都認為可伸縮視頻編碼（SVC）是最先進的，而多方呼叫架構卻是最複雜的。

為了理解它是如何工作的，兩個WebRTC視頻架構專家：Sergio Garcia Murillo是資深的媒體伺服器開發人員，同時還是Medooze的創始人。和這個話題直接相關，他最近正在利用VP9和SVC開發開源SFU項目；另外，知名視頻專家Gustavo Garcia Bernando也會加入進來。

下面，我們一起來看看在Google Chrome瀏覽器的WebRTC實現中複雜的技術和還未記錄在案的特點（功能）。拿出小本本做好筆記！

如何針對具有不同能力的參與者來調整視頻比特率一直是WebRTC多方呼叫解決方案面臨的挑戰之一。傳統的解決方案基於多點控制單元（MCU）模型。針對具有不同質量、解析度和幀率的參與者，MCU的轉碼（完全解碼流然後重新編碼）分別提供了不同版本的流。

其後，基於轉發數據包而不進行任何重新編碼的選擇性轉發單元（SFU）模型開始變得非常流行。主要是因為其可擴展性同時還有相對便宜的伺服器端架構，導致SFU在WebRTC中特別受歡迎。在過去幾年中，Chrome 瀏覽器對同時聯播和時間可擴展性提供了非官方支持——VP8壓縮編解碼器，這也是實現WebRTC SFU的最佳方式之一。同時聯播要求端點能夠發送兩到三個具有不同解析度、質量的相同的流，以便SFU伺服器可以轉發到每個目的地。幸運的是，在Chrome中啟用同時播報功能時，您將自動獲得對時間伸縮性的支持（如下所述）。這意味著SFU還可以根據可獲得的帶寬有選擇地轉發不同幀質量的數據包。

然而，同時聯播確實存在一些缺點，它需要額外的獨立編碼流，導致了額外的帶寬開銷和CPU佔用。

有什麼更好的選擇嗎？當然有，可伸縮視頻編碼（SVC）就是一種更為複雜的方法，但它可以在保持SFU模型優點的同時將這種額外的開銷降至最低。

什麼是SVC？

可伸縮視頻編碼（SVC）是指在相同比特流內產生若干編碼層的編解碼器能力。SVC並不是一個新的概念，它最初是作為H264 / MPEG-4的一部分引入的，後來在2005年被標準化了。不同於發送具有冗餘信息和分組開銷的多個流的同時聯播，SVC旨在通過對單個比特流進行分層編碼以提供更高效的實現。使用單一流和新穎的編碼方法在提供輕量級視頻路由架構的同時，還有助於降低網路帶寬消耗和客戶端CPU編碼成本。

三個圖層類型

有三種不同的層次：

時間 - 不同的幀速率。

空間 - 不同的圖像大小

質量 - 不同的編碼質量。

VP9支持將質量圖層作為空間圖層，而解析度不會發生任何變化，因此從現在開始我們將只需要關注空間和時間層。

SVC層結構決定了編碼層之間的依賴關係。這樣，在選擇某個圖層並在編碼之後刪除所有其他非依賴圖層時，也不會影響生成的流的可解碼性。

在VP9中，每個層用一個整數ID定義（從0開始）。ID較高的圖層依賴於較低的圖層。

編碼和SFU選擇

VP9 SVC為每個編碼的圖像幀生成一個「超幀」。超幀由屬於單個時間和空間層的「層幀」組成。當通過RTP發送VP9 SVC時，每個超幀都會隨著單個RTP幀中一起發送，在每個RTP包中都有額外的有效載荷描述，允許SFU提取各個層幀。這樣，SFU可以選擇當前空間和時間層中所需的一個。

控制帶寬

SFU可以在任何給定的全幀層下壓縮（在時間上和空間上）。它只能在有效載荷描述表頭上進行拓展升級。

降低時間層的尺寸會導致每秒解碼幀數（FPS）的下降。對空間層進行縮小會降低解碼圖像的尺寸。放大將提供相反的效果。

Chrome中VP9 SVC的狀態

目前，VP9 SVC僅在標準Chrome瀏覽器中允許使用。但是，對於任何編碼流（至少從M57開始），VP9 SVC都可以使用命令行參數現場調試啟用：

啟用後，Chrome將SVC編碼它發送的每個VP9流。通過上述設置，VP9編碼器將產生2個空間層（size 和 size/2）和3個時間層（FPS，FPS / 2和FPS / 4），而且沒有質量層。舉例來說，如果以30 FPS對尺寸為640×480的VGA圖像進行編碼，則可以在以下解析度和幀率之間選擇：

VP9有效載荷格式

每個攜帶VP9流的RTP包僅含有來自同一個層幀的數據。每個數據包也以VP9有效載荷描述開始。該有效載荷的描述向SFU提供了關於層幀依賴性和可伸縮性結構的提示。

模式

目前，Chrome Canary（58）提供VP9 SVC的兩種有效載荷格式：

1.靈活模式 - 提供了動態改變時間層次結構和模式的能力。在每個有效載荷描述表頭上都提供了每個層幀的參考幀。此模式目前僅用於屏幕共享。

2.非靈活模式 - 在有效載荷描述的可伸縮性結構中指定了幀組（GOF）內的每個幀的參考幀，直到發送新的可伸縮性結構前，它們都是固定不變的。這是目前用於實時視頻的模式。

結構體

在非靈活模式下，Chrome Canary實時視頻所使用層幀依賴關係中，實際的可拓展性結構：

解碼器需要獲得依賴幀，以分辨幀是「可解碼的」還是在不給定時接收的幀。

依賴性描述

幸運的是，有效載荷描述還為SFU提供提示，根據所決定發送到每個端點的期望的時間和空間層，來決定哪些幀可能被丟棄。我們需要檢查的有效載荷描述的主要位置是：

• P ：圖片間預測圖層幀，指定當前圖層幀是否依賴於同一空間層的先前圖層幀。
• D ：使用層間依賴性，其指定當前層幀是否取決於來自當前超幀內緊接的前一空間層的層幀。
• U ：切換點，其指定當前層幀是否依賴於同一時間層的先前層幀。

當S位被設置為0時，我們可以在層幀上設置較高的時間層，因為後面的更高時間層幀將不再依賴於任何比當前層更高的時間層的先前層幀。當層幀不利用圖片間預測時（P位被設置為0），可以從直接較低的空間層幀向上切換到當前空間層的幀。

依賴模型

現在我們來看看如何從最近的Chrome Canary捕獲中獲得實際的VP9 SVC編碼流。對於RTP流的每個幀，我們已經解碼了有效載荷描述並提取了代表性比特位，並使用可伸縮性結構來描述層幀依賴性。

如圖所示：

T表示時間層。 S表示空間層。 S0和 T0是基礎層。超幀1到4包括一組幀，同樣5到8也是一組幀。 可以看出，空間層 S1的每個層幀依賴於同一超幀的S0層幀。另外，很顯然， 每個可伸縮性組的第二個T2幀不可縮放，因為它取決於先前的 T2和 T1幀。

選擇性轉發的例子

使用這個模型，我們來看看給定幀是如何選擇圖層。

縮小規模

我們將超幀2中（紅色部分）T2 S1層幀縮小到T1 S1層幀中，結果是大小沒有改變，但FPS按預期減半：

在相同的圖層框架下，我們還可以進一步縮小到T1 S0，結果是圖像尺寸減小（寬度和高度減半），FPS也減半：

倍增

為了時間上升，SFU應該等待具有切換點標誌的層幀被啟用（U比特位被設置為1）。在非靈活模式下，根據可伸縮性結構周期性地發生。SFU需要等待一個不是幀間圖像預測的層幀（P比特位設置為0），然後才能進行空間的放大。

通過發送RTCP反饋層刷新請求（LRR）消息 或者由圖像丟失指示符（PLI）/全幀內請求（FIR）來發送，是SFU能夠強制編碼器產生非幀間圖像預測層幀的一種方式。在我們的RTP示例流中，我們必須等到第68幀才能看到它。這恰好是由幀67和68之間的FIR發起的。空間層 S0 不依賴於先前的時間層 T0，所以在那之後可擴展性結構可以用新的幀組重新開始。

所以在之前的VP9流中，SFU能夠在空間上讓幀68進行倍增，在時間上讓幀73進行倍增。

少了什麼東西

目前，通過傳遞命令行標誌並自動獲取2個空間層加上3個時間層（如上所示），可以在Chrome中啟用VP9 SVC（包括穩定版）。如果谷歌要將VP9 SVC設為默認選項，至少還有四個方面的問題亟待解決：

1. 當啟用VP9 SVC時，如何確定時間層和空間層的最佳組合，或者可以提供一個API來配置（但可能需要部分尚未提供的新ORTC類API）。
2. 提供一種能夠在每個會話中啟用或禁用SVC的方法，因此可以使用SVC或者1：1使用傳統VP9方式來進行多方呼叫，以避免SVC編碼的開銷。
3. 雜訊消除被禁用（通過模糊幀以消除缺陷），在VP9中還不是默認啟用。
4. 使用VP9 SVC時的CPU使用率仍然非常高 - 在中高端設備上，檢測CPU過度使用和縮減發送的解析度需要一些時間。

結果/演示

如上所述，使用SVC編解碼器的主要目標是能夠生成不同版本的流，而不必對其進行轉碼。這意味著我們需要生成許多不同碼率的流版本，以適應參與者不斷變化的帶寬。

在下圖中，我們以2Mbps的速度使用VP9 SVC發送同一個流。通過上面的 2SL3TL配置，我們可以通過選擇不同的時間和空間層來生成6個不同的版本。最底層版本（1/4解析度的1/4幀速率）大約為250kbps，而其他層次則大約相差200kbps。

您可以使用新的開源Medooze SFU進行測試，或者聯繫TokBox獲取有關其VP9 SVC支持的更多信息。

Medooze提供了一個可以測試VP9圖層選擇的Demo演示，

地址：https：//http://sfu.medooze.com/svc/

注意：需要在Chrome上啟用SVC才能正常工作！

關於即構ZEGO

即構科技於2015年由QQ前總經理林友堯創立，A輪獲得IDG投資，核心團隊來自騰訊QQ，匯聚了來自YY和華為等廠商的頂尖語音視頻人才。即構ZEGO致力於提供全球最清晰最穩定的實時語音視頻雲服務，助力企業業務創新，改變用戶線上溝通方式。即構ZEGO深耕視頻直播、視頻社交、遊戲語音、線上抓娃娃和在線教育等領域，贏得了映客、花椒直播、一直播、喜馬拉雅FM、陌陌遊戲、自由之戰2、和好未來等頂級廠商託付和信賴。

推薦閱讀：