關於直播，所有的技術細節都在這裡了（二）

引言

網路視頻直播存在已有很長一段時間，隨著移動上下行帶寬提升及資費的下調，視頻直播被賦予了更多娛樂和社交的屬性，人們享受隨時隨地進行直播和觀看，主播不滿足於單向的直播，觀眾則更渴望互動，直播的打開時間和延遲變成了影響產品功能發展重要指標。那麼，問題來了： 如何實現低延遲、秒開的直播？

先來看看視頻直播的5個關鍵的流程：錄製->編碼->網路傳輸->解碼->播放，每個環節對於直播的延遲都會產生不同程度的影響。這裡重點分析移動設備的情況。受限於技術的成熟度、硬體環境等，我們針對移動場景簡單總結出直播延遲優化的4個點：網路、協議、編解碼、移動終端，並將分四期來一一解密UCloud直播雲實現低延遲、秒開的技術細節。

上篇《關於直播，所有的技術細節都在這裡了（一）》我們講述了如何讓直播內容以「最短」路徑從主播到觀眾上，傳輸層面獲得最低延遲，在本篇中我們會介紹直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析 。

直播協議的選擇

國內常見公開的直播協議有幾個：RTMP、HLS、HDL（HTTP-FLV）、RTP，我們來逐一介紹。

RTMP協議：

是Adobe的專利協議，現在大部分國外的CDN已不支持。在國內流行度很高。原因有幾個方面：

1、開源軟體和開源庫的支持穩定完整。如鬥魚主播常用的OBS軟體，開源的librtmp庫，服務端有nginx-rtmp插件。

2、播放端安裝率高。只要瀏覽器支持FlashPlayer就能非常簡易的播放RTMP的直播，協議詳解可以Google了解。相對其他協議而言，RTMP協議初次建立連接的時候握手過程過於複雜（底層基於TCP，這裡說的是RTMP協議本身的交互），視不同的網路狀況會帶來給首開帶來100ms以上的延遲。基於RTMP的直播一般內容延遲在2~5秒。

HTTP-FLV協議：

即使用HTTP協議流式的傳輸媒體內容。相對於RTMP，HTTP更簡單和廣為人知，而且不擔心被Adobe的專利綁架。內容延遲同樣可以做到2~5秒，打開速度更快，因為HTTP本身沒有複雜的狀態交互。所以從延遲角度來看，HTTP-FLV要優於RTMP。

HLS 協議：

即Http Live Streaming，是由蘋果提出基於HTTP的流媒體傳輸協議。HLS有一個非常大的優點：HTML5可以直接打開播放；這個意味著可以把一個直播鏈接通過微信等轉發分享，不需要安裝任何獨立的APP，有瀏覽器即可，所以流行度很高。社交直播APP，HLS可以說是剛需，下來我們分析下其原理 。

基於HLS的直播流URL是一個m3u8的文件，裡面包含了最近若干個小視頻TS（一種視頻封裝格式，這裡就不擴展介紹）文件，如 http://www.ucloud.cn/helloworld.m3u8 是一個直播留鏈接，其內容如下：

假設列表裡面的包含5個TS文件，每個TS文件包含5秒的視頻內容，那麼整體的延遲就是25秒。當然可以縮短列表的長度和單個TS文件的大小來降低延遲，極致來說可以縮減列表長度為1，1秒內容的m3u8文件，但是極易受網路波動影響造成卡頓。

通過公網的驗證，目前按同城網路可以做到比較好的效果是5~7秒的延遲，也是綜合流暢度和內容延遲的結果。那麼HTML5是否可以有更低延遲直接打開的直播流技術呢？ 我們在最後會探討這個問題。

RTP協議：

即Real-time Transport Protocol，用於Internet上針對多媒體數據流的一種傳輸層協議。

實際應用場景下經常需要RTCP（RTP Control Protocol）配合來使用，可以簡單理解為RTCP傳輸交互控制的信令，RTP傳輸實際的媒體數據。

RTP在視頻監控、視頻會議、IP電話上有廣泛的應用，因為視頻會議、IP電話的一個重要的使用體驗：內容實時性強。

對比與上述3種或實際是2種協議，RTP和它們有一個重要的區別就是默認是使用UDP協議來傳輸數據，而RTMP和HTTP是基於TCP協議傳輸。為什麼UDP 能做到如此實時的效果呢？關於TCP和UDP差別的分析文章一搜一大把，這裡不在贅述，簡單概括：

UDP：單個數據報，不用建立連接，簡單，不可靠，會丟包，會亂序；

TCP：流式，需要建立連接，複雜，可靠 ，有序。

實時音視頻流的場景不需要可靠保障，因此也不需要有重傳的機制，實時的看到圖像聲音，網路抖動時丟了一些內容，畫面模糊和花屏，完全不重要。TCP為了重傳會造成延遲與不同步，如某一截內容因為重傳，導致1秒以後才到，那麼整個對話就延遲了1秒，隨著網路抖動，延遲還會增加成2秒、3秒，如果客戶端播放是不加以處理將嚴重影響直播的體驗。

總結一下：在直播協議的選擇中，如果選擇是RTMP或HTTP-FLV則意味著有2~5秒的內容延遲，但是就打開延遲開，HTTP-FLV 要優於RTMP。HLS則有5~7秒的內容延遲。選擇RTP進行直播則可以做到1秒內的直播延遲。但就目前所了解，各大CDN廠商沒有支持基於RTP直播的，所以目前國內主流還是RTMP或HTTP-FLV。

是否有除了HLS外更低延遲的方案？

HLS的優點點是顯而易見的：移動端無需安裝APP使用兼容HTML5的瀏覽器打開即可觀看，所有主流的移動端瀏覽器基本都支持HTML5，在直播的傳播和體驗上有巨大的優勢。

而看起來唯一的缺點：內容延遲高（這裡也有很多HLS限制沒有提到，比如必須是H264+AAC編碼，也可認為是「缺點」之一）。如果能得到解決，那將會是直播技術非常大的一個進步。或者換個說法，有沒有更低延遲可直接用鏈接傳播的直播方案？不局限於HLS本身。

對於瀏覽器直接的視頻互動，Google一直在推WebRTC，目前已有不少成型的產品出現，可以瀏覽器打開即實時對話、直播。但來看看如下的瀏覽器覆蓋圖：

非常遺憾的說，在直至iOS 9.3上的Safari仍然不能支持WebRTC。繼續我們的探索，那Websocket支持度如何呢？

除了老而不化的Opera Mini外，所有的瀏覽器都支持WebSocket。這似乎是個好消息。梳理一下HTML5 WebSocket直播需要解決的問題：

1、後端兼容

2、傳輸

3、解碼播放

對於#1似乎不是特別大問題，對於做過RTMP轉HLS、RTP來說是基本功。#2對於瀏覽器來說使用HTTP來傳輸是比較好的選項。對於#3 這裡推薦一個開源的JS解碼項目jsmpeg: GitHub - phoboslab/jsmpeg: MPEG1 Video Decoder in JavaScript，裡面已有一個用於直播的stream-server.js的NodeJS伺服器。

從測試結果看，該項目的代碼相對較薄，還沒達到工業級的成熟度，需要大規模應用估計需要自填不少坑，有興趣的同學可以學習研究。

以上就是直播云：直播應用層協議及傳輸層協議的選擇以及對直播體驗影響的分析 。

——————

那麼，延遲與卡頓的矛盾關係如何解決？有時候還需要主動丟包？！

更多關於接入網路優化、內容緩存與傳輸策略優化、終端優化的技術細節。請關注下一篇解析內容：《關於直播，所有的技術細節都在這裡了（三）》。

敬請期待！

本文由『UCloud流媒體研發團隊』提供。

「UCloud機構號」將獨家分享雲計算領域的技術洞見、行業資訊以及一切你想知道的相關訊息。

歡迎提問&求關注 o(*////▽////*)q～

以上。