在不犧牲服務(wù)質(zhì)量（卡頓率、畫面清晰度）的前提下，越低的延時能帶來越好的互動性用戶體驗。為達成可擴展性、服務(wù)質(zhì)量、互動性的三贏，Twitch團隊研發(fā)了基于HLS格式的低延時互動直播技術(shù)。本文來自Twitch Principal Research Engineer沈悅時在LiveVideoStackCon 2018大會上的分享，并由LiveVideoStack整理而成。

文 / 沈悅時

整理 / LiveVideoStack

本次分享的內(nèi)容包括以下幾個方面：

1、Twitch.tv的介紹；

2、互動性：互動直播和傳統(tǒng)電視的區(qū)別；

3、點對點 vs. 廣播：延時、可擴展性以及服務(wù)質(zhì)量之間的利弊權(quán)衡；

4、推流 vs. 拉流：依然是延時、可擴展性以及服務(wù)質(zhì)量之間的利弊權(quán)衡；

5、協(xié)議：HLS 加 HTTP Chunked Transfer Encoding；

6、后臺：每個環(huán)節(jié)都得嚴(yán)格遵守紀(jì)律；

7、前臺：ABR變得更難，瓶頸是帶寬估計；

8、總結(jié)；

1、Twitch.tv的介紹

Twitch.tv是中國市場以外最大的互動直播平臺，它的模式和國內(nèi)的虎牙、斗魚直播是類似的。從技術(shù)上來說，Twitch對廣播產(chǎn)業(yè)的價值是最大程度地降低了廣播的技術(shù)壁壘，只要你家里有個很簡單的設(shè)備你就可以廣播，實現(xiàn)互動的網(wǎng)上直播。

1.?Twitch.tv的內(nèi)容和用戶社區(qū)

從用戶社區(qū)上來說，Twitch.tv的用戶社區(qū)是面向全球范圍的，但最多的用戶量集中在歐美地區(qū)；從直播內(nèi)容上來說，Twitch.tv的內(nèi)容和國內(nèi)的虎牙、斗魚直播非常相似，主要是以游戲為主。

2. Twitch的成長歷程

Twitch于2011年開始創(chuàng)立，大概在2013年開始火起來的，從上圖也可以看出，Alexa（評估網(wǎng)站受歡迎程度的第三方網(wǎng)站）通過統(tǒng)計單個用戶每天的訪問量和每個用戶的訪問頁面次數(shù)，Twitch的受歡迎程度是排在全球第32位。這個排名自從2011年創(chuàng)立公司以來節(jié)節(jié)攀升。

下面這張圖是我們2017年統(tǒng)計的真實觀看量數(shù)據(jù)，每天的活動量大概在1500萬左右，每月的活動量大約是1億左右。另外，就在今年，在E3上統(tǒng)計得出Twitch的單個頻道訪問量超過了1700萬，同時在線觀眾數(shù)達到了290萬，這也創(chuàng)造了新的記錄。

順便給大家提一下，Twitch上最紅的一個主播——Ninja，他是第一個上ESPN雜志頭版頭條封面的電子競技玩家。

2、互動性：互動直播和傳統(tǒng)電視的區(qū)別

在前面也有提到互動直播和傳統(tǒng)電視是有很大區(qū)別的，主要就在于互動性，而要實現(xiàn)互動性的一個關(guān)鍵技術(shù)就是要做到低延時。正因為有了低時延，也導(dǎo)致衍生了一些新的商業(yè)模式，比如Twitch 的Extension，就是說低延時可以實現(xiàn)主播和眾多觀眾一起參與游戲。

Extension指的是我們的主播跟觀眾同時在一起打游戲，在主播直播游戲的過程中，會有一些接口開放給觀眾，比如上圖的場景下，參與游戲的有10個人，主播需要去解救十個人當(dāng)中的某一個人，要去救誰呢？這個不是由主播來決定的，而是他的觀眾來投票決定的，因為有了低延時，就能讓主播和觀眾實時互動起來，這是一種全新的商業(yè)模式。

?

從心理學(xué)上來講，如果你要實現(xiàn)對話，延時必須在400毫秒以內(nèi)，不然就進行不下去了，這也說明了低延時對于互動的重要性。下面將從三個方面來介紹我們Twitch是如何做到低延時的。

3、點對點 vs. 廣播

首先我們要理清的一點就是點對點和廣播是完全兩碼事，在流媒體中針對應(yīng)用的利弊權(quán)衡是有三個方面的考量因素的：低延時、高可擴展性和高服務(wù)質(zhì)量。對于Twitch，首先是要求有很高的可擴展性，因為它的同時在線人數(shù)多，要求單個用戶的成本很低，這就是它的高擴展性；同時，它還要求比較高的觀看質(zhì)量，就像看春晚一樣，不能總是低清、卡頓的，但往往高的觀看質(zhì)量會犧牲一定的延時；在網(wǎng)上做直播的用DASH、HLS延時往往有30秒到60秒是很平常的，但這也給了很多人誤解，認(rèn)為HLS延時就一定很高，希望本次的分享能夠打破這種偏見。

但對于點對點的應(yīng)用，比如電話會議、Facetime，它是一定要求低延時的，不能超過400毫秒，最好在200毫秒以內(nèi)；與此同時，它犧牲了可擴展性，比如，今年Facetime給出的最多在線人數(shù)是32人，一般的電話會議軟件也就不到100人，而像Twitch上比較火的網(wǎng)紅一般同時觀看人數(shù)都有10萬左右。而且，點對點在服務(wù)質(zhì)量上是有一定犧牲的，比如連麥的過程中，要求比較高的低延時，對畫質(zhì)、卡頓率就沒有那么高的要求了。因此，不能把點對點生搬硬套在互動直播的應(yīng)用上去。

?

如上圖所示的紫線部分，我們Twitch首先要求高的可擴展性，只要能容下足夠多的用戶，才能生存下去；同時，我們還要提高用戶體驗，就是希望畫質(zhì)越來越好，卡頓率要很低；在這個基礎(chǔ)上，我們同時還想把這個延時降的很低，把傳統(tǒng)的線性電視跟點對點的優(yōu)點結(jié)合起來，后續(xù)會為大家介紹，為了做到這些我們做了哪些工作。 另外提一下我們Twitch上的大網(wǎng)紅Ninja，他是我們Twitch最大的低延時廣播頻道，低延時是1.2秒。下面先從推流和拉流的區(qū)別上來說明一下，中美互動直播的不同。

4、推流 vs. 拉流

對于推流和拉流方式的選擇上同樣要考慮上述的三個因素，依然是延時、可擴展性以及服務(wù)質(zhì)量之間的利弊權(quán)衡。先來看一幅圖，就能看出架構(gòu)的不同：

在中國最常見的就是用RTMP來推流，推流的意思就是說，在主播端，他把內(nèi)容一幀一幀往轉(zhuǎn)碼器里面放，轉(zhuǎn)碼后發(fā)往源站，源站收到了流后就會不斷地往播放器發(fā)，也就是說，它有一幀就往外發(fā)一幀。RTMP推流有個顯著的特點就是低延時且低擴展性。

Twitch采用的是用HLS拉流，在前面同樣是用RTMP來將流推到轉(zhuǎn)碼器，在轉(zhuǎn)碼器里會把一個連續(xù)的流切成片，我們Twitch是兩秒鐘一片，Facebook和YouTube是一秒鐘一片，這個也是質(zhì)量、低延時和HTTP之間請求數(shù)量的一個權(quán)衡。轉(zhuǎn)碼器或源站把連續(xù)的RTMP流轉(zhuǎn)碼后切成一秒或者兩秒的片存在那里，它是不會主動的把流推給播放器的。只有播放器收到一個播放清單（Playlist），它再去向它的最終節(jié)點，一層一層的往源站去做請求。對于推流是后臺主動做的，而對于拉流是后臺被動做的，播放端是主動的。RTMP是一個相對來說，低延時但成本比較高，與此相反，HLS是成本比較低但延時比較高。在這里插一個小故事，Twitch是2011年創(chuàng)業(yè)成立的，最開始都采用的是RTMP來推流，在2013年由于用戶的增多，我們的錢卻虧得越來越多了而大面積裁員。就在那個時候，我們將RTMP換為HLS才扭虧為盈，然后我們那個時候算了一下，如果一臺單機服務(wù)器，在同樣的CPU、內(nèi)存的情況下，用RTMP推流和HLS拉流來比，它的密度是1：5的關(guān)系，用HLS還有個好處就是可以做碼率自適應(yīng)播放（ABR），這個細(xì)節(jié)等會再解釋，它的好處就是讓很多的弱網(wǎng)情況下觀眾有個更好的觀看體驗，但是有個非常壞的地方就是延遲增加到了10秒，下面再給大家介紹我們?yōu)榱私档脱訒r做了哪些改進。

5、協(xié)議

在協(xié)議上，我們采用的是HLS 加 HTTP Chunked Transfer Encoding。

在這里我先介紹一下我們Twitch整個的從端到端的互動直播架構(gòu)：

直播的延時計算的是從光打到攝像機的那一刻到光從熒幕射到看的人的眼睛里面之間的時間差。在這個過程當(dāng)中，首先就是主播用OBS推流工具和采集工具將一個RTMP流發(fā)送到就近的互聯(lián)網(wǎng)服務(wù)器，再通過我們的主干網(wǎng)把它傳到中心的轉(zhuǎn)碼服務(wù)器，從轉(zhuǎn)碼服務(wù)器把它切成一秒或者兩秒的片，再把它再放到源站上，通過我們內(nèi)部的骨干網(wǎng)一步一步把它分發(fā)，再通過最終節(jié)點連接觀看者的互聯(lián)網(wǎng)，最終通過我們自己自建的這個播放器把解碼顯示出來。在這個流水線當(dāng)中，轉(zhuǎn)碼器和播放器都是我們自己開發(fā)的軟件，而且我們有自己的私有云，這可能也是中國跟美國不太一樣，中國的互動直播平臺大多都是用公有云，而美國的互動直播平臺基本都是私有云。

HTTP1.1協(xié)議里面有個東西叫做Chunked Transfer Encoding，在前面介紹有提到，在RTMP流到轉(zhuǎn)碼器后會被截成一個一秒或兩秒的片，在所有的分片收好后會放到服務(wù)器上等待播放器來請求它。

但其實我們想，當(dāng)一個分片生產(chǎn)好時，在等待其他的分片都生產(chǎn)好的過程中，這個兩秒鐘就浪費了，我們完全可以在這個過程中節(jié)省出兩秒。就是說，當(dāng)我在這個片剛生產(chǎn)好的時候，就在其他分片還在生產(chǎn)的過程，它就前面的這些已經(jīng)推給這個播放端了，會達到一個什么效果呢？對于一個Segment來說，它的生產(chǎn)和發(fā)送還有它的播放是同步的，如下圖所示，內(nèi)容生產(chǎn)、分發(fā)、播放是緊密同步的。如果要達到低延時，如下圖中綠色劃出部分，每兩秒鐘的一個片，我都僅僅花兩秒鐘來下載，它下載的時間是非常整齊劃一的。

那么我的毫秒都花在哪兒了呢？在下圖中列出了上述架構(gòu)中幾個步驟在采用HTTP Chunked Transfer Encoding和不采用的情況下的時延對比：

除了在轉(zhuǎn)碼器部分降低到0.5秒，我們在播放清單和播放器緩沖方面也做了很多的優(yōu)化工作，最終端到端的延遲降低到了4.45秒。我們Twitch已經(jīng)上線了，很多網(wǎng)紅也在用著低延時，但最重要的是如何把低延時實現(xiàn)出來，下面我將在分后臺和前臺兩個方面來介紹低延時的實現(xiàn)。

6、后臺：每個環(huán)節(jié)都得嚴(yán)格遵守紀(jì)律

在前面瀏覽器的例子中，我們可以看出每兩秒鐘的一分片，它都要花兩秒鐘來下載，不能多也不能少，如果它稍微有些波動的話，這個波動就會到你的緩存里面去，就讓你的這個時延給增加了，因此，在整個CDN拓?fù)浣Y(jié)構(gòu)里每個節(jié)點它都要非常守紀(jì)律，下面有一個后臺穩(wěn)定性檢查的例子，統(tǒng)計了一臺分發(fā)服務(wù)器上HTTP請求時間的情況：

另外，給大家提一點的就是，Twitch的直播轉(zhuǎn)碼器是我們開發(fā)的，而不是采用的FFmpeg，因為FFmpeg不太適合做直播的轉(zhuǎn)碼，它可能做離線的轉(zhuǎn)碼是OK的，但做直播轉(zhuǎn)碼性能不是最優(yōu)。

直播轉(zhuǎn)碼器的功能就是將收進的1080p60的流，然后出去的流是1080p60到160p30，以此來滿足不同的網(wǎng)絡(luò)帶寬的用戶需求。稍微提一點，對于出去的1080p60的流我們是不做轉(zhuǎn)碼的，而是做的轉(zhuǎn)封裝。

此外，HLS轉(zhuǎn)碼器的輸出必須是對齊的分片，為了HLS它能夠上下做ABR的切換，要求每個分片的起始的IDR幀在PTS上面一定要對齊的，如果不對齊的話，不同碼率切換就不是無縫切換。

最后，對于基于分片和基于幀的實時轉(zhuǎn)碼器要有一定的區(qū)分，最簡單的區(qū)分就是基于分片的實時轉(zhuǎn)碼器會在最后生成很多幀，而基于幀的實時轉(zhuǎn)碼器是收一幀最后生成出一幀。

基于幀的實時轉(zhuǎn)碼器會有一個問題，在進行1080p轉(zhuǎn)封裝、720p轉(zhuǎn)碼、480p轉(zhuǎn)碼的過程中都是獨立存在的，它互相是不知道對方的。

也就是說，每一幀的PTS和DTS都是自己的，如果時延沒有同步的話，會導(dǎo)致IDR幀出來的時間是不一樣的，那么這個分片起始幀就不是IDR，那你的片就不能播了。

7、前臺：ABR變得更難，瓶頸是帶寬估計

在前面介紹的是后臺的相關(guān)東西，其實HLS低延時真正難的地方在于前臺這一塊，主要是前臺的ABR。播放器的播放過程是，在播放時會不斷請求發(fā)送分片，轉(zhuǎn)碼器會把一片里面的一幀一幀往那邊推，推了以后，播放器會收這些幀，收完了以后還再轉(zhuǎn)封裝。

ABR有一個公式，會通過當(dāng)前的帶寬大小、播放器緩存情況等等判斷請求下一個切片的大小，它會做出一個決策來判斷下一個片應(yīng)該是去播1080p，還是應(yīng)該下調(diào)到480p。在這個過程中，ABR會不斷的偵測帶寬的大小，判斷現(xiàn)在的帶寬能否播放當(dāng)前的碼率，是否在下一次需要請求低碼率的分片。對于分片下載，計算下載速度是很容易的，當(dāng)我的一個兩秒的視頻，下載下來需要0.5秒時，這說明帶寬是視頻碼率的四倍，但帶寬的大小預(yù)測這一塊有個問題就是，在帶寬充分的情況下，兩秒鐘的一個分片永遠(yuǎn)是花兩秒鐘來下載的，這就無法計算真實的帶寬有多大，如果減小采樣間隔，將下載速度打印出來會發(fā)現(xiàn)噪音非常的

多，如下圖。

所以我們現(xiàn)在就面臨這么一個難題，在充足帶寬情況下，比如，帶寬到底是10Mbps還是20Mbps，這個是我們在做基于HLS低延時的一個最頭疼的一個問題。還有更糟糕的情況，在有的播放端會缺乏Streams API的支持，導(dǎo)致無法獲取客戶端的打印信息。

對于Firefox這個問題是可以解決的，因為我們跟他們團隊有合作，從64版開始，他們就會把這個開關(guān)打開，那么我們現(xiàn)有的算法應(yīng)該就可以工作了。

8、總結(jié)

總結(jié)一下本次分享的幾點主要內(nèi)容：

低延時的直播能實現(xiàn)主播和觀眾之間的強互動性，然而具有可擴展的低延時實時廣播和點對點的低延時實時通訊是兩個完全不同的工程問題；

推流（RTMP）的優(yōu)勢是低延遲，而拉流（HLS、DASH）的優(yōu)勢是低成本和ABR；

在不犧牲可擴展性和服務(wù)質(zhì)量的前提下，Twitch仍然使用HLS來實現(xiàn)低延時廣播。我們控制整條視頻上載、分發(fā)的管道，同時對后臺和前臺做創(chuàng)新性的優(yōu)化；

HTTP Chunked Transfer Encoding被用在全棧的轉(zhuǎn)碼、源站、中間節(jié)點、邊緣節(jié)點以及播放器。這樣才能實現(xiàn)中位值<4.5秒的端到端延時，其中包括轉(zhuǎn)碼的<0.5秒以及播放器的<2.5秒。

精品文章推薦

線上分享：

• 快手QoE指標(biāo)設(shè)計的分析初探

• 劉歧：FFmpeg Filter深度應(yīng)用

• FFmpeg Maintainer趙軍：FFmpeg關(guān)鍵組件與硬件加速

• 手淘H265編解碼算法與工程優(yōu)化

• 傅德良：選擇視頻編碼器的誤區(qū)

技術(shù)趨勢：

• UDP成為低延時流媒體關(guān)鍵 選SRT還是QUIC？

• BBR如何讓Spotify流媒體更流暢？

• CMAF將在2019年得到快速發(fā)展

• YouTube高效傳輸策略：節(jié)省14%帶寬 用戶體驗提升

總結(jié)

以上是生活随笔為你收集整理的基于HLS格式的低延时互动直播技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。