編者按：通過網絡支持的實時音視頻通話已成為人們日常生活和辦公中必不可少的一部分，對于音視頻領域的網絡技術要求也越來越高。對此，LiveVideoStack特別邀請到了來自美國Paramount Global的張博老師，他以《利用WebTransport進行現場視頻流注入》為題來進行相關內容分享。

大家好，我叫張博，目前在美國波士頓，供職于美國Paramount Global公司。Paramount是美國五大電影制片公司之一，國內叫派拉蒙影視。Pluto TV是它旗下的一個streaming service流媒體。我是負責視頻編碼和播放系統設計的架構師。在此之前，我還供職于其它的視頻技術公司，包括Fubo TV，Brightcove，Ericsson。在供職于Brightcove公司期間，我曾擔任過多個國際視頻制定標準委員會的委員，包括MPEG，INCITS L3.1，DASH Industry工業論壇和CTA-WAVE，并且曾經參與過MPEG-DASH和MPEG-CMAF標準的制定工作，我還曾經參與Brightcove公司著名的Zencoder編碼系統和開源視頻播放器Video.js的開發工作。

今天我要講的話題是利用WebTransport進行現場視頻流注入，英文叫Live Video Ingest via WebTransport。Pluto TV是Paramount旗下的一個流媒體服務。Paramount公司有自己的院線、電影院和streaming service，因此我們線上線下都有放送的平臺。Pluto TV不需要交會員費，我們是完全通過廣告的營收來支持營運。Pluto TV大概有幾百個頻道，其中包括Paramount下屬的其它傳統電視頻道（比如CBS新聞網絡，Nickelodean，Showtime），另外也包括一些由眾多單個VoD內容串聯起來的虛擬直播頻道。我們基本上都是靠廣告營收，在廣告上有很多創新。不過今天我要講的話題跟我的工作其實沒有關系。我們也有一部分的現場直播的頻道應用，但是現在還沒有運用到WebTransport，因為WebTransport是一個比較新的技術，2019年才正式制定出版協議上線，現在還是在一個定稿階段。

我今天演講分為三個部分：首先是對WebTransport的簡單介紹；接下來會分享我提出的一個新的方法：利用WebTransport進行Live Video Ingest現場視頻流的注入；最后我會做一個概念證明，這個idea提出來以后需要去證明它真的可以被做出來。

01WebTransport簡介

首先是來簡單介紹一下WebTransport。WebTransport是一種基于HTTP/3的新型網絡傳輸協議，它支持以下功能：包括雙向通訊（就通訊雙方可以給對方發送message和datagram）、安全傳輸（所有數據傳輸都是經過TLS加密的），它有兩種數據傳輸模式：一種是基于stream的，類似于TCP的可靠傳輸；還有一種是基于Datagram的快速低延遲傳輸，有點類似于UDP。它還有一個功能是NAT and firewall traversal，它可以穿透NAT和防火墻，支持跨互聯網的傳輸。通常人們把WebTransport跟另外兩個協議進行對比，一個是Websocket，一個是WebRTC。那么Websocket是基于HTTP/2(第二代HTTP協議），WebTransport是基于HTTP/3（第三代的HTTP協議）。一般認為未來WebTransport會取代Websocket用在很多游戲和交互比較多的應用上。WebTransport有很大的發展前景，因為WebTransport基于HTTP/3，所以它比基于HTTP/2的Websocket擁有更快的傳輸速度和更低的延遲。另外一個經常對比的協議就是WebRTC，WebRTC必須要依靠ICE（Interactive Connectivity Establishments）協議來讓通訊雙方知道對方的IP地址和網絡端口，如果通訊雙方沒有直接的網絡連接的話，它還需要通過中間的通信的基礎設施communication infrastructure來建立連接。那么在這一點上Websocket和WebRTC就不如WebTransport，因為它是直接運行在443網絡端口上的，所以它天然具備穿透NAT和防火墻的能力，現有的Web Infrastructure就可以無障礙的支持WebTransport，所以它相較于WebRTC更簡單一些，也更易于部署，不需要額外的基礎設施投資。

WebTransport是運行在HTTP/3和443網絡端口之上的一種Client server協議，和Websocket一樣，每一個連接雙方都會有一個HTTP/3的connection。比如一個傳統Client、一個browser瀏覽器和一個HTTP服務器之間，現有的服務器和客戶端原本就支持HTTP，但是我們現在只需要讓它額外支持WebTransport，通訊雙方就可以具備Websocket和WebTransport的能力，它會先建立一個HTTP/3的connection然后在HTTP的connection里它會允許建立多個WebTransport的session，每一個session都是獨立的傳輸單元，都有自己獨立的session ID。包里面會有一個session ID在header里，這樣的話它就可以區分不同的session。

連接的建立是由連接的發起方通過extended CONNECT method來發起連接的請求，跟Websocket是一樣的。雙方都需要支持WebTransport連接才可以建立。在創建HTTP連接的時候就需要在setting frame里將SETTINGS_ENABLE_ WEBTRANSPORT的參數設置為1。當它看見對方的setting frame里參數被設為1以后，它就知道對方是支持WebTransport的，然后它才會允許連接的建立。流量控制和擁塞控制是由底層的QUIC協議來負責，就是flow control和congesting control。

WebTransport支持單向，也支持雙向數據傳輸，基于TLS的安全數據傳輸可以無障礙穿越NAT和防火墻。它有兩種傳輸模式，一個是stream，一個是datagram。stream支持可靠的、有序的數據傳輸，而Datagram就只管發給對方，它不會重發，也不會流量控制的數據傳輸，所以它的速度會快一些。stream是比較可靠、有序的傳輸。

02利用WebTransport進行現場視頻流注入

第二部分是WebTransport在視頻方面有哪些應用。首先我想到的就是把WebTransport用來進行現場視頻流注入Live Ingest。

圖片是現有傳統的現場視頻流注入方法，有上、中、下三種現有的模式，第一種是最上面的，用RTMP作為視頻注入的媒體，從左到右是視頻源video source，把原始視頻以RTMP流的方式發給ingester注入端，注入端拿到后，把數據給轉碼器和封裝器，封裝器拿到以后把視頻流封裝成DASH和HLS的stream，然后發給origin server，再發給CDN，一直到播放器player。我們知道RTNP是基于TCP的，所以它的延遲會比較大，因為它中間需要做一些buffering，連接的建立也會更費時，一般會有2到3秒的延遲。

WebRTC我不知道國內用的多不多，是只用作live ingest，還是直接對終端用戶進行視頻直播。但是，美國的一些公司把WebRTC作為視頻注入協議，它跟RTMP類似，把原始的視頻流與WebRTC流的格式發給ingester。但是WebRTC比較依賴ICE和底層的infrastructure，所以它的協議更復雜一些，需要額外的基礎設施部署。

最下面的第三種方法在傳統的廣電網絡里面應用比較多，美國傳統的cable broadcast公司是直接使用mpeg-ts和multicast，然后直接把數據從視頻源發給注入端，這個方法的速度很快而且也很穩定，但這個是基于broadcaster也就是廣電的電視網，它的網絡是獨享的，不是共享的公共互聯網，它沒有任何的網絡的jitter，所以它很快。但是OTT的streaming service是不可以享受到紅利的，所以在互聯網中它無法使用，因為互聯網一般是不允許multicast工作的。

基于剛才說的三種模式，我發現它們都有一些各自的問題，那么我想到WebTransport來進行現場直播流注入的基本思路就如上圖所示這樣，首先是視頻源Client serve，注入端就是server，視頻源相對于注入端它是Client，輸入端是server。Client和注入端server建立一個WebTransport的連接，就像中間這樣一個管道，然后Client通過WebTransport管道把mpeg-ts的流或其它格式的視頻流通過管道傳輸給server。WebTransport本身并不對原始的視頻流做任何的修改和優化，它僅僅只是一個管道而已，因為管道具備安全性、較低的延遲，還可以跨越互聯網。所以我們就把視頻源直接通過管道發給注入端，可以讓它更安全、更低延遲地、更及時地傳送到另一端。

WebTransport相對于幾個現有的傳輸方法的優勢是易于部署。因為它是基于HTTP之上的，現有的Web Infrastructure就可以支持，視頻的注入無需額外基礎設施的投資，然后它是基于443端口，所以可以無障礙穿越NAT、防火墻。低延遲是它一個最大的優勢，因為WebTransport有datagram的傳輸方式，而現有的Websocket是沒有的，WebRTC是有的，但它都是UDP、RTP的，需要依賴ICE，所以它可以支持高效、低延遲的傳輸，相對于RTMP和HTTP這兩個基于TCP的協議要具備優勢，因為低延遲對于視頻直播尤為重要。

03概念證明

概念是很簡單的，也沒有很多復雜的概念，但是我需要對我的方法做一個概念證明Proof of Concept。

現有對WebTransport的支持其實并不多，因為第一版協議2019年才提出，那么現在客戶端這邊支持它的瀏覽器只有Chromium，Chromium是Chrome的實驗版本產品，通用版的Chrome都不支持WebTransport。Google有自己的一個簡單的Client和server的WebTransport的實現。Client是用Javascript寫的，它調用Chromium提供的WebTransport API來進行連接的建立和傳輸，然后server是用Python寫的，它調用AIOQUIC庫，是一個Python的QUIC的library，然后我利用Google提供的Client和server的實現做了一個自己的PoC，程序在Github上面可以找到Live Video Ingest via WebTransport。

我的實現PoC的思路是這樣的，首先讓Client程序和server程序建立一個WebTransport的連接然后我會讓Client（一個Javascript的程序，它是基于Google的WebTransport Client）每隔數秒鐘抓取一次攝像頭的視頻，然后我把攝像頭的視頻，封裝成WebM格式，然后Client會將WebM文件通過WebTransport管道發送到server那邊，server拿到WebM文件后把它用FFmpeg轉格式成為MP4文件，然后存到一個webserver目錄下，比如說EngineX的目錄下，然后提供給video player進行下載播放。

那么為什么傳輸格式可以是mpeg-ts，但我要用WebM呢？因為有一些技術上的限制。WebTransport的客戶端僅僅只被瀏覽器支持，那么Client只能是一個Javascript程序，我們無法將FFmpeg生成的mpeg-ts的視頻流發給運行在瀏覽器中的Client，我沒有找到合適的方法來做這件事情，所以我只能用WebM格式進行，流傳輸在我的PoC里面是這樣的，但是我相信將來WebTransport會有更多的本地的native的支持，將來我們可以直接把Web mpeg-ts流直接通過WebRTC，而不需要通過瀏覽器發送到server那端。

具體的實現是我們讓Client調用Chromium提供的API來建立一個與server之間的WebTransport的datagram連接，我之所以采用datagram而不采用stream是因為datagram可以快速地傳輸數據，然后連接建立以后，Client會調用getUserMedia API來抓取攝像頭的視頻，并創建一個video窗口進行本地的視頻播放，然后Client會每隔4秒鐘調用MediaRecorder API抓取的視頻錄制成WebM文件,然后將WebM文件以datagram的形式分段通過WebTransport發給server，每一個datagram的長度是1,200個字節，這由底層協議的最大報文長度決定的，server在收到WebM文件后用FFmpeg把WebM文件轉格式成為MP4格式，然后把它存到server的下載鏈接目錄下，并且server把新文件的HTTP下載鏈接回復給Client，Client拿到鏈接以后就下載MP4文件，然后在另外一個video窗口進行播放，如果我把這兩個video播放窗口并列擺放的話，我們就可以看到整個流程的延遲，即本地視頻是直接播放的，下載的視頻是經過WebTransport和FFmpeg的轉碼再經過HTTP的下載，這三個步驟才可以播放，那么這兩個擺在一起的話就可以看到整個流程的延遲。

下面是一個簡單演示demo。我把server部署在AWS EC2的機器上，Client運行在本地的Chromium瀏覽器上。那么我需要打開443端口并且允許UDP traffic通過。如果以前都是443的話，我們只需要打開TCP。對于QUIC和WebTransport這種協議來說，我們還需要打開UDP的端口以便讓WebTransport datagram能夠到達server那邊。

本來的demo應該運行在AWS上面，但我只有一個免費的那個賬戶，今天的時間已經到了，所以今天我的demo只能運行在本地的機器上面，這是demo的截屏。

我現在就要運行一下demo，窗口是WebTransport的server的Python程序。WebTransport server要讀取本地的certificate就是TLS的certificate和key，我是讓它跑在443端口上面，這本身沒有區別，然后chromium瀏覽器它需要允許特定的IP和端口，然后把Client拿出來，本地窗口抓取的視頻直接播放，然后我點connect server那邊就拿到了連接，然后我這邊開始抓取視頻，ingest注入到server那邊start，然后如果我們等幾秒鐘就能夠看見兩個視頻可以同時收到。那么我們看一下手機上面的時間，延遲大概是有4秒鐘左右，有的時候是4秒，有的時候是3秒，有的時候是2秒因為API時間并不穩定，每一個segment的時間并不穩定。

因為時間有限，我只完成了一個PoC的實現，那么未來我還需要將我的新方法跟其它現有的方法進行比較。那么我很關心的是兩個比較參數，一個是它的延遲，一個是丟包率。因為我知道，我用的是datagram進行數據傳輸，用視頻流注入的延遲會比較低，但是低多少我還得具體去衡量。再一個就是丟包率，因為用datagram的話會有一些丟包，它不保證可靠的傳輸，那么對視頻播放的質量也會有些影響，我要去看具體的影響有多大，然后我再進行一些改進和優化。

審核編輯 ：李倩