聲網(wǎng)Agora 開(kāi)發(fā)者社區聯(lián)合 InfoQ 共同策劃，邀請了聲網(wǎng)Agora 開(kāi)發(fā)者社區中的多位技術(shù)專(zhuān)家，從視頻傳輸、計算機視覺(jué)、編解碼標準發(fā)展、WebRTC、機器學(xué)習、音頻技術(shù)等角度，共同撰寫(xiě)「2021 實(shí)時(shí)互動(dòng)技術(shù)展望系列」，一窺技術(shù)新趨勢。本系列內容由聲網(wǎng) Agora 開(kāi)發(fā)者社區 與 InfoQ 聯(lián)合策劃，并由 InfoQ 審校，首發(fā)于 InfoQ。

　　2020 年，WebRTC 發(fā)生了很多變化。WebRTC 其實(shí)就是一個(gè)客戶(hù)端庫。大家都知道它是開(kāi)源的。盡管 Google 大力地在支持 WebRTC，但社區的力量同樣功不可沒(méi)。

　　WebRTC 對于桌面平臺、瀏覽器端實(shí)現音視頻交互來(lái)講十分重要。因為在你可以再瀏覽器上運行任何一種服務(wù)，并進(jìn)行安全檢查，無(wú)需安裝任何應用。這是此前開(kāi)發(fā)者使用該開(kāi)源庫的主要方式。

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

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

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

　　另一方面，Project Zero——Google 負責產(chǎn)品安全性的團隊，通過(guò)尋找漏洞，幫助提高 WebRTC 的安全性。這意味著(zhù)如果你的庫不基于瀏覽器，及時(shí)更新 WebRTC 庫、遵守說(shuō)明就更加重要了。

　　另一件激動(dòng)人心的事情就是，2020 年，云游戲已經(jīng)上線(xiàn)了。它的實(shí)現有賴(lài)于 WebRTC。Stadia（Google 的云游戲平臺）已于 2019 年底推出，但 2020 年初才正式在瀏覽器得以支持。其云游戲搭載 VP9，提供 4k、HDR 圖像和環(huán)繞聲體驗。這些都會(huì )通過(guò) WebRTC 進(jìn)行傳輸。

　　數月前，NVIDIA 也發(fā)布了適用于 Chromebook 的 GeForce Now，同樣使用了 WebRTC。最近，Microsoft 和亞馬遜也宣布支持基于瀏覽器的云游戲開(kāi)發(fā)。這確實(shí)促使 WebRTC 從數百毫秒延遲降低到了數十毫秒延遲，同時(shí)開(kāi)啟了全新的應用場(chǎng)景。但最重要的是， 2020 年，實(shí)時(shí)通訊（RTC）對于每個(gè)人來(lái)說(shuō)都是必不可少的一部分。因此，許多網(wǎng)絡(luò )服務(wù)的使用率暴漲，漲幅從十倍到幾百倍不等。大家打語(yǔ)音電話(huà)的次數更多了，時(shí)間更久了，群組數量和成員人數也增加了， 線(xiàn)上交流越來(lái)越多。所以我們需要更豐富的互動(dòng)方式。

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

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

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

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

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

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

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

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

　　1、避免耗時(shí)耗力的擴展操作，在 incongnito 模式下進(jìn)行測試。

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

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

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

　　3、通過(guò) Intel Power Gadgets 來(lái)測試

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

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

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

　　5、攝像頭分辨率設置與傳輸分辨率一致

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

　　6、要留意 WebAudio 的使用

　　WebAudio 可能比預期需要更多 CPU 來(lái)處理。

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

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

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

　　在以上這些目標上，WebRTC NV 的思路是不定義全新 API。目前已經(jīng)有兩個(gè) API 和 WebRTC，PeerConnetion 和 getUserMedia 了。我們不會(huì )重新定義它們，從頭開(kāi)始研發(fā)。相反，我們正在做的是：允許我們使用稱(chēng)為“HTML 流”的接口訪(fǎng)問(wèn)端對 peer connection 內部，以及允許訪(fǎng)問(wèn)瀏覽器中的編解碼器的接口。再加上諸如 Web Assembly 和 workers threads 的新技術(shù)，你可以在瀏覽器，以及集成的端對端連接中使用 Javascript 進(jìn)行實(shí)時(shí)處理。

　　如果看一下現在的 WebRTC 的內部，你會(huì )發(fā)現媒體流就像是從網(wǎng)絡(luò )傳入時(shí)一樣被拆包（depacketized）。這里會(huì )有一些丟失或延遲的適配。因此，我們對此進(jìn)行了重構。

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

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

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

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