聲網(wǎng)Agora 開發(fā)者社區(qū)聯(lián)合 InfoQ 共同策劃，邀請了聲網(wǎng)Agora 開發(fā)者社區(qū)中的多位技術(shù)專家，從視頻傳輸、計算機視覺、編解碼標準發(fā)展、WebRTC、機器學習、音頻技術(shù)等角度，共同撰寫「2021 實時互動技術(shù)展望系列」，一窺技術(shù)新趨勢。本系列內(nèi)容由聲網(wǎng) Agora 開發(fā)者社區(qū) 與 InfoQ 聯(lián)合策劃，并由 InfoQ 審校，首發(fā)于 InfoQ。
2020 年，WebRTC 發(fā)生了很多變化。WebRTC 其實就是一個客戶端庫。大家都知道它是開源的。盡管 Google 大力地在支持 WebRTC，但社區(qū)的力量同樣功不可沒。
WebRTC 對于桌面平臺、瀏覽器端實現(xiàn)音視頻交互來講十分重要。因為在你可以再瀏覽器上運行任何一種服務，并進行安全檢查，無需安裝任何應用。這是此前開發(fā)者使用該開源庫的主要方式。
但 2020 年，瀏覽器的發(fā)展方向變了。首先講講 Microsoft，它將自研的瀏覽器引擎替換為基于 Chromium 的引擎，同時它們也成為了 WebRTC 的積極貢獻者。Microsoft 貢獻之一是 perfect negotiation，它使得兩端以更穩(wěn)妥的形式協(xié)商。而且，它們還改良了屏幕捕獲，使其效率更高。
另一方面，還有 Safari。蘋果的 Safari 還在繼續(xù)改進他們 WebRTC API。激動人心的是，最新一版的 Safari Tech Preview 中已支持了 VP9，而且還支持硬件加速，大家可以在 Safari 的“開發(fā)者設置”中啟用它。
火狐瀏覽器增加了重傳以及 transport-cc，這有助于更好地估計可用帶寬，從而改善媒體質(zhì)量。
另一方面，Project Zero——Google 負責產(chǎn)品安全性的團隊，通過尋找漏洞，幫助提高 WebRTC 的安全性。這意味著如果你的庫不基于瀏覽器，及時更新 WebRTC 庫、遵守說明就更加重要了。
另一件激動人心的事情就是，2020 年，云游戲已經(jīng)上線了。它的實現(xiàn)有賴于 WebRTC。Stadia（Google 的云游戲平臺）已于 2019 年底推出，但 2020 年初才正式在瀏覽器得以支持。其云游戲搭載 VP9，提供 4k、HDR 圖像和環(huán)繞聲體驗。這些都會通過 WebRTC 進行傳輸。
數(shù)月前，NVIDIA 也發(fā)布了適用于 Chromebook 的 GeForce Now，同樣使用了 WebRTC。最近，Microsoft 和亞馬遜也宣布支持基于瀏覽器的云游戲開發(fā)。這確實促使 WebRTC 從數(shù)百毫秒延遲降低到了數(shù)十毫秒延遲，同時開啟了全新的應用場景。但最重要的是， 2020 年，實時通訊（RTC）對于每個人來說都是必不可少的一部分。因此，許多網(wǎng)絡服務的使用率暴漲，漲幅從十倍到幾百倍不等。大家打語音電話的次數(shù)更多了，時間更久了，群組數(shù)量和成員人數(shù)也增加了， 線上交流越來越多。所以我們需要更豐富的互動方式。
從 Google 的角度來看， 在疫情爆發(fā)的頭 2、3 個月內(nèi)，我們的最大需求容量增長了 30 倍。所以即使是 Google，要確保后端和所有系統(tǒng)功能都可以應對這么大的增長，我們也付出了很多努力。
在變化面前， WebRTC 和實時通信使用量激增。大眾的日常習慣也在變化�，F(xiàn)在不只在公司能工作， 自己的臥室、廚房里都是工作場所了。由于“社交距離”，面對面交流變得不再現(xiàn)實，我們需要其它與他人社交的方法。我們只能通過視頻，依據(jù)別人的表情猜測他的意圖，此時高清的視頻質(zhì)量就顯得更加重要了。
每個人協(xié)作的方式不同，可能是因為我們用的設備不一樣。如果你在公司， 你用的可能是臺式機，那你可能會用它在會議室里開會。而下班之后，你可能會帶你的筆記本電腦回家。但現(xiàn)在人們都在用筆記本處理各種事宜，比如同時運行應用、視頻會議和文字聊天。這種場景下，電腦的使用率非常高。我們看到學校里的孩子們也在用筆記本電腦，比如 Chromebook， 但他們電腦的性能相對差一點。社交、學習線上化之后，電腦的任務處理量突然增大， 所以開展該 WebRTC 項目的意義在于我們需要幫助擴展 WebRTC，確保其運行良好。
其次，我們需要為 Web 開發(fā)者和實時通訊開發(fā)者提供更大的靈活度，讓他們可以在當下開發(fā)出新的互動體驗。當疫情爆發(fā)時，它阻礙我們了在 Chrome 中開展的所有實驗，于是我們所做的一件事情就是專注于服務的擴展、維護。但這遠遠不夠，特別是在提高性能方面，我們需要做得更好。
大家可以猜一猜，如果你要在任何使用 WebRTC 的瀏覽器中開展實時服務， 最耗性能的部分會是什么呢？是視頻編碼？音頻編碼？網(wǎng)絡適配？（因為你會考慮到可能會有丟包和網(wǎng)絡變化）又或者是渲染？
當你想在屏幕顯示攝像頭采集的畫面時，我們可以來看看瀏覽器中發(fā)生了什么。我們假設你有一個通過 USB 驅(qū)動程序輸入的攝像頭， 驅(qū)動運行，開始處理，攝像頭可能還會進行人臉檢測、亮度調(diào)整等操作。這要經(jīng)過瀏覽器內(nèi)的系統(tǒng)，Chrome 和其它瀏覽器都是多進程的。多進程有助于瀏覽器的穩(wěn)定性和安全性，比如一個組件或一個頁面崩潰，或存在安全漏洞，那么它就會與其他沙盒中的組件隔離。但這也意味著進程間有大量的通信。所以如果你有一幀視頻數(shù)據(jù)從攝像頭被采集，它可能是 MJPEG 格式。當它開始渲染你定義媒體流的頁面時， 格式可能為 I420。當從渲染進程轉(zhuǎn)到 GPU 進程（需要實際在屏幕上繪制）時，需要提供最高質(zhì)量的數(shù)據(jù)，此時數(shù)據(jù)可能是 RGB 格式。當它再次進入操作系統(tǒng)，在屏幕上進行合成時， 可能需要一個 alpha 層， 格式又要變。這中間涉及到大量轉(zhuǎn)換和復制步驟。由此可見， 無論內(nèi)容來自攝像頭還是某一終端，僅僅把它放到屏幕上的視頻幀中就要花費大量的處理時間。所以這就是 WebRTC 服務中最復雜的部分——渲染。
這也是我們做了很多優(yōu)化的地方。渲染變得更加高效了，可以確保我們不會在每次更新視頻幀時都重新繪制。如果同時有多個視頻，我們會把他們同步，再做其他操作。Chrome 團隊優(yōu)化了內(nèi)存分配，確保每個視頻幀都以最有效的方式得到分配。我們還改進了 Chrome OS 上的操作系統(tǒng)調(diào)度，以確保視頻服務即使負載過重也能保證交互和響應。接下來的幾個月里，我們將致力于從攝像頭采集到視頻幀渲染到屏幕這個過程的“零拷貝”。我們希望不會出現(xiàn)一次拷貝或轉(zhuǎn)換，但所有信息都會以最高效的方式保存在圖片內(nèi)存里的。
同時，我們也致力于使刷新率適應視頻幀率。所以在沒有任何變化的情況下，我們不需要 60Hz 的屏幕刷新率，但要適應視頻的幀速率，例如 25 秒一次。以下是我們覺得有用的建議：
1、避免耗時耗力的擴展操作，在 incongnito 模式下進行測試。
避免耗時耗力的擴展操作很難，它可以干擾你的服務進程，減緩你的服務速度。
2、避免安全程序干擾瀏覽器運行
殺毒軟件若要做深度數(shù)據(jù)包檢查或阻止數(shù)據(jù)包，會占用大量 CPU。
3、通過 Intel Power Gadgets 來測試
我們建議你用 Intel Power Gadgets 看看你的服務用了多少能耗。它會比只看 CPU 百分比直觀的多。
4、花哨的視頻效果會占用更多性能
如果你用一些花哨的動畫， 比如會動的圓點來裝飾你的視頻幀，就會占用更多性能。盡管看起來不錯，但它可能會導致視頻幀卡頓一番才能渲染在屏幕上。
5、攝像頭分辨率設置與傳輸分辨率一致
如果你使用攝像頭采集，請確保打開攝像頭時將其分辨率的設置，與你調(diào)用 getUserMedia 時的設置保持一致。如果你打開攝像頭，設置了高清畫質(zhì)，格式為 VGA，那么勢必需要轉(zhuǎn)換很多字節(jié)的信息都會被扔掉。
6、要留意 WebAudio 的使用
WebAudio 可能比預期需要更多 CPU 來處理。
關(guān)于視頻編解碼
視頻編解碼器可用于構(gòu)建更高性能服務器。因為不僅 CPU 資源很重要， 若你構(gòu)建網(wǎng)絡相關(guān)的服務，視頻編解碼器就顯得重要起來了。如果你要把業(yè)務拓展一百倍， Google 提供一款免費的編解碼器，VP8、VP9、AV1，并且他在所有瀏覽器中都可用。
VP8 是目前為止瀏覽器內(nèi)部使用最多的版本，所有瀏覽器都支持它。VP9 同樣在市場中流通很多年了，也一直在改進。它具備 30%-50% 的節(jié)約率，以及如支持 HDR 和 4K 的高質(zhì)量功能。同時，它廣泛應用于谷歌內(nèi)部，支持 Stadia 及其他內(nèi)部服務。因為它有 VP8 中沒有的功能，即能幫助你更好地適應高低帶寬連接的轉(zhuǎn)換。然后是 AV1。AV1 也即將在 WebRTC、一些開源實現(xiàn)和瀏覽器中使用。大多數(shù)瀏覽器已經(jīng)可以使用它進行流式傳輸。希望明年能正式啟用它。實際上，微軟剛剛宣布他們的操作系統(tǒng)將支持硬件加速 AV1。性能的提升給予了開發(fā)者更大空間。
WebRTC NV（Next Version）
發(fā)布 WebRTC 1.0 之后，我們就和社區(qū)一起研發(fā)下一個版本， 該版本叫“NV”。該版本意在支持當前 WebRTC API 不可能或很難實現(xiàn)的新用例，比如虛擬現(xiàn)實。對于虛擬現(xiàn)實特效，就像前面提到過的筆記本電腦和機器學習的例子一樣， 為了能夠使用 WebRTC API 運行，我們需要更好地掌握媒體處理的技能， 比如更好控制傳輸和擁塞，使用編解碼器進行更多自定義操作等等。
在以上這些目標上，WebRTC NV 的思路是不定義全新 API。目前已經(jīng)有兩個 API 和 WebRTC，PeerConnetion 和 getUserMedia 了。我們不會重新定義它們，從頭開始研發(fā)。相反，我們正在做的是：允許我們使用稱為“HTML 流”的接口訪問端對 peer connection 內(nèi)部，以及允許訪問瀏覽器中的編解碼器的接口。再加上諸如 Web Assembly 和 workers threads 的新技術(shù)，你可以在瀏覽器，以及集成的端對端連接中使用 Javascript 進行實時處理。
如果看一下現(xiàn)在的 WebRTC 的內(nèi)部，你會發(fā)現(xiàn)媒體流就像是從網(wǎng)絡傳入時一樣被拆包（depacketized）。這里會有一些丟失或延遲的適配。因此，我們對此進行了重構(gòu)。
另一方面， 攝像頭輸入或麥克風輸入已經(jīng)經(jīng)過編解碼器如 Opus 或 VP8，去除了回聲。比特率已經(jīng)根據(jù)網(wǎng)絡情況進行了適配，然后將其打包為 RTP 數(shù)據(jù)包并通過網(wǎng)絡發(fā)送。我們想做到在 WebRTC NV 中攔截該管道，所以要從媒體框架開始。因此，我們希望能夠在媒體幀從網(wǎng)絡到達顯示器，以及從攝像機麥克風到網(wǎng)絡回到媒體幀時對其進行監(jiān)聽。我們希望能夠更好地管理這些流。目前我們提出兩個流方案，也正是我致力研究的兩個 API。
第一個是可插入媒體流（Insertable Media Stream）。當前的 Chrome 瀏覽器 86 中已提供此功能。Google 服務和其他外部服務已使用了此功能。你可以使用它來實現(xiàn)端到端加密，或者可以使用它向框架中添加自定義元數(shù)據(jù)（meta-data）。你要做的是在 PeerConnection 中定義此編碼的可插入媒體流，并且你也可以創(chuàng)建流。之后，當你從攝像頭獲取視頻幀時，它首先被編碼，比如 VP8 格式，之后你可以訪問它并進行流式處理。你還可以對其進行加密或標記其中一些元數(shù)據(jù)。
另一個是原始媒體流 API（Raw Media Stream）。這是標準委員會正在討論的標準工作。目前已經(jīng)有一些確切的建議了。從 Google 的角度來說，我們正在嘗試這種實現(xiàn)。該 API 允許我們訪問原始幀。它意味著，當原始幀從攝像頭采集后，在還未進行視頻編碼前，你就可以訪問這些數(shù)據(jù)了。然后你可以對其進行處理，比如實現(xiàn) AR 效果。你還可以運行多個濾鏡來刪除背景，然后應用一些效果。比如我想把我現(xiàn)在的視頻背景設成一個熱帶島嶼。這還可以應用到自定義的編解碼器中，比如你此前使用的一些編解碼器與現(xiàn)在的瀏覽器不兼容，那么你可以利用這個接口將數(shù)據(jù)直接傳給編解碼器來處理。原始媒體流 API 可以提供一種非常有效的方式來訪問此原始媒體。
總結(jié)一下。雖然 WebRTC 作為 W3C 正式標準已經(jīng)發(fā)布，但仍在繼續(xù)改進。新的視頻編解碼器 AV1 可節(jié)省多達 50% 的帶寬，正在 WebRTC 和網(wǎng)絡瀏覽器中使用。開源代碼的持續(xù)改進有望進一步減少延遲，提高視頻流的質(zhì)量。WebRTC NV 收集了創(chuàng)建補充 API 的倡議，以實現(xiàn)新的用例。這些 API 包括對現(xiàn)有 API 的擴展，以提供更多對現(xiàn)有功能的控制，例如可擴展視頻編碼，以及提供對 low-level 組件的訪問的 API。后者通過集成高性能的定制 WebAssembly 組件，為網(wǎng)絡開發(fā)者提供了更多的創(chuàng)新靈活性。隨著新興的 5G 網(wǎng)絡和對更多交互式服務的需求，我們預計在未來一年內(nèi)，持續(xù)增強在 WebRTC 的服務端建設。
