- +1
基于WebAssembly構(gòu)建Web端音視頻通話引擎
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ì)。
文/田建華
編輯/LiveVideoStack
大家好,我叫田建華。今天分享的主題是基于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)景都可以自定義。
謝謝大家!

本文為澎湃號(hào)作者或機(jī)構(gòu)在澎湃新聞上傳并發(fā)布,僅代表該作者或機(jī)構(gòu)觀點(diǎn),不代表澎湃新聞的觀點(diǎn)或立場(chǎng),澎湃新聞僅提供信息發(fā)布平臺(tái)。申請(qǐng)澎湃號(hào)請(qǐng)用電腦訪問(wèn)http://renzheng.thepaper.cn。





- 報(bào)料熱線: 021-962866
- 報(bào)料郵箱: news@thepaper.cn
滬公網(wǎng)安備31010602000299號(hào)
互聯(lián)網(wǎng)新聞信息服務(wù)許可證:31120170006
增值電信業(yè)務(wù)經(jīng)營(yíng)許可證:滬B2-2017116
? 2014-2026 上海東方報(bào)業(yè)有限公司




