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

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

-01-

背景

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

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

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

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

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

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

-02-

WebAssembly引擎

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

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

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

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

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

-03-

方案落地

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

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

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

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

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

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

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

-04-

問(wèn)題及展望

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

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

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

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