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

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

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

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

01WebTransport簡(jiǎn)介

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

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

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

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

02利用WebTransport進(jìn)行現(xiàn)場(chǎng)視頻流注入

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

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

WebRTC我不知道國內(nèi)用的多不多，是只用作live ingest，還是直接對(duì)終端用戶進(jìn)行視頻直播。但是，美國的一些公司把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ā)給注入端，這個(gè)方法的速度很快而且也很穩(wěn)定，但這個(gè)是基于broadcaster也就是廣電的電視網(wǎng)，它的網(wǎng)絡(luò)是獨(dú)享的，不是共享的公共互聯(lián)網(wǎng)，它沒有任何的網(wǎng)絡(luò)的jitter，所以它很快。但是OTT的streaming service是不可以享受到紅利的，所以在互聯(lián)網(wǎng)中它無法使用，因?yàn)榛ヂ?lián)網(wǎng)一般是不允許multicast工作的。

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

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

03概念證明

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

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

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

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

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

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

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

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

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

審核編輯 ：李倩