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

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

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

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

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

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

最后一個場景是跟SaaS本身有關系的海外。海外用戶的使用習慣跟國內用戶不太一樣，如果有Web應用，海外用戶一定不會選擇native應用，這是一個很大的使用習慣區(qū)別，也是Web應用目前非常流行的原因。

-02-

技術探索與實踐

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

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

第一，它必須是穩(wěn)定可靠的。因為直播是一對多的場景，一個主播可能有幾萬的用戶在觀看。所以在直播的實時場景下，任何鏈路上的穩(wěn)定性問題，都會造成非常嚴重的用戶體驗的損失。因此穩(wěn)定性放在了第一位。

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

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

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

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

先劇透一下，省流到目前為止不存在銀彈，但探索的過程讓我們在技術選擇上面有更大的空間。

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

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

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

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

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

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

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

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

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

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

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

那為什么WebSocket的信令當時會斷開？

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

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

事故產(chǎn)生的原因是信令，我們就從信令上嘗試解決這個問題。既然是超時導致的斷開，因此第一個方案是把心跳的?；顣r長加到6個小時，因為一般的直播到不了六個小時。這樣能夠保證信令斷開了，但流還保留著，這個方案會是一個好的解決方案嗎？

顯然不是，因為它存在一個很明顯的風險，如果信令斷開了，意味著不只是瀏覽器到服務器的消息沒辦法發(fā)送。如果服務器內部，比如合流有服務的異常，也沒有辦法通過信令再傳達到瀏覽器，也不能再執(zhí)行后面的容災動作了，因此這在當時是一個臨時的解決方案。

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

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

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

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

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

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

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

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

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

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

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

這樣做的第一個好處是明顯縮短了整個方案的鏈路，第二是使用標準的RTC協(xié)議接入，能夠降低整個推流的延遲，沒有中間的環(huán)節(jié)，最后是信令流程大幅簡化，應用的復雜度得到很大的降低，因為不需要一套很復雜的信令系統(tǒng)，比如RTMP推流本身就沒有信令，不需要去設計一些特別復雜的信令指令來控制，所以流程上有大幅的簡化。

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

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

但是，畫質提升的瓶頸并不在這里。因為剛才提到的ContentHint是碼率降低情況下的一種選擇方式，其實根本問題是為什么碼率會降？這就要提到GCC帶寬預計算法，或者Congestion control，也就是擁塞控制的算法。WebRTC底層用的就是GCC：Google Congestion control，這個算法有幾種方式：一種是從客戶端來估計，一種是從服務端來估計，在大部分情況下是服務端來估計。

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

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

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

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

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

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

-03-

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

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

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

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

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

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

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

我們還有一個特別關心的問題：流暢度。雖然用了另一個協(xié)議，但RTC本身的優(yōu)勢就是流暢。我們做了一些實驗室環(huán)境下的測試，因為流暢度有一套比較規(guī)范的評估方式，即用低速攝影機來判斷卡頓。我們發(fā)現(xiàn)在正常網(wǎng)絡下流暢度沒有問題。

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

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

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

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

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

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

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

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

如果已經(jīng)建立過連接了，刷新頁面會重新去連接，因為有緩存能記憶之前的連接，在這種情況下，可以做到1個0RTT，也就是一次握手就能把連接重新恢復回來。根據(jù)Google在上QUIC時的實驗數(shù)據(jù)，Youtube平臺上大量的連接都可以使用到0RTT。

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

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

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

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

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

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

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

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

-04-

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

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

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

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

最后我希望WebTransport成為CDN普遍支持的推流協(xié)議，因為它的部署成本非常低，它是基于公開協(xié)議HTTP/3的。希望未來更多的廠商支持WebTransport推流。

編輯：黃飛

?