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

文 / 沈悅時

整理 / LiveVideoStack

本次分享的內容包括以下幾個方面：

1、Twitch.tv的介紹；

2、互動性：互動直播和傳統電視的區別；

3、點對點 vs. 廣播：延時、可擴展性以及服務質量之間的利弊權衡；

4、推流 vs. 拉流：依然是延時、可擴展性以及服務質量之間的利弊權衡；

5、協議：HLS 加 HTTP Chunked Transfer Encoding；

6、后臺：每個環節都得嚴格遵守紀律；

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

8、總結；

1、Twitch.tv的介紹

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

1.?Twitch.tv的內容和用戶社區

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

2. Twitch的成長歷程

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

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

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

2、互動性：互動直播和傳統電視的區別

在前面也有提到互動直播和傳統電視是有很大區別的，主要就在于互動性，而要實現互動性的一個關鍵技術就是要做到低延時。正因為有了低時延，也導致衍生了一些新的商業模式，比如Twitch 的Extension，就是說低延時可以實現主播和眾多觀眾一起參與游戲。

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

?

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

3、點對點 vs. 廣播

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

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

?

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

4、推流 vs. 拉流

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

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

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

5、協議

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

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

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

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

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

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

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

6、后臺：每個環節都得嚴格遵守紀律

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

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

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

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

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

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

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

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

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

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

多，如下圖。

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

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

8、總結

總結一下本次分享的幾點主要內容：

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

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

在不犧牲可擴展性和服務質量的前提下，Twitch仍然使用HLS來實現低延時廣播。我們控制整條視頻上載、分發的管道，同時對后臺和前臺做創新性的優化；

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

精品文章推薦

線上分享：

• 快手QoE指標設計的分析初探

• 劉歧：FFmpeg Filter深度應用

• FFmpeg Maintainer趙軍：FFmpeg關鍵組件與硬件加速

• 手淘H265編解碼算法與工程優化

• 傅德良：選擇視頻編碼器的誤區

技術趨勢：

• UDP成為低延時流媒體關鍵 選SRT還是QUIC？

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

• CMAF將在2019年得到快速發展

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。