Web技術(shù)在發(fā)展，音視頻通話需求在演進，怎么去實現(xiàn)新的Web技術(shù)點在實際應用中的值，以及給我們帶來更大的收益是需要我們?nèi)ヌ剿骱蛯嵺`的。LiveVideoStackCon 2022北京站邀請到田建華為我們從實踐中來介紹WebAssembly、WebCodecs、WebTransport等技術(shù)在音視頻行業(yè)的價值以及優(yōu)勢。

大家好，我叫田建華。今天分享的主題是基于WebAssembly構(gòu)建Web端音視頻通話引擎。今天將從背景、WebAssembly引擎、方案落地和問題及展望四個方面展開介紹。

-01-

背景

隨著網(wǎng)絡基礎(chǔ)設施的升級，音視頻傳輸技術(shù)的迭代，以及音視頻消費習慣的轉(zhuǎn)變，多媒體技術(shù)從最開始的點播和直播發(fā)展到了現(xiàn)在的超低延時直播和實時音視頻互動。在發(fā)展過程中Web RTC奠定了技術(shù)基礎(chǔ)。

這是WebRTC的架構(gòu)示意圖。WebRTC提供了豐富的Web API。音視頻采集、音視頻編解碼、音視頻前后處理、音視頻的傳輸和渲染都因WebRTC得以實現(xiàn)。在開發(fā)音視頻Web端應用時，由于WebRTC的應用，開發(fā)難度降低，成本也減少很多。WebRTC也存在一些不足。首先WebRTC不能自定義編解碼器，另外WebRTC不能復用現(xiàn)有的服務框架以及優(yōu)化能力，最后WebRTC的可定制化程度較低。

有沒有新的Web技術(shù)作為替代來解決WebRTC的問題呢？下面將列舉一些可以使用的新技術(shù)。

WebAssembly是一種運行在現(xiàn)代瀏覽器中的新型代碼，并且提供新的性能特性和效果。其設計目標是快速、高效、可移植、可讀、可調(diào)試、安全和不破壞網(wǎng)絡。使用WebAssembly可以解決JavaScript在復雜場景的性能問題，例如3D 游戲、計算機視覺、圖像視頻編輯等以及大量的要求原生性能的其他領(lǐng)域。一些原先使用JavaScript的場景中使用WebAssembly可以顯著提高使用效率。得益于WebAssembly體積小的特性，使用WebAssembly還可以解決下載、解析JavaScript應用程序成本高的問題。

WebCodecs為開發(fā)人員提供了一種使用瀏覽器中已經(jīng)存在的媒體組件的方法，不僅可以解決編碼器低延時問題，還可以提供更靈活的配置接口。右邊的圖片是視頻編碼器的配置項，可以看出有很多可以配置的選項都被提供出來，例如軟硬件編碼的選擇、VBR/CBR的選擇、質(zhì)量優(yōu)先/低延時優(yōu)先等都可以選擇配置。H264編碼使用HighProfile時，WebCodes配置項里可以很容易的支持，在編碼層面提供非常大的便利。

WebTransport是一個全新的可插拔的通信協(xié)議，支持可靠和非可靠傳輸。在一些需要可靠傳輸?shù)膽弥锌梢允褂肳ebTransport。WebTransport的目標是更快速、更高效、安全和低延時。WebTransport可以解決鏈接遷移的問題。WebTransport擁有靈活的擁塞控制以及更好的弱網(wǎng)能力。在應對隊頭阻塞時，有可以使用更加靈活的傳輸方式。

-02-

WebAssembly引擎

新技術(shù)和新架構(gòu)致力于給用戶提供更多的可能性。自定義編解碼器、自定義傳輸方式、自定義數(shù)據(jù)加密、自定義音視頻前后處理和自定義QoS操作均已在可以實踐的項目中落地。

這是整個WebAssembly引擎的架構(gòu)圖。WebAssembly引擎主要包含WebSDK、用戶調(diào)度中心、WebTransport/WebSocket Gateway集群和后臺TRTC服務集群和調(diào)度四大模塊。因為后臺的TRTC服務可以直接復用，所以主要的工作是WebSDK和WebGateway的開發(fā)。

WebSDK提供了Client、LocalStream、RemoteStream等接口。Client為用戶提供可操作的方法。LocalStream提供音視頻的數(shù)據(jù)回調(diào)。RemoteStream提供遠端用戶的音視頻數(shù)據(jù)回調(diào)。總線負責整個WebSDK的運行。底層包括日志上報、質(zhì)量上報、異常檢測、狀態(tài)回復、采集渲染、Wasm SDK、WebCodecs、WebTransport/WebSocket等。橙色部分是主要使用的技術(shù)。其中WebCodecs和WebTransport/WebSocket是瀏覽器提供的方法，只需要用好即可。

WebAssembly SDK分為五大模塊。音頻處理包含回聲消除、AI降噪和增益三部分。協(xié)議封裝解封裝包含視頻協(xié)議封裝解封裝、視頻包協(xié)議分裝解封裝和FEC。下行質(zhì)量控制包含視頻Jitterbuffer、視頻NetEQ、FEC恢復/NACK和音視頻同步。除此之外還有上下行質(zhì)量統(tǒng)計、擁塞控制、音頻編碼和音頻解碼四個部分。

最左側(cè)淺色部分是JS層。上下是WebCodecs層，中間是Wasm，最右邊是網(wǎng)絡傳輸部分。JS業(yè)務層采集到音視頻數(shù)據(jù)之后，交給WebAssembly進行音頻的前處理。之后會由WebCodecs編碼，封裝之后通過網(wǎng)絡發(fā)送。從網(wǎng)絡搜集到數(shù)據(jù)之后，也會在WebAssembly解封裝和進行一些音視頻的后處理。完成之后交由WebCodecs解碼和JS渲染。在實際使用過程中，音視頻編碼是在WebAssembly SDK中實現(xiàn)。

-03-

方案落地

騰訊云新的SDK已經(jīng)在一些金融客戶、行業(yè)用戶和信創(chuàng)項目得到了廣泛應用。

右上角圖片中，前四個是WebAssembly用戶，后面兩個是WebRTC用戶。他們同時加入一個房間。在內(nèi)存使用率方面，WebAssembly和WebRTC差不多，但CPU使用率WebAssembly更低。這樣，WebAssembly就擁有了更加靈活的可操作性。在兩人進房，編碼碼率為1Mbps，幀率為30幀，RTT 10ms的場景下，多次截圖，從采集到渲染，端到端的延時在100ms內(nèi)。可以看出使用WebAssembly進行超低延時通訊也是可靠的。

從最開始的技術(shù)探索到方案落地，SDK經(jīng)過了很多次的技術(shù)迭代。一開始SDK只是用單線程，但在實際使用過程中發(fā)現(xiàn)了各種各樣的問題。例如定時器精度差、單核跑高、UI阻塞底層等。之后我們引入了Worker，主線程只負責采集、渲染等操作，其他的都交由Worker操作。

UI收集到用戶的操作指令之后，通過PostMessage交付給Worker線程。Worker搜到數(shù)據(jù)也會通過PostMessage響應給主線程。信令的封裝解封裝、推拉流、狀態(tài)統(tǒng)計、WebCodecs編解碼和WebAssembly SDK音視頻處理等都是由Worker進行。現(xiàn)在的架構(gòu)中有兩個Worker，其中一個負責上行，另一個負責下行。在這里我們還引入Worklet減少音頻數(shù)據(jù)的拷貝，以提升音頻數(shù)據(jù)的傳遞效率。在特殊場合可以使用SharedArrayBuffer傳遞視頻數(shù)據(jù)，以減小視頻數(shù)據(jù)的性能影響。

后臺RTC服務主要采用的是復用的現(xiàn)網(wǎng)架構(gòu)。在服務端采用BBR算法和更激進的擁塞控制已收獲更低延遲的弱網(wǎng)體驗。同時根據(jù)丟包、Jitter情況，適當調(diào)整弱網(wǎng)策略。最后，我們還設計根據(jù)網(wǎng)絡情況自適應FEC策略。

在WebAssembly開發(fā)過程中遇到問題怎么辦？答案是調(diào)試。WebAssembly的調(diào)試非常方便，提供了可視化界面。

調(diào)試程序使用C++開發(fā)。在調(diào)試過程中，會先在瀏覽器安裝如圖所示的插件，安裝好之后需要一些簡單的配置。配置完成以后就可以進行調(diào)試。啟動應用程序之后會自動加載wasm文件和源文件。右圖以opus編碼為例。左邊是源碼欄，里面有一個斷點。中間是很詳細的變量信息，右下角是堆棧調(diào)用關(guān)系。和普通的C++程序一樣，在編譯時需要添加-g選項。缺少的話就會因為找不到源碼目錄而不能調(diào)試。

-04-

問題及展望

我認為WebAssembly的高度自定義是其最大的優(yōu)點。自定義音視頻編碼方式、自定義加解密、國密支持、自定義3A都已經(jīng)支持。使用WebAssembly進行國密支持，其性能可以得到數(shù)10倍的提升，自定義3A中的AI降噪已經(jīng)投入到生產(chǎn)，實際落地，支持200多種噪聲的處理。QoS調(diào)優(yōu)可以自定義或可復用現(xiàn)有系統(tǒng)的QoS策略。更簡單的服務器邏輯使得可復用后臺服務邏輯。WebAssembly擁有更快更安全的網(wǎng)絡傳輸，WebTransport有更好的防火墻穿透能力。

WebAssembly同樣也存在一些問題。WebAssembly引入了WebAssembly、WebCodecs和WebTransport三個新的模塊。WebAssembly擁有更好的復雜性，增加開發(fā)難度，需要更多的技術(shù)積累。WebTransport不能在Safari瀏覽器中運行，WebCodecs目前只能在Chrome和Edge94以上以及最新的 safari版本運行，WebTransport也只能在Chrome和Egde97以上以 版本運行，這些問題都帶來一定的兼容性問題。另外WebTransport上行擁塞控制算法暫不支持調(diào)整。這里我們有考慮過通過協(xié)商的方式解決上行擁塞控制，但瀏覽器作為客戶端時，會直接將協(xié)商結(jié)果忽視掉，所以這里只能等官方的支持實現(xiàn)。

在實現(xiàn)過程中，團隊也遭遇了很多的挫折。底層邏輯被UI阻塞的問題被我們引入Worker解決。我們還發(fā)現(xiàn)WebCodecs OPUS編碼只支持60ms編碼，只支持60ms會帶來實時性和兼容性的問題，所以我們嘗試在WebAssembly實現(xiàn)音視頻的編碼。除此之外，在共享標簽頁時發(fā)現(xiàn)不采集的情況。該問題的主要原因是標簽頁在靜止的時候不會被瀏覽器采集。我們在SDK活躍的前提下，增加標簽頁減活機制，通過邏輯策略進行一系列飽和操作，保證標簽頁在不活躍時也能正常屏幕共享。另外，回聲有時會無法消除。聲音對時間非常敏感，采集和渲染是會有較大的延遲，這樣就會產(chǎn)生回聲。我們調(diào)整了音頻的播放控件和傳輸策略，通過worklet播放，可以更加精準計算采集和播放的延遲。再配合回聲消除算法，該問題得以解決。目前我們也在探索能否使用AI進行回聲消除。最后，H264大小碼流也會有問題。使用WebCodecs在騰訊會議場景進行硬編時，會出現(xiàn)大小碼流輸出同樣分辨率的情況。嘗試多次發(fā)現(xiàn)，這些問題是由硬編帶來的。所以在小滿流編碼時，會強制采用軟編的baseline，這樣就可以得到一個很小的分辨率。這里僅僅例舉出其中的一小部分的問題，還有很多問題必須在實際使用和落地過程中才會發(fā)現(xiàn)。

未來，我們希望會有更開放的Web技術(shù)。WebTransport更加完善、將提供更靈活的擁塞控制算法，WebGPU也會開放硬件能力，WebAssembly的SIMD的也將更好支持。同時，更加復雜的應用場景，支持更加高度的自定義也是未來目標的一部分。云游戲、自定義加解密、遠程桌面、空間音頻、音視頻前后處理等越來越多的場景都可以自定義。