Web開播系統(tǒng)技術(shù)探索與實(shí)踐

隨著直播SaaS業(yè)務(wù)的深入發(fā)展，Web端開播的訴求變得越來越強(qiáng)烈，對(duì)比客戶端開播工具如OBS，Web開播與SaaS平臺(tái)親和度高，可以讓用戶快速體驗(yàn)平臺(tái)全流程，同時(shí)易于分享鏈接，快速連麥。因此，尋求更加穩(wěn)定可用的Web開播能力成為了一個(gè)需要解決的問題。LiveVideoStackCon 2022北京站邀請(qǐng)到了字節(jié)跳動(dòng)的付宇豪老師，為我們分享Web開播系統(tǒng)的技術(shù)演進(jìn)。

大家好，我是付宇豪，來自字節(jié)跳動(dòng)的視頻架構(gòu)Web多媒體團(tuán)隊(duì)。今天給大家分享的主題是Web開播系統(tǒng)的技術(shù)演進(jìn)，主要講一下字節(jié)跳動(dòng)在Web開播上做的一些技術(shù)嘗試和踩過的坑。

首先簡(jiǎn)單的介紹一下我自己，我16年畢業(yè)于山東大學(xué)，17年加入字節(jié)跳動(dòng)，19年開始在Web多媒體團(tuán)隊(duì)做Web多媒體相關(guān)的工作。目前負(fù)責(zé)Web直播技術(shù)方向。

?

今天給大家分享的內(nèi)容，主要分為四個(gè)部分。首先是技術(shù)的使用場(chǎng)景，為什么要做Web開播，也就是技術(shù)的來源；第二是我們?cè)诩夹g(shù)探索過程中做的技術(shù)嘗試和踩過的坑；第三是使用WebTransport來優(yōu)化畫質(zhì)體驗(yàn)和功能擴(kuò)展性；最后是對(duì)于未來的技術(shù)和標(biāo)準(zhǔn)化的展望。

-01-

業(yè)務(wù)背景與Web開播優(yōu)勢(shì)

首先是第一部分，業(yè)務(wù)背景。

圖上的數(shù)據(jù)是直播行業(yè)的用戶規(guī)模，來自工信院的大數(shù)據(jù)統(tǒng)計(jì)。最早有統(tǒng)計(jì)數(shù)據(jù)的是2016年，因此把2016年稱為直播的元年，當(dāng)時(shí)的場(chǎng)景被稱為千播大戰(zhàn)，每個(gè)人的手機(jī)里有很多關(guān)于直播的App。

我們把整個(gè)發(fā)展過程分成兩段，可以將2020年作為一個(gè)分界點(diǎn)，分為疫情前和疫情后。疫情前的直播，經(jīng)常是一種泛娛樂化的場(chǎng)景，比如電競(jìng)直播、戶外直播、才藝直播。疫情之后，用戶的規(guī)模飛速增長(zhǎng)，這意味著在疫情的影響下，直播作為一種高效的觸達(dá)形式，開始跟商業(yè)場(chǎng)景結(jié)合起來，成為一種比較成熟的商業(yè)推廣的模式。簡(jiǎn)單來說，有人開始用直播掙錢，有人用直播掙用戶的錢，那就會(huì)有人用直播的平臺(tái)來掙企業(yè)的錢。

從數(shù)據(jù)來看，2020年疫情對(duì)于直播SaaS的增長(zhǎng)非常快。

先簡(jiǎn)單介紹一下什么是企業(yè)直播SaaS：比如一個(gè)公司要直播，卻沒有相應(yīng)的人力資源投入，但希望有自己的品牌和平臺(tái)，因此借助SaaS的平臺(tái)來搭建自己的直播。從數(shù)據(jù)上看，可以發(fā)現(xiàn)2020年企業(yè)直播有飛速的增長(zhǎng)，未來市場(chǎng)的預(yù)期非常大，因?yàn)橹辈サ臐B透率較高，用戶也養(yǎng)成了習(xí)慣，預(yù)期未來整個(gè)市場(chǎng)的商業(yè)規(guī)模會(huì)越來越大。那以上講述的業(yè)務(wù)和Web開播技術(shù)之間有什么關(guān)系呢？接下來看一下，業(yè)務(wù)場(chǎng)景里面有哪些是可以用技術(shù)解決的。

我們看一下企業(yè)會(huì)在哪些場(chǎng)景下用企業(yè)直播的服務(wù)，包括營(yíng)銷直播、現(xiàn)場(chǎng)直播、企業(yè)培訓(xùn)和教育等。

這些場(chǎng)景有一個(gè)特點(diǎn)：有大量非專業(yè)的主播開始用平臺(tái)做直播，比如HR可能會(huì)用SaaS平臺(tái)來做企業(yè)的宣講，老師可能會(huì)用SaaS平臺(tái)做課程內(nèi)容的分發(fā)。這類人的技術(shù)背景比較少，如果給其OBS軟件、RCMP地址、參數(shù)等，可能會(huì)比較懵，學(xué)習(xí)成本也高，因此該技術(shù)的第一個(gè)使用場(chǎng)景，是針對(duì)這些非專業(yè)的主播，降低技術(shù)的使用門檻，我們的直播平臺(tái)可以直接內(nèi)置這樣低門檻的方式。

接下來看下一個(gè)場(chǎng)景，線上的研討需要有嘉賓的參與，對(duì)于要參與研討會(huì)的嘉賓來說，需要下載一個(gè)軟件才可以加入，但這位嘉賓也許只參會(huì)一次，不愿意下載軟件。而通過企業(yè)Web開播的方式，只需打開一個(gè)鏈接就可以連麥，非常方便。

下一個(gè)場(chǎng)景是新客體驗(yàn)，如果企業(yè)中的一個(gè)人需要調(diào)研這個(gè)平臺(tái)，在平臺(tái)上注冊(cè)了賬號(hào)，開了直播間，想要立馬看到直播間落地頁的效果。這時(shí)如果在平臺(tái)上就可以開播，體驗(yàn)感會(huì)非常絲滑，這對(duì)體驗(yàn)鏈路的縮短非常有效，也能幫助SaaS平臺(tái)縮短體驗(yàn)的流程。

最后一個(gè)場(chǎng)景是跟SaaS本身有關(guān)系的海外。海外用戶的使用習(xí)慣跟國(guó)內(nèi)用戶不太一樣，如果有Web應(yīng)用，海外用戶一定不會(huì)選擇native應(yīng)用，這是一個(gè)很大的使用習(xí)慣區(qū)別，也是Web應(yīng)用目前非常流行的原因。

-02-

技術(shù)探索與實(shí)踐

針對(duì)業(yè)務(wù)上需要解決的問題，接下來看一下技術(shù)探索的過程以及踩過的坑有哪些？

首先，我們要找的方案需要具備哪幾個(gè)特征，需要尋找和優(yōu)化什么樣的方案。我提煉了以下幾點(diǎn)：

第一，它必須是穩(wěn)定可靠的。因?yàn)橹辈ナ且粚?duì)多的場(chǎng)景，一個(gè)主播可能有幾萬的用戶在觀看。所以在直播的實(shí)時(shí)場(chǎng)景下，任何鏈路上的穩(wěn)定性問題，都會(huì)造成非常嚴(yán)重的用戶體驗(yàn)的損失。因此穩(wěn)定性放在了第一位。

第二是高質(zhì)量。有一次我買相機(jī)，老板問道，你知道玉石直播嗎？他說，玉石直播要用多個(gè)相機(jī)定焦拍玉石，對(duì)細(xì)節(jié)的要求非常高。所以有的直播場(chǎng)景，用戶對(duì)視頻傳輸?shù)馁|(zhì)量有很高的要求。

最后是CDN的支持程度。一個(gè)私有協(xié)議，只有一部分的CDN廠家支持，能分發(fā)的范圍是非常有限的。比如一個(gè)特別大的活動(dòng)直播需要幾家CDN廠家支持，私有協(xié)議不能解決該問題，只能用公開協(xié)議將其拓展到更廣的知識(shí)度上。

將以上三點(diǎn)凝練為一個(gè)問題：如何穩(wěn)定地將高質(zhì)量的視頻信息傳遞給大量的用戶。

以上是Web開播技術(shù)探索演進(jìn)的過程。首先是Flash直播，通過Flash可以發(fā)起RTMP推流，RTMP推流是瀏覽器很早就具備的能力。第二個(gè)階段，將WebRTC協(xié)議轉(zhuǎn)成RTMP協(xié)議，再推送到CDN上。第三個(gè)階段，使用RTC的協(xié)議，直接向CDN推送WebRTC的音視頻流。最后是使用WebTransport /HTTP3公開傳輸音視頻流。

先劇透一下，省流到目前為止不存在銀彈，但探索的過程讓我們?cè)诩夹g(shù)選擇上面有更大的空間。

進(jìn)入第一個(gè)階段Flash。在最早2007年的版本里，F(xiàn)lash就在瀏覽器里定義了一套完整的接口，包括音視頻采集、傳輸和編碼，已經(jīng)可以很好地向CDN推流。但Flash技術(shù)的生命周期與Web直播的生命周期存在著一定錯(cuò)位。2016年直播正火的時(shí)候，F(xiàn)lash已經(jīng)接近到了Web生態(tài)的邊緣，所以當(dāng)時(shí)無法使用Flash的推流技術(shù)。

到2020年，F(xiàn)lash已經(jīng)完全退出了Web生態(tài)，主流瀏覽器不再支持。

Flash退出后，原有用Flash來實(shí)現(xiàn)的場(chǎng)景和能力被現(xiàn)有的HTML和新的規(guī)范替代。比如它的播放能力被H5的Video標(biāo)簽替換，它的直播能力被Media Source，extension的規(guī)范替替換，它的游戲和渲染的能力被WebGL新的規(guī)范替換。

接下來思考一個(gè)問題，繼Flash和RTMP消失后，瀏覽器怎么向CDN推流？我們要從現(xiàn)有的生態(tài)里尋找一個(gè)服務(wù)里有上行能力的協(xié)議。我們認(rèn)為WebRTC協(xié)議是下一代的音視頻流媒體的傳輸協(xié)議，它未來的發(fā)展空間非常廣，能夠支持這個(gè)場(chǎng)景。但是這時(shí)有一個(gè)問題，WebRTC是否能夠替換RTMP推流的能力呢？

首先第一個(gè)問題，瀏覽器有WebRTC，但CDN廠商沒有。也就是一門語言叫做WebRTC，另一門語言叫RTMP，而這兩者之間語言不通。當(dāng)語言不通的時(shí)候，我們會(huì)怎么做呢？

我們嘗試找一個(gè)翻譯，軟件的問題經(jīng)常加個(gè)中間層就可以解決，因此我們找到了現(xiàn)有的WebRTC系統(tǒng)里的一個(gè)能力，叫做RTC合流。這個(gè)能力本身就與直播關(guān)系非常大。我們都知道主播之間經(jīng)常要PK，PK的時(shí)候主播與主播之間會(huì)做一個(gè)視頻會(huì)議的通話。

RTC的合流服務(wù)負(fù)責(zé)把兩人之間通話的流以一定的模板合成為一路，再分別推到各自的直播間，直播間里的用戶就能夠看到兩個(gè)人在一起PK的畫面了。

我們知道轉(zhuǎn)推的能力是能夠轉(zhuǎn)成RTMP再推出去的。兩個(gè)人用是合流，一個(gè)人用是推流，一個(gè)人加入這個(gè)房間，然后調(diào)取服務(wù)能力，再把它推出去，合流轉(zhuǎn)推流的鏈路就打通了，也就是從瀏覽器端的WebRTC到CDN端的Flash。我們當(dāng)時(shí)認(rèn)為自己找到了翻譯，最后的技術(shù)方案利用了實(shí)時(shí)通信系統(tǒng)，根據(jù)WebRTC系統(tǒng)的能力來直接做這件事情。因?yàn)閷?shí)時(shí)通信的系統(tǒng)本身就有推流和上下行的能力，所以過程特別絲滑，開發(fā)測(cè)試上線都很快，但事故來得也很快。

當(dāng)時(shí)我們內(nèi)部在做技術(shù)分享直播的時(shí)候，遇到了一個(gè)問題。這個(gè)主題非常的吸引人，是教大家怎么做職業(yè)規(guī)劃，因此很多人來看直播，不巧的是，直播過程中多次斷流，最后導(dǎo)致了大量的內(nèi)網(wǎng)差評(píng)。這件事情在體驗(yàn)上非常差，因此我們嘗試去看一看事故為什么會(huì)出現(xiàn)。

了解WebRTC系統(tǒng)的同學(xué)應(yīng)該知道，WebRTC通信一般需要連一個(gè)媒體服務(wù)，一個(gè)信令服務(wù)。媒體服務(wù)是傳實(shí)時(shí)音視頻的數(shù)據(jù)，信令服務(wù)是RTC的一些基本業(yè)務(wù)，比如進(jìn)房、退房、發(fā)布、訂閱，這些邏輯會(huì)通過WebSocket的信令服務(wù)去做調(diào)用操作，信令服務(wù)的狀態(tài)也會(huì)回調(diào)。即一個(gè)模型，兩個(gè)服務(wù)器。

事故發(fā)生的時(shí)候，我們定位到信令斷了，信令服務(wù)認(rèn)為信令當(dāng)時(shí)斷開了，說明用戶不活躍了，隔了一段的超時(shí)時(shí)長(zhǎng)之后，直播的音視頻流就斷了。

那為什么WebSocket的信令當(dāng)時(shí)會(huì)斷開？

這里涉及到一個(gè)當(dāng)時(shí)使用的信令的技術(shù)，使用非常廣泛的Socket.io，它在WebSocket傳輸協(xié)議的基礎(chǔ)上定義了一套二進(jìn)制的傳輸格式，以及內(nèi)置的一些消息機(jī)制。其中影響最明顯的是ping pong保活的機(jī)制，通過間隔一段時(shí)間發(fā)一個(gè)消息來判斷連接是不是活躍。但是瀏覽器里面要定時(shí)發(fā)送消息到服務(wù)端，大概率要用到定時(shí)器來實(shí)現(xiàn)。

但問題是，在什么樣的情況下，瀏覽器發(fā)不出來ping消息了，導(dǎo)致保活沒辦法定時(shí)發(fā)送呢？這涉及到瀏覽器頁簽切后臺(tái)降頻的問題，我們?cè)贑hrome80版本的時(shí)候遇到了這樣的情況，在后來的Chrome版本，如果頁面使用了WebRTC，不會(huì)導(dǎo)致降頻。但在當(dāng)時(shí)的實(shí)際情況下，信令保證不了按照一秒一次的間隔去發(fā)送，處于一種長(zhǎng)期失準(zhǔn)的一個(gè)情況，因此導(dǎo)致ping pong消息長(zhǎng)時(shí)間發(fā)不出去，對(duì)面認(rèn)為一段時(shí)間收不到就斷開了，這就是整個(gè)事故產(chǎn)生的原因。

事故產(chǎn)生的原因是信令，我們就從信令上嘗試解決這個(gè)問題。既然是超時(shí)導(dǎo)致的斷開，因此第一個(gè)方案是把心跳的?；顣r(shí)長(zhǎng)加到6個(gè)小時(shí)，因?yàn)橐话愕闹辈サ讲涣肆鶄€(gè)小時(shí)。這樣能夠保證信令斷開了，但流還保留著，這個(gè)方案會(huì)是一個(gè)好的解決方案嗎？

顯然不是，因?yàn)樗嬖谝粋€(gè)很明顯的風(fēng)險(xiǎn)，如果信令斷開了，意味著不只是瀏覽器到服務(wù)器的消息沒辦法發(fā)送。如果服務(wù)器內(nèi)部，比如合流有服務(wù)的異常，也沒有辦法通過信令再傳達(dá)到瀏覽器，也不能再執(zhí)行后面的容災(zāi)動(dòng)作了，因此這在當(dāng)時(shí)是一個(gè)臨時(shí)的解決方案。

我們真正解決這個(gè)問題是使用了RTC的DataChannel，這也得益于RTC整個(gè)架構(gòu)的升級(jí)。DataChannel是WebRTC提供的一個(gè)穩(wěn)定可靠的消息傳輸機(jī)制。如果端口bundle了，可以跟媒體流使用同一個(gè)UDP連接進(jìn)行發(fā)送，這意味著它的連接狀態(tài)是跟媒體一致的。也就是說不需要再用心跳的機(jī)制來確認(rèn)它是不是活躍，只需要看媒體流是不是還活躍就可以了。

除了使用DataChannel解決以上的問題，作為信令它還有一些優(yōu)勢(shì)。首先，維護(hù)難度大量降低，因?yàn)樾帕詈兔襟w是兩個(gè)獨(dú)立的鏈路，二者在狀態(tài)上有不一致性，信令斷了媒體沒斷或媒體斷了信令沒斷，都會(huì)導(dǎo)致單獨(dú)的重試鏈路或做一些操作時(shí)，狀態(tài)比較復(fù)雜。能回調(diào)給用戶的東西也是很難理解的，從而產(chǎn)生一些中間狀態(tài)處理上的難度。

另外從功能性上來說，DataChannel完全覆蓋了WebSocket的能力，它是一個(gè)穩(wěn)定的、雙向的可靠數(shù)據(jù)連接。最后它的延遲是非常低的，因?yàn)閃ebSocket是使用http做協(xié)議升級(jí)，要過http網(wǎng)關(guān)會(huì)增加一定的延遲，而使用RTCDataChannel，可以直接與一個(gè)邊緣節(jié)點(diǎn)node下發(fā)的指定ip的node進(jìn)行建連，延遲非常低。所以我們現(xiàn)在也能看到很多實(shí)時(shí)的信令的產(chǎn)品會(huì)使用DataChannel來提供。

雖然信令的問題解決了，但還遺留了一個(gè)問題，我認(rèn)為這個(gè)方案是很難去解決的，因?yàn)樵谖覀兒虲DN之間引入了一個(gè)很復(fù)雜的實(shí)時(shí)音視頻的系統(tǒng)。這意味著有系統(tǒng)的參與，就會(huì)有問題的出現(xiàn)。有問題的出現(xiàn)，就會(huì)引入很多的角色來幫你解決這些問題。在這個(gè)問題中間，我們涉及到了直播服務(wù)、媒體服務(wù)、信令、前端等角色。如果是緊急的問題，大家都會(huì)按照最高優(yōu)先級(jí)去看，但如果日常出現(xiàn)任何的問題，再引入這么多角色去解決比較困難。所以很難長(zhǎng)期的保障穩(wěn)定性，對(duì)于維護(hù)的成本非常不利。

回到原來的三個(gè)要素，我們?cè)倩仡櫼幌路桨?。這個(gè)方案最大的問題是穩(wěn)定性，鏈路拉長(zhǎng)，引入的服務(wù)多了后，穩(wěn)定性很難保障，音畫質(zhì)量在后面還有RTC推流環(huán)節(jié)，我們?cè)賳为?dú)去講。最后是支持度非常好，不需要CDN做任何改造，也不需要瀏覽器做額外的事情就可以支持，所以這是最大的好處，但僅有這個(gè)好處是不夠的，我們要著力去解決穩(wěn)定性的問題。

雖然引入了pong翻譯來解決這個(gè)問題，但我們是否真的需要一個(gè)翻譯來解決瀏覽器和CDN協(xié)議之間的gap？

解決gap的最終方案，大概率是CDN能夠支持直接使用WebRTC協(xié)議推流。

如果是推一家CDN來解決這個(gè)問題，是不是可行的呢？其實(shí)我覺得不行，最好這個(gè)協(xié)議是有廣泛的CDN的支持度的，推一家做了一個(gè)私有協(xié)議出來之后，其他家不認(rèn)可，可能做出來又是另一個(gè)方案，是不標(biāo)準(zhǔn)的。

去年國(guó)內(nèi)的火山引擎和騰訊云、阿里云一起做了一個(gè)超低延遲的公開信令的標(biāo)準(zhǔn)。海外的Millicast也遇到了推流的問題，他們使用了WHIP協(xié)議，也就是WebRTCHTTP推流協(xié)議。

這兩個(gè)協(xié)議其實(shí)有很多相似之處，它主要的實(shí)現(xiàn)原理是用HTTP的公開的網(wǎng)關(guān)信令，我們都知道WebRTC的建聯(lián)需要信令去幫助交換sdp信息，把它做成公開的信令網(wǎng)關(guān)，也就是一個(gè)公開的http地址，瀏覽器可以發(fā)送offer給它，然后它把a(bǔ)nswer的sdp返回給瀏覽器。

之后瀏覽器跟一個(gè)CDN的節(jié)點(diǎn)產(chǎn)生了單向的推流send連接、RTC的連接，就可以把音視頻流推給CDN節(jié)點(diǎn)，WHIP協(xié)議以及國(guó)內(nèi)的超低延遲的直播協(xié)議大概是這樣的流程。

這樣做的第一個(gè)好處是明顯縮短了整個(gè)方案的鏈路，第二是使用標(biāo)準(zhǔn)的RTC協(xié)議接入，能夠降低整個(gè)推流的延遲，沒有中間的環(huán)節(jié)，最后是信令流程大幅簡(jiǎn)化，應(yīng)用的復(fù)雜度得到很大的降低，因?yàn)椴恍枰惶缀軓?fù)雜的信令系統(tǒng)，比如RTMP推流本身就沒有信令，不需要去設(shè)計(jì)一些特別復(fù)雜的信令指令來控制，所以流程上有大幅的簡(jiǎn)化。

但是協(xié)議上線后還是遇到一些問題，主要是畫質(zhì)方面，用戶反饋文字經(jīng)常模糊、網(wǎng)絡(luò)抖動(dòng)時(shí)分辨率會(huì)降低、起播的時(shí)候有長(zhǎng)時(shí)間的畫面模糊的情況。

由于是在網(wǎng)不太好的情況下，容易出現(xiàn)這些問題，于是我們找了一個(gè)辦法，media string track 上有一個(gè)ContentHint，ContentHint這個(gè)屬性可以提高畫質(zhì)，但是這個(gè)屬性的本質(zhì)是什么呢？在網(wǎng)不好的情況下，意味著不可能以當(dāng)前的碼率去發(fā)送，一定要降級(jí)，而降級(jí)有兩個(gè)方向，一個(gè)方向是畫面模糊的碼率低，另一個(gè)方向是幀率低一點(diǎn)，使用ContentHint，關(guān)注細(xì)節(jié)是不會(huì)降低分辨率的，這是降級(jí)方向上的取舍。通過這種方式能夠優(yōu)化一些畫面上的體驗(yàn)。

但是，畫質(zhì)提升的瓶頸并不在這里。因?yàn)閯偛盘岬降腃ontentHint是碼率降低情況下的一種選擇方式，其實(shí)根本問題是為什么碼率會(huì)降？這就要提到GCC帶寬預(yù)計(jì)算法，或者Congestion control，也就是擁塞控制的算法。WebRTC底層用的就是GCC：Google Congestion control，這個(gè)算法有幾種方式：一種是從客戶端來估計(jì)，一種是從服務(wù)端來估計(jì)，在大部分情況下是服務(wù)端來估計(jì)。

這種方式在遇到瞬時(shí)網(wǎng)絡(luò)抖動(dòng)的情況下，碼率會(huì)大幅下降，這是抗算法的具體表現(xiàn)。在實(shí)際測(cè)試中，如果突然給網(wǎng)絡(luò)加一個(gè)100毫秒的延時(shí)，碼率會(huì)有特別大的下降，因?yàn)楫?dāng)時(shí)判斷網(wǎng)絡(luò)不是很好，因此畫面特別模糊。

除此之外，編碼擴(kuò)展性也有一些限制，包括不支持固定的碼率推流，不支持H.265的編碼擴(kuò)展，不支持B幀，不支持AAC編碼。我們知道WebRTC推流不支持AAC，推上去一定是Opus，這意味著需要分發(fā)成其他格式，比如HISA、FA，依賴一個(gè)音頻轉(zhuǎn)碼的服務(wù)將Opus轉(zhuǎn)到AAC，但這特別依賴音頻轉(zhuǎn)碼服務(wù)的穩(wěn)定性。

最后核心問題其實(shí)是WebRTC協(xié)議的關(guān)注點(diǎn)與直播推流技術(shù)場(chǎng)景的關(guān)注點(diǎn)的區(qū)別。WebRTC協(xié)議是為了點(diǎn)對(duì)點(diǎn)的音視頻通話場(chǎng)景而設(shè)計(jì)的，一切成立的基礎(chǔ)是什么？是延遲。如果脫離了300毫秒以內(nèi)的延遲保障，WebRTC就不成立了。因?yàn)橥ㄔ挄r(shí)如果有300毫秒的延遲會(huì)有明顯感知，再高體驗(yàn)感會(huì)變得不好，一旦在擁塞的情況下，為了保證低延遲的流暢性，碼率會(huì)降低。但是對(duì)于直播推流來說，關(guān)注點(diǎn)是穩(wěn)定性、視頻的質(zhì)量，這些可能要通過犧牲延遲來保障。

其實(shí)延遲的加入對(duì)于直播來說也不是問題，我們看到的直播在大多數(shù)情況下有很高的延遲，甚至賽事的直播，即便有幾十秒的延遲也不影響看球，尤其在推流沒有這么大的影響，更多的延遲發(fā)生在播放的buffer延遲。

再回到原來的幾個(gè)問題，我們發(fā)現(xiàn)穩(wěn)定性得到了很好的提升，支持度有一個(gè)公開的協(xié)議，云廠商都會(huì)跟進(jìn)來支持，國(guó)外的廠商也關(guān)注，因此認(rèn)為支持度未來不會(huì)有太大問題。剩下的問題是音畫質(zhì)量可以用，但很難提升。在現(xiàn)有的WebRTC公開協(xié)議上面，如果是native端可能不會(huì)關(guān)注這個(gè)問題，改一改擁塞控制算法，把逼真的東西加上去，就能擴(kuò)展解決。但對(duì)瀏覽器來說，必須要有標(biāo)準(zhǔn)化介入解決問題，但這個(gè)過程比較漫長(zhǎng)。

接下來我們進(jìn)入下一個(gè)話題，有沒有比WebRTC更加適合Web推流的傳輸協(xié)議呢？之前是沒有的，但是后來我們發(fā)現(xiàn)了WebTransport。

-03-

使用WebTransport優(yōu)化畫質(zhì)與功能

我們認(rèn)識(shí)到WebTransport傳輸協(xié)議后，開始嘗試用它來優(yōu)化畫質(zhì)和功能。

簡(jiǎn)單介紹一下WebTransport。WebTransport是一個(gè)基于QUIC底層，又基于TCP這樣不穩(wěn)定傳輸?shù)腢DP的基礎(chǔ)上做了一套可靠傳輸。它最早是用于谷歌內(nèi)部產(chǎn)品連接性能的優(yōu)化。最近HTTP/3用了這套傳輸協(xié)議棧做了一個(gè)公開的協(xié)議，也就是未來下一代的HTTP傳輸協(xié)議會(huì)基于QUIC，HTTP支持可靠和不可靠?jī)煞N模式的開放的網(wǎng)絡(luò)協(xié)議。

那與RTC相比，這兩個(gè)技術(shù)棧的區(qū)別是什么呢？WebRTC為了點(diǎn)對(duì)點(diǎn)通信引入了很多的東西，比如ICE的框架是為了解決內(nèi)網(wǎng)發(fā)現(xiàn)的穿透的問題，它與WebTransport這種公開的基于HTTP的協(xié)議要考慮的問題不太一樣，這就是兩者之間最大的區(qū)別。

我們使用WebTransport來看看效果，在加入100毫秒延遲的情況下，整個(gè)畫面會(huì)有明顯的抖動(dòng)，如果是WebTransport，延遲雖然會(huì)增加，但并不影響畫面，這時(shí)Congestion control會(huì)更傾向于加入一定延遲，繼續(xù)保持碼率發(fā)送。這是第一個(gè)場(chǎng)景。

第二個(gè)場(chǎng)景大家可能關(guān)注的較少，是網(wǎng)絡(luò)搶占。網(wǎng)絡(luò)搶占不會(huì)發(fā)生在自己的電腦上，可能會(huì)發(fā)生在如果你在別人的會(huì)議室做一些上行，在占用大量帶寬的情況下，網(wǎng)絡(luò)搶占的場(chǎng)景使用GCC擁塞控制算法的傳輸會(huì)處于絕對(duì)劣勢(shì)。

當(dāng)在1M碼率的情況下，發(fā)現(xiàn)自由搶占時(shí)TCP的傳輸會(huì)搶占掉絕大部分的流。我做了一個(gè)實(shí)驗(yàn)，在3M碼率的情況下，兩個(gè)固定碼率是1.5M的推流，WebTransport能夠更好地保持碼率的穩(wěn)定，但RTC的推流整體碼率會(huì)有下降。

我們還有一個(gè)特別關(guān)心的問題：流暢度。雖然用了另一個(gè)協(xié)議，但RTC本身的優(yōu)勢(shì)就是流暢。我們做了一些實(shí)驗(yàn)室環(huán)境下的測(cè)試，因?yàn)榱鲿扯扔幸惶妆容^規(guī)范的評(píng)估方式，即用低速攝影機(jī)來判斷卡頓。我們發(fā)現(xiàn)在正常網(wǎng)絡(luò)下流暢度沒有問題。

在200毫秒的延遲下，WebTransport推流的流暢度與RTC也能基本保持接近，卡頓率很低，對(duì)用戶來說基本無感知。

但在大量丟包的情況下，RTC展示出了非常好的丟包抗性，減少了很多卡頓。但是對(duì)于可靠傳輸，WebTransport引入了大量推流的卡頓。以上就是WebTransport與RTC在性能上表現(xiàn)的區(qū)別。

我們使用WebTransport還關(guān)注到協(xié)議棧、擴(kuò)展上的優(yōu)勢(shì)。不只是協(xié)議本身的優(yōu)勢(shì)，是它能夠更好地與現(xiàn)有的Web多媒體的單點(diǎn)連接起來，這些單點(diǎn)大家比較關(guān)心，比如WebGPU，元宇宙、3D渲染都要用到WebGPU的資源；WebCodecs是瀏覽器提供的硬件解碼的接口，直接去訪問的解碼器的資源；WebAudio以及WebNN是大家都很關(guān)心的一個(gè)問題：AI在Web生態(tài)上的發(fā)展；最后是WebAssembly，現(xiàn)有的很多功能都需要從native端移植或其他的代碼庫移植，用WebAssembly的方式注入到Web的生態(tài)中。

總結(jié)一下WebTransport的優(yōu)勢(shì)，它只定義了網(wǎng)絡(luò)傳輸?shù)牟糠?，?duì)其他的技術(shù)棧是非常開放的，它能夠更好地與單點(diǎn)進(jìn)行結(jié)合。我們?cè)谧鲞@些事情的串聯(lián)時(shí)，能更好地根據(jù)自己的場(chǎng)景選擇更適合的方案，做更深入的優(yōu)化，這是協(xié)議開放性能的優(yōu)勢(shì)。另外一個(gè)優(yōu)勢(shì)是它能更好地使用多線程。

WebRTC協(xié)議只能在主線程MainThread或GS線程上使用，最多用InsertableStream把一部分的能力pipe到worker的線程上處理，而且解碼不是直接在GS線程上做完了，但代碼的關(guān)注點(diǎn)會(huì)在主線程上跑，包括統(tǒng)計(jì)數(shù)據(jù)的處理、網(wǎng)絡(luò)的處理，都會(huì)在GS線程上。

但如果使用WebTransport，只需要關(guān)注采集在主線程上跑之后，把流放到Worker線程就能夠走完，從處理編碼到網(wǎng)絡(luò)傳輸?shù)恼麄€(gè)環(huán)節(jié)，所有的工作在一個(gè)Worker里解決就可以了。我們測(cè)試到性能上有比較明顯的提升，還有一個(gè)非常大的好處是應(yīng)用的擴(kuò)展性會(huì)變得更好。

如果媒體的任務(wù)都能在Worker里面做完，當(dāng)有多個(gè)任務(wù)的時(shí)候，抽象起來是非常容易的，只需要在多個(gè)Worker之間做切換，或者再定義更多的Worker去處理不同的任務(wù)，在Worker之間傳遞資源，以上是在應(yīng)用擴(kuò)展性上的優(yōu)勢(shì)。

最后說一下WebTransport協(xié)議本身的優(yōu)勢(shì)，因?yàn)閃ebTransport底層基于QUIC，所以QUIC能享受到的能力上的優(yōu)勢(shì)，WebTransport自然也會(huì)有，即它會(huì)比TCP的連接快1-2個(gè)RTT，優(yōu)化的原因是它內(nèi)置了TLS1.3，可以在1個(gè)RTT之間做完一個(gè)加密連接的握手，這是WebTransport協(xié)議一個(gè)明顯的優(yōu)勢(shì)。

如果已經(jīng)建立過連接了，刷新頁面會(huì)重新去連接，因?yàn)橛芯彺婺苡洃浿暗倪B接，在這種情況下，可以做到1個(gè)0RTT，也就是一次握手就能把連接重新恢復(fù)回來。根據(jù)Google在上QUIC時(shí)的實(shí)驗(yàn)數(shù)據(jù)，Youtube平臺(tái)上大量的連接都可以使用到0RTT。

還有一個(gè)值得關(guān)注的連接遷移的優(yōu)勢(shì)。什么是連接遷移呢？一個(gè)應(yīng)用在兩個(gè)不同獨(dú)立的網(wǎng)絡(luò)之間做切換的時(shí)候，不需要再做額外的協(xié)商工作，可以無縫的把之前的連接狀態(tài)帶過去。

這是如何做到的呢？其實(shí)是在上一個(gè)連接的時(shí)候已經(jīng)協(xié)商好了，以一個(gè)Connection ID來定義連接，在下一次連接的時(shí)候，如果是之前協(xié)商好的Connection ID，連接的切換是無縫的。雖然連接遷移目前在瀏覽器上還不work，但協(xié)議定義的部分是有包含的。

如果網(wǎng)特別不好，開手機(jī)熱點(diǎn)時(shí)遷移會(huì)更加絲滑，這是連接遷移帶來的一些體驗(yàn)上的可能性，看未來的實(shí)現(xiàn)能不能解決這一點(diǎn)。

我們?cè)趯?shí)現(xiàn)的過程中也遇到了一些技術(shù)上的挑戰(zhàn)。第一個(gè)是AAC編碼在瀏覽器上沒有合適的解決方案，雖然有WebCodecs編碼，但只定義了AAC作為規(guī)范，沒有實(shí)際的提供AAC的編碼。最后我們選用WebAssembly打了libFaac來做音頻的編碼。

另外一個(gè)挑戰(zhàn)是格式封裝，熟悉Web生態(tài)的同學(xué)應(yīng)該知道，大部分處理flv的場(chǎng)景是Demux，從flv數(shù)據(jù)到原始的H264數(shù)據(jù)，但是從264數(shù)據(jù)到flv數(shù)據(jù)，這條鏈路似乎沒人做過。如果用FFmpeg來做，再用WebAssembly顯然是很不合算的，因?yàn)樗炔缓盟悖壿嬕矝]有那么復(fù)雜。所以我們最終用Typescript重新寫了一個(gè)，在這個(gè)過程中要處理設(shè)備在采集時(shí)很可能會(huì)產(chǎn)生音畫不同步的問題，需要從時(shí)間上嘗試去兼容。

以上就是WebTransport推流的整體流程，從采集開始使用WebCodecs和WebAssembly編音視頻的數(shù)據(jù)，做一次數(shù)據(jù)封裝后就可以交給WebTransport封裝成FLV的數(shù)據(jù)，發(fā)送給CDN，這與現(xiàn)有的RTMP的協(xié)議是親和度非常高。這一切都可以在一個(gè)WebWorker里發(fā)生，這意味著擴(kuò)展性在未來可以得到比較好的保障。

最后依照慣例帶入問題來看，穩(wěn)定性和音畫質(zhì)量都得到了比較好的解決。支持度，如果只有一個(gè)CDN支持，它能分發(fā)的面是比較窄的，能量比較小，要把它作為公開的協(xié)議推廣出去，讓廠商幫助我們適配來支持。

我們最終得到了三個(gè)方案，最早的WebRTC轉(zhuǎn)推RTPM、RTC直推CDN和WebTransport推流。每個(gè)方案其實(shí)都有各自的問題，在Web上做事很難馬上有一個(gè)特別完美的解決方案，所以我們要根據(jù)不同的場(chǎng)景來使用不同的解決方案。比如WebRTC轉(zhuǎn)推，在嘉賓連麥的情況下，可以使用這種方案；如果你對(duì)延遲特別敏感，想要一秒以內(nèi)的低延遲的推拉流，可以使用RTC直推；如果對(duì)畫質(zhì)有一些體驗(yàn)上的要求，研發(fā)實(shí)力比較強(qiáng)的話，可以使用WebTransport推流。

-04-

展望未來技術(shù)發(fā)展

其實(shí)這條路走下來還是比較坎坷的，接下來我們看一看未來這條路該怎么走，我認(rèn)為未來Web多媒體的技術(shù)棧會(huì)呈現(xiàn)非常多樣的發(fā)展。

在解決很多單點(diǎn)的問題時(shí)，我們有很多的方案。最近的規(guī)范比較在意規(guī)范之間的可互通性，比如將ABC三個(gè)技術(shù)組合起來，或BCD三個(gè)技術(shù)組合起來實(shí)現(xiàn)一個(gè)場(chǎng)景下的問題，這時(shí)我們的能力在單點(diǎn)上做的更好，互通做應(yīng)用的可能性也會(huì)更多，再輔助于離線應(yīng)用的優(yōu)勢(shì)PWA，也就是可以把一個(gè)網(wǎng)頁變成桌面上的應(yīng)用，并不需要實(shí)際下載什么東西。PWA離線應(yīng)用可以做出更多的準(zhǔn)專業(yè)級(jí)甚至于未來專業(yè)級(jí)的Web多媒體的處理應(yīng)用，比如播放、剪輯、推流等應(yīng)用。我特別期待看到有更多的Web應(yīng)用能夠在更多的業(yè)務(wù)場(chǎng)景里被專業(yè)的場(chǎng)景依賴，變成一個(gè)非常重頭的產(chǎn)品。以上是我對(duì)未來的多媒體技術(shù)棧的展望。

去年Quest pro發(fā)布時(shí)讓我看到了PWA的可能性，它集成了很多微軟的產(chǎn)品，包括XBOX、Office都是以PWA集成進(jìn)去的。因?yàn)檫w移成本很低，相當(dāng)于是內(nèi)嵌的一個(gè)網(wǎng)頁應(yīng)用，但又不需要實(shí)際下載任何東西。如果把直播推流跟WebXR這類的應(yīng)用結(jié)合起來，相當(dāng)于在頭顯里有一個(gè)PWA的應(yīng)用，可以把頭顯里面的畫面推流發(fā)送出來。結(jié)合元宇宙的概念，可以做反向串流，從頭顯再串流到直播。

最后我希望WebTransport成為CDN普遍支持的推流協(xié)議，因?yàn)樗牟渴鸪杀痉浅５?，它是基于公開協(xié)議HTTP/3的。希望未來更多的廠商支持WebTransport推流。

編輯：黃飛

?