隨著直播SaaS業務的深入發展，Web端開播的訴求變得越來越強烈，對比客戶端開播工具如OBS，Web開播與SaaS平臺親和度高，可以讓用戶快速體驗平臺全流程，同時易于分享鏈接，快速連麥。因此，尋求更加穩定可用的Web開播能力成為了一個需要解決的問題。LiveVideoStackCon 2022北京站邀請到了字節跳動的付宇豪老師，為我們分享Web開播系統的技術演進。

大家好，我是付宇豪，來自字節跳動的視頻架構Web多媒體團隊。今天給大家分享的主題是Web開播系統的技術演進，主要講一下字節跳動在Web開播上做的一些技術嘗試和踩過的坑。

首先簡單的介紹一下我自己，我16年畢業于山東大學，17年加入字節跳動，19年開始在Web多媒體團隊做Web多媒體相關的工作。目前負責Web直播技術方向。

?

今天給大家分享的內容，主要分為四個部分。首先是技術的使用場景，為什么要做Web開播，也就是技術的來源；第二是我們在技術探索過程中做的技術嘗試和踩過的坑；第三是使用WebTransport來優化畫質體驗和功能擴展性；最后是對于未來的技術和標準化的展望。

-01-

業務背景與Web開播優勢

首先是第一部分，業務背景。

圖上的數據是直播行業的用戶規模，來自工信院的大數據統計。最早有統計數據的是2016年，因此把2016年稱為直播的元年，當時的場景被稱為千播大戰，每個人的手機里有很多關于直播的App。

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

從數據來看，2020年疫情對于直播SaaS的增長非常快。

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

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

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

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

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

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

-02-

技術探索與實踐

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

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

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

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

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

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

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

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

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

到2020年，Flash已經完全退出了Web生態，主流瀏覽器不再支持。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-03-

使用WebTransport優化畫質與功能

我們認識到WebTransport傳輸協議后，開始嘗試用它來優化畫質和功能。

簡單介紹一下WebTransport。WebTransport是一個基于QUIC底層，又基于TCP這樣不穩定傳輸的UDP的基礎上做了一套可靠傳輸。它最早是用于谷歌內部產品連接性能的優化。最近HTTP/3用了這套傳輸協議棧做了一個公開的協議，也就是未來下一代的HTTP傳輸協議會基于QUIC，HTTP支持可靠和不可靠兩種模式的開放的網絡協議。

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

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

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

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

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

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

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

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

總結一下WebTransport的優勢，它只定義了網絡傳輸的部分，對其他的技術棧是非常開放的，它能夠更好地與單點進行結合。我們在做這些事情的串聯時，能更好地根據自己的場景選擇更適合的方案，做更深入的優化，這是協議開放性能的優勢。另外一個優勢是它能更好地使用多線程。

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

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

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

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

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

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

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

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

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

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

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

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

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

-04-

展望未來技術發展

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

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

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

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

編輯：黃飛

?