編者按：通過網(wǎng)絡(luò)支持的實時音視頻通話已成為人們?nèi)粘Ｉ詈娃k公中必不可少的一部分，對于音視頻領(lǐng)域的網(wǎng)絡(luò)技術(shù)要求也越來越高。對此，LiveVideoStack特別邀請到了來自美國Paramount Global的張博老師，他以《利用WebTransport進行現(xiàn)場視頻流注入》為題來進行相關(guān)內(nèi)容分享。

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

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

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

01WebTransport簡介

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

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

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

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

02利用WebTransport進行現(xiàn)場視頻流注入

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

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

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

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

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

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

03概念證明

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

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

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

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

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

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

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

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

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

審核編輯 ：李倩