直播平台如何使用RTMP實現視頻直播低延遲

借《讓子彈飛》中姜文的名言作為開場白：讓子彈飛一會兒。

某名人吐槽說：還要飛一會兒哪？這子彈的延遲也忒大了。

該名人就是鄙人。

為什麼低延遲很重要？

低延遲的子彈可以擊殺敵軍千米之外，低延遲的直播技術可以秒殺粉絲千里之外。

互動直播技術已經成為直播平台的標配。沒有互動直播技術的直播平台無法躋身直播行業第一梯隊。而要獲得互動直播技術，實現低延遲是必須的。

因此，低延遲很重要。

那麼，直播技術如何實現低延遲呢？

請允許我根據即構科技直播技術的經驗，和各位分享一下如何實現低延遲。

即構科技的連麥互動直播技術，連麥方的延遲400毫秒，觀看方的延遲1秒左右。目前映客直播，花椒直播，一直播和栗子直播都採用了即構科技的連麥互動直播技術。因此，這個直播技術經驗是經過市場驗證的，是從實操中得來的，而不是單憑理論分析得到的。

一般來說，延遲低於800毫秒， 才能夠在直播中連麥，做一些比較高頻的互動，比如相聲或者談話節目。如果延遲高於800毫秒，在直播中連麥的效果就無法被觀眾接受了。因此，延遲400毫秒的直播技術，是有足夠的餘地去實現連麥互動直播業務的。

要在直播技術中實現低延遲，有一個簡單而要務實的哲學：

1）選擇一條最優的路徑；

2）在這條路徑上做到最優；

3）保持所有路徑優質。

下面我將按照這個思路來論述如何實現低延遲。

選擇一條最優的路徑

要選擇一條最優的路徑，有很多方法。目前使用比較多的是網路測速，用戶個人連接數據分析，和用戶群體連接數據分析等幾種方法來選擇最優的網路路徑。

• 網路測速

推流端在推流之前，向各個路徑發送簡單的數據包，然後根據數據包響應的時間來推測哪條路徑最快。這個方法比較簡單，有效然而有限：選出來的路徑只是在該測試時間點最快的，而網路狀況是隨著時間變化的；另外，簡單數據包測出來速度比較快，並不代表流媒體傳輸數據速度也比較快。因此，這個方法得到的結果只能作為一個指標來參考。

• 大數據分析

為了迴避單個採樣時間點測速導致的偏差，可以採取對歷史大數據進行分析，預測哪個網路路徑最優。對歷史大數據進行的分析分為兩個維度：用戶個人連接數據分析和用戶群體連接數據分析。

1）. 用戶個人連接數據分析

每個主播用戶的使用歷史數據是有規律可循的。通過分析這些歷史數據，可以發現主播用戶從哪裡接入，在什麼時候接入，接入到哪個伺服器，走什麼路徑的效果最優。這些歷史數據積累得越豐富，歷史數據分析得出來的結論就越靠譜。這個方法能夠發現個人主播用戶周期性的網路連接情況，能找出大部分時間連接效率最優的網路路徑。然而，這個方法的缺點是：數據採樣只是基於單個用戶，採樣點太少，沒有全局考慮到該用戶所在地區的整體網路連接情況。

2）. 用戶群體連接數據分析

為了彌補用戶個人連接數據分析的不足，這裡引入另外一個維度的數據分析：某地區用戶群體連接數據的分析。針對某用戶所在區域的用戶群進行歷史數據分析，可以發現這個區域網路連接隨著時間變化的規律，找出在不同的時間點，在不同的接入點連接到哪個伺服器最好。

單點網路測速，用戶個人連接數據分析，再加上用戶群體連接數據分析綜合得到結論，就能比較有效地預測哪條路徑最優。選路這部分需要不斷地優化，才能積累豐富的用戶數據，同時適應網路的變化。

在這條路徑上做到最優

選好最優的路徑以後，剩下的就是要在該路徑上做到最優。這條路徑包括了下面幾個環節：採集，編碼，推流，轉碼，分發，拉流，解碼和渲染。在一個實時的音視頻系統架構里，每個環節都會有一定程度的優化空間。行業內的小夥伴在這條路上已經有過很多探索，這裡不想重複討論別人已經探索過的議題，而只重點討論下面幾個關鍵點。

• 選擇協議

傳輸協議的選擇十分重要。傳輸協議一定程度上就決定了延遲的範圍。選擇傳輸協議的時候要考慮是推流端還是拉流端。推流端的協議有RTMP, WebRTC和基於UDP的私有協議。

1）. RTMP是基於TCP的標準協議，CDN網路普遍支持，也能做到相對比較低的延遲。即構科技的互動直播技術在推流端使用RTMP協議，拉流端兼容三種協議：RTMP，HLS和FLV。HLS協議的延遲比較大，在需要進行連麥互動的場景下，不應該使用HLS協議。

2）. WebRTC的好處在於用戶體驗好，不需要安裝東西，分享一個鏈接就可以看。但是它有一個缺點，就是WebRTC是Google推的一項技術，除了Google Chrome和Opera支持WebRTC，其他瀏覽器大部分不支持WebRTC。換一句話說，40%的瀏覽器支持WebRTC，剩下60%瀏覽器不支持，所以適用範圍就比較局限。然後，在中國國內，WebRTC在Google Chrome上的表現也大打折扣。最後，因為瀏覽器沒有開放核心的能力，所以在瀏覽器上運行的協議比較難以做到比較低的延遲。

3）. 基於UDP的私有協議十分適合做實時音視頻系統，它是面向無連接的，避免了TCP做網路質量控制所需要的開銷，能夠做到比較低的延遲。但是它也有一個缺點，那就是私有協議的兼容性不好。CDN支持標準的RTMP協議，但是不支持基於UDP的私有協議。為了吸納UDP的優點，而避免UDP的缺點，即構科技的互動直播技術採用了基於UDP的私有協議作為補充，在有必要的時候用來彌補RTMP協議的不足。比如說，只有在網路環境比較惡劣或者在跨國互通的情況下，才使用基於UDP的私有協議；比如說，只在推流端到媒體伺服器這一段才使用基於UDP的私有協議，而從媒體伺服器轉推流到CDN網路這一段採用RTMP協議，在這兩段之間通過把UDP私有協議轉換成RTMP協議來進行適配和銜接。這樣一來，即構科技的直播方案既擁有超低延遲的優勢，又保留了標準協議普遍被CDN網路支持的好處。

• 前向糾錯和丟包重傳

前向糾錯簡稱FEC，英文全稱Forward Error Correction，是通過提前採取措施來對抗網路損傷。丟包重傳主要針對丟包的情況下，有針對性地對丟失的數據包進行高效率的重傳。準確來說，它們的直接目的不是為了降低延遲，而是為了對抗網路損傷。在不可預測的網路環境中，能很好地處理網路抖動帶來的負面影響，間接也會降低了延遲，同時保證了穩定性和流暢性。一般來說，前向糾錯和丟包重傳互補使用，前者屬於前驗的方法，比較節省時間，但是佔用多餘的帶寬；後者屬於後驗的方法，比較節省帶寬，但是會消耗比較多的時間。在網路比較差情況下，丟包率比較高，那麼可以通過前向糾錯方法來保證信息完整送達。比如說發送冗餘信息，確保在一定丟包率之下，接受方也能準確而完整的還原發送方所要發送的信息。在網路相對比較好的情況下，丟包率比較低，那麼可以通過丟包重傳的方法來保證信息完整送達。比如說針對丟掉的數據包，通過高效的機制進行重傳，確保接受方能夠完整的收到發送方所要發送的消息。

• 緩衝自適應

由於有網路抖動的存在，數據包的到達不是勻速的。最直接的降低延遲的方法就是把緩衝隊列的長度設置為零，接收到什麼數據包就直接渲染什麼數據包，然而這樣做的後果就是播放不流暢，會出現卡頓。因此，延遲和流暢兩者本身就是一對矛盾的因素。我們要做的是尋找低延遲和流暢之間的平衡點，尋找平衡點的有效方法就是建立緩衝隊列。在拉流端和混流伺服器都需要建立緩衝隊列。對於一個實時系統來說，緩衝隊列的長度必須不是固定的，而是自適應的：當網路很好的時候，緩衝隊列的長度就會變得比較短，接近零，甚至為零；當網路不好的情況下，緩衝隊列的長度會變得比較長，但是不能超過能接受的上限，畢竟緩衝隊列的長度本質上就是延遲的時間。另外，還可以把緩衝自適應技術和快播或慢播技術結合起來使用。當網路由差轉好的情況下，可以適當的播得快一點，儘快縮短緩衝隊列的長度。當網路由好轉差的情況下，可以適當的播得慢一點，讓緩衝隊列適當變長，保持流暢性。快播和慢播是結合觀眾的心理學模型，在適合快播和慢播的條件下採用，讓觀眾沒有覺察出播放速度的變化，同時整體感覺也顯得既流暢又低延遲。

• 碼率自適應

由於網路環境的複雜多變，碼率要能自動適應網路狀況的變化，也就是所謂的碼率自適應。 在網路比較差的時候，要降低碼率，讓直播保持低延遲和流暢性；在網路比較好的時候，要提高碼率，讓直播保持高清畫質。為了做到碼率自適應，對協議選擇也很考究。RTMP對碼率自適應能做的事情比較有限，因為它基於TCP, 而TCP 下層已經做了網路質量控制，當網路出現擁塞的時候，上層應用不會及時得到通知。基於UDP的私有協議更加適合做碼率自適應，因為它基於UDP，而UDP只負責發包和收包，把網路質量控制交給應用層來做，這樣應用層會有足夠的空間來實現碼率自適應。

保持所有路徑優質

那麼，為了在直播技術中實現低延遲，要選擇一條最優路徑，還要在該路徑上做到最優。故事講完了嗎？沒有，我們忘記了一個前提：整體的道路網路必須要足夠好。道路網路不好，怎麼選都是爛泥土路，選了爛泥土路，如何能夠跑的快呢？因此，要實現低延遲，網路基建必須要足夠好。網路基建的質量可以通過以下三個方面來提高：

1）. 全網充分覆蓋：一般來說，音視頻雲服務的機房會分布在核心的幾個樞紐城市，邊遠地區的用戶的訪問質量是得不到保障的。另外，在中國國內，各個網路運營商的覆蓋面是參錯不齊的，有些網路運營商對一些邊遠地區也是覆蓋不足的。為了做到全網充分覆蓋，可以採用多節點代理和重定向，來確保全網充分覆蓋無盲點。這個需要經過實際充分測試，才能夠驗證各類網路可以充分連通。

2）. 全方位保障QoE：網路接入點的覆蓋面對QoE（Quality of Experience）十分的重要。從即構科技的經驗來看，通過部署遍布全球範圍的接入點能夠確保這一點。另外，由於在中國國內存在有「兩張大網，多張小網」這樣一個局面，BGP在這種情況下十分有必要。BGP能夠很好地解決不同網路之間的互通問題。即構科技所有的網路接入點都使用了BGP。

3）. 優質的網路節點資源：音視頻雲服務是跑在網路基建上面的，下層網路基建的質量必須要優質，而且音視頻雲服務和下層網路基建也要深度結合。為了實現直播技術的低延遲，最好能對接一線的網路運營商，這樣部署的網路節點資源無論是數量還是質量上都是有充分的保障。這也是即構團隊在與映客直播，花椒直播，一直播和栗子直播等一線直播平台合作的過程中，在騰訊QQ過去十多年海量用戶運營的過程中總結出來的經驗。

綜合來說，要實現直播技術低延遲，必須要選好一條最優的路徑，然後在該路徑上做到最優，最後要確保所有路徑的質量都是好的。道理就是那麼簡單，實現起來就是那麼難，魔鬼都出在細節上。

文章轉載自雷鋒網（閱讀原文）。

作者：冼牛，死磕視頻直播的資深技術人，微信xianniu1216，歡迎交流。

文章同時同步到即構科技微信公眾號zego_tech，陸續推出直播平台技術乾貨。