聲網(wǎng)Agora 開發(fā)者社區(qū)聯(lián)合 InfoQ 共同策劃，邀請了聲網(wǎng)Agora 開發(fā)者社區(qū)中的多位技術(shù)專家，從視頻傳輸、計算機視覺、編解碼標(biāo)準(zhǔn)發(fā)展、WebRTC、機器學(xué)習(xí)、音頻技術(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)音視頻交互來講十分重要。因為在你可以再瀏覽器上運行任何一種服務(wù)，并進行安全檢查，無需安裝任何應(yīng)用。這是此前開發(fā)者使用該開源庫的主要方式。

　　但 2020 年，瀏覽器的發(fā)展方向變了。首先講講 Microsoft，它將自研的瀏覽器引擎替換為基于 Chromium 的引擎，同時它們也成為了 WebRTC 的積極貢獻者。Microsoft 貢獻之一是 perfect negotiation，它使得兩端以更穩(wěn)妥的形式協(xié)商。而且，它們還改良了屏幕捕獲，使其效率更高。

　　另一方面，還有 Safari。蘋果的 Safari 還在繼續(xù)改進他們 WebRTC API。激動人心的是，最新一版的 Safari Tech Preview 中已支持了 VP9，而且還支持硬件加速，大家可以在 Safari 的“開發(fā)者設(shè)置”中啟用它。

　　火狐瀏覽器增加了重傳以及 transport-cc，這有助于更好地估計可用帶寬，從而改善媒體質(zhì)量。

　　另一方面，Project Zero——Google 負責(zé)產(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ù)十毫秒延遲，同時開啟了全新的應(yīng)用場景。但最重要的是， 2020 年，實時通訊（RTC）對于每個人來說都是必不可少的一部分。因此，許多網(wǎng)絡(luò)服務(wù)的使用率暴漲，漲幅從十倍到幾百倍不等。大家打語音電話的次數(shù)更多了，時間更久了，群組數(shù)量和成員人數(shù)也增加了， 線上交流越來越多。所以我們需要更豐富的互動方式。

　　從 Google 的角度來看， 在疫情爆發(fā)的頭 2、3 個月內(nèi)，我們的最大需求容量增長了 30 倍。所以即使是 Google，要確保后端和所有系統(tǒng)功能都可以應(yīng)對這么大的增長，我們也付出了很多努力。

　　在變化面前， WebRTC 和實時通信使用量激增。大眾的日常習(xí)慣也在變化。現(xiàn)在不只在公司能工作， 自己的臥室、廚房里都是工作場所了。由于“社交距離”，面對面交流變得不再現(xiàn)實，我們需要其它與他人社交的方法。我們只能通過視頻，依據(jù)別人的表情猜測他的意圖，此時高清的視頻質(zhì)量就顯得更加重要了。

　　每個人協(xié)作的方式不同，可能是因為我們用的設(shè)備不一樣。如果你在公司， 你用的可能是臺式機，那你可能會用它在會議室里開會。而下班之后，你可能會帶你的筆記本電腦回家。但現(xiàn)在人們都在用筆記本處理各種事宜，比如同時運行應(yīng)用、視頻會議和文字聊天。這種場景下，電腦的使用率非常高。我們看到學(xué)校里的孩子們也在用筆記本電腦，比如 Chromebook， 但他們電腦的性能相對差一點。社交、學(xué)習(xí)線上化之后，電腦的任務(wù)處理量突然增大， 所以開展該 WebRTC 項目的意義在于我們需要幫助擴展 WebRTC，確保其運行良好。

　　其次，我們需要為 Web 開發(fā)者和實時通訊開發(fā)者提供更大的靈活度，讓他們可以在當(dāng)下開發(fā)出新的互動體驗。當(dāng)疫情爆發(fā)時，它阻礙我們了在 Chrome 中開展的所有實驗，于是我們所做的一件事情就是專注于服務(wù)的擴展、維護。但這遠遠不夠，特別是在提高性能方面，我們需要做得更好。

　　大家可以猜一猜，如果你要在任何使用 WebRTC 的瀏覽器中開展實時服務(wù)， 最耗性能的部分會是什么呢？是視頻編碼？音頻編碼？網(wǎng)絡(luò)適配？（因為你會考慮到可能會有丟包和網(wǎng)絡(luò)變化）又或者是渲染？

　　當(dāng)你想在屏幕顯示攝像頭采集的畫面時，我們可以來看看瀏覽器中發(fā)生了什么。我們假設(shè)你有一個通過 USB 驅(qū)動程序輸入的攝像頭， 驅(qū)動運行，開始處理，攝像頭可能還會進行人臉檢測、亮度調(diào)整等操作。這要經(jīng)過瀏覽器內(nèi)的系統(tǒng)，Chrome 和其它瀏覽器都是多進程的。多進程有助于瀏覽器的穩(wěn)定性和安全性，比如一個組件或一個頁面崩潰，或存在安全漏洞，那么它就會與其他沙盒中的組件隔離。但這也意味著進程間有大量的通信。所以如果你有一幀視頻數(shù)據(jù)從攝像頭被采集，它可能是 MJPEG 格式。當(dāng)它開始渲染你定義媒體流的頁面時， 格式可能為 I420。當(dāng)從渲染進程轉(zhuǎn)到 GPU 進程（需要實際在屏幕上繪制）時，需要提供最高質(zhì)量的數(shù)據(jù)，此時數(shù)據(jù)可能是 RGB 格式。當(dāng)它再次進入操作系統(tǒng)，在屏幕上進行合成時， 可能需要一個 alpha 層， 格式又要變。這中間涉及到大量轉(zhuǎn)換和復(fù)制步驟。由此可見， 無論內(nèi)容來自攝像頭還是某一終端，僅僅把它放到屏幕上的視頻幀中就要花費大量的處理時間。所以這就是 WebRTC 服務(wù)中最復(fù)雜的部分——渲染。

　　這也是我們做了很多優(yōu)化的地方。渲染變得更加高效了，可以確保我們不會在每次更新視頻幀時都重新繪制。如果同時有多個視頻，我們會把他們同步，再做其他操作。Chrome 團隊優(yōu)化了內(nèi)存分配，確保每個視頻幀都以最有效的方式得到分配。我們還改進了 Chrome OS 上的操作系統(tǒng)調(diào)度，以確保視頻服務(wù)即使負載過重也能保證交互和響應(yīng)。接下來的幾個月里，我們將致力于從攝像頭采集到視頻幀渲染到屏幕這個過程的“零拷貝”。我們希望不會出現(xiàn)一次拷貝或轉(zhuǎn)換，但所有信息都會以最高效的方式保存在圖片內(nèi)存里的。

　　同時，我們也致力于使刷新率適應(yīng)視頻幀率。所以在沒有任何變化的情況下，我們不需要 60Hz 的屏幕刷新率，但要適應(yīng)視頻的幀速率，例如 25 秒一次。以下是我們覺得有用的建議：

　　1、避免耗時耗力的擴展操作，在 incongnito 模式下進行測試。

　　避免耗時耗力的擴展操作很難，它可以干擾你的服務(wù)進程，減緩你的服務(wù)速度。

　　2、避免安全程序干擾瀏覽器運行

　　殺毒軟件若要做深度數(shù)據(jù)包檢查或阻止數(shù)據(jù)包，會占用大量 CPU。

　　3、通過 Intel Power Gadgets 來測試

　　我們建議你用 Intel Power Gadgets 看看你的服務(wù)用了多少能耗。它會比只看 CPU 百分比直觀的多。

　　4、花哨的視頻效果會占用更多性能

　　如果你用一些花哨的動畫， 比如會動的圓點來裝飾你的視頻幀，就會占用更多性能。盡管看起來不錯，但它可能會導(dǎo)致視頻幀卡頓一番才能渲染在屏幕上。

　　5、攝像頭分辨率設(shè)置與傳輸分辨率一致

　　如果你使用攝像頭采集，請確保打開攝像頭時將其分辨率的設(shè)置，與你調(diào)用 getUserMedia 時的設(shè)置保持一致。如果你打開攝像頭，設(shè)置了高清畫質(zhì)，格式為 VGA，那么勢必需要轉(zhuǎn)換很多字節(jié)的信息都會被扔掉。

　　6、要留意 WebAudio 的使用

　　WebAudio 可能比預(yù)期需要更多 CPU 來處理。

　　視頻編解碼器可用于構(gòu)建更高性能服務(wù)器。因為不僅 CPU 資源很重要， 若你構(gòu)建網(wǎng)絡(luò)相關(guān)的服務(wù)，視頻編解碼器就顯得重要起來了。如果你要把業(yè)務(wù)拓展一百倍， Google 提供一款免費的編解碼器，VP8、VP9、AV1，并且他在所有瀏覽器中都可用。

　　VP8 是目前為止瀏覽器內(nèi)部使用最多的版本，所有瀏覽器都支持它。VP9 同樣在市場中流通很多年了，也一直在改進。它具備 30%-50% 的節(jié)約率，以及如支持 HDR 和 4K 的高質(zhì)量功能。同時，它廣泛應(yīng)用于谷歌內(nèi)部，支持 Stadia 及其他內(nèi)部服務(wù)。因為它有 VP8 中沒有的功能，即能幫助你更好地適應(yīng)高低帶寬連接的轉(zhuǎn)換。然后是 AV1。AV1 也即將在 WebRTC、一些開源實現(xiàn)和瀏覽器中使用。大多數(shù)瀏覽器已經(jīng)可以使用它進行流式傳輸。希望明年能正式啟用它。實際上，微軟剛剛宣布他們的操作系統(tǒng)將支持硬件加速 AV1。性能的提升給予了開發(fā)者更大空間。

　　發(fā)布 WebRTC 1.0 之后，我們就和社區(qū)一起研發(fā)下一個版本， 該版本叫“NV”。該版本意在支持當(dāng)前 WebRTC API 不可能或很難實現(xiàn)的新用例，比如虛擬現(xiàn)實。對于虛擬現(xiàn)實特效，就像前面提到過的筆記本電腦和機器學(xué)習(xí)的例子一樣， 為了能夠使用 WebRTC API 運行，我們需要更好地掌握媒體處理的技能， 比如更好控制傳輸和擁塞，使用編解碼器進行更多自定義操作等等。

　　在以上這些目標(biāo)上，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)絡(luò)傳入時一樣被拆包（depacketized）。這里會有一些丟失或延遲的適配。因此，我們對此進行了重構(gòu)。

　　另一方面， 攝像頭輸入或麥克風(fēng)輸入已經(jīng)經(jīng)過編解碼器如 Opus 或 VP8，去除了回聲。比特率已經(jīng)根據(jù)網(wǎng)絡(luò)情況進行了適配，然后將其打包為 RTP 數(shù)據(jù)包并通過網(wǎng)絡(luò)發(fā)送。我們想做到在 WebRTC NV 中攔截該管道，所以要從媒體框架開始。因此，我們希望能夠在媒體幀從網(wǎng)絡(luò)到達顯示器，以及從攝像機麥克風(fēng)到網(wǎng)絡(luò)回到媒體幀時對其進行監(jiān)聽。我們希望能夠更好地管理這些流。目前我們提出兩個流方案，也正是我致力研究的兩個 API。

　　第一個是可插入媒體流（Insertable Media Stream）。當(dāng)前的 Chrome 瀏覽器 86 中已提供此功能。Google 服務(wù)和其他外部服務(wù)已使用了此功能。你可以使用它來實現(xiàn)端到端加密，或者可以使用它向框架中添加自定義元數(shù)據(jù)（meta-data）。你要做的是在 PeerConnection 中定義此編碼的可插入媒體流，并且你也可以創(chuàng)建流。之后，當(dāng)你從攝像頭獲取視頻幀時，它首先被編碼，比如 VP8 格式，之后你可以訪問它并進行流式處理。你還可以對其進行加密或標(biāo)記其中一些元數(shù)據(jù)。

　　另一個是原始媒體流 API（Raw Media Stream）。這是標(biāo)準(zhǔn)委員會正在討論的標(biāo)準(zhǔn)工作。目前已經(jīng)有一些確切的建議了。從 Google 的角度來說，我們正在嘗試這種實現(xiàn)。該 API 允許我們訪問原始幀。它意味著，當(dāng)原始幀從攝像頭采集后，在還未進行視頻編碼前，你就可以訪問這些數(shù)據(jù)了。然后你可以對其進行處理，比如實現(xiàn) AR 效果。你還可以運行多個濾鏡來刪除背景，然后應(yīng)用一些效果。比如我想把我現(xiàn)在的視頻背景設(shè)成一個熱帶島嶼。這還可以應(yīng)用到自定義的編解碼器中，比如你此前使用的一些編解碼器與現(xiàn)在的瀏覽器不兼容，那么你可以利用這個接口將數(shù)據(jù)直接傳給編解碼器來處理。原始媒體流 API 可以提供一種非常有效的方式來訪問此原始媒體。

　　總結(jié)一下。雖然 WebRTC 作為 W3C 正式標(biāo)準(zhǔn)已經(jīng)發(fā)布，但仍在繼續(xù)改進。新的視頻編解碼器 AV1 可節(jié)省多達 50% 的帶寬，正在 WebRTC 和網(wǎng)絡(luò)瀏覽器中使用。開源代碼的持續(xù)改進有望進一步減少延遲，提高視頻流的質(zhì)量。WebRTC NV 收集了創(chuàng)建補充 API 的倡議，以實現(xiàn)新的用例。這些 API 包括對現(xiàn)有 API 的擴展，以提供更多對現(xiàn)有功能的控制，例如可擴展視頻編碼，以及提供對 low-level 組件的訪問的 API。后者通過集成高性能的定制 WebAssembly 組件，為網(wǎng)絡(luò)開發(fā)者提供了更多的創(chuàng)新靈活性。隨著新興的 5G 網(wǎng)絡(luò)和對更多交互式服務(wù)的需求，我們預(yù)計在未來一年內(nèi)，持續(xù)增強在 WebRTC 的服務(wù)端建設(shè)。