前言
隨著直播行業大火,各種直播類產品和產品層出不窮,能夠滿足各方人員的需求和互動,也使得鬥魚、虎牙、抖音都隨著直播業的大火而欣欣向榮,
大家也對直播平臺瞭解不少,也參與使用,但是怎麼樣才能研發出視訊直播平臺呢?那麼針對於這個問題就是我今天想給大家講解的一些東西,首先要對直播協議有所瞭解,然後怎麼樣使用作者研發的surging 去搭建直播平臺,首先接下來,我就給大家簡單介紹下常見的直播協議。
常見的直播協議
國內常見的直播協議有幾個:RTMP、HLS、HTTP-FLV,下面我們來一一介紹。
RTMP,全稱 Real Time Messaging Protocol,即實時訊息傳送協議。Adobe 公司為 Flash 播放器和伺服器之間音視訊資料傳輸開發的私有協議。工作在 TCP 之上的明文協議,預設使用埠 1935。協議中的基本資料單元成為訊息(Message),傳輸的過程中訊息會被拆分為更小的訊息塊(Chunk)單元。最後將分割後的訊息塊通過 TCP 協議傳輸,接收端再反解接收的訊息塊恢復成流媒體資料。
RTMP 主要有以下幾個優點:RTMP 是專為流媒體開發的協議,對底層的優化比其它協議更加優秀,同時它 Adobe Flash 支援好,基本上所有的編碼器(攝像頭之類)都支援 RTMP 輸出。現在 PC 市場巨大,PC 主要是 Windows,Windows 的瀏覽器基本上都支援 Flash。另外RTMP適合長時間播放,曾經有過測試,連續 10 天多連續播放沒有出現問題。最後 RTMP 的延遲相對較低,一般延時在 1-3s 之間,一般的視訊會議,互動式直播,完全是夠用的。
當然 RTMP 並沒有盡善盡美,它也有不足的地方。一方面是它是基於 TCP 傳輸,非公共埠,可能會被防火牆阻攔;另一方面,也是比較坑的一方面是 RTMP 為 Adobe 私有協議,很多裝置無法播放,特別是在 iOS 端,需要使用第三方解碼器才能播放。
FLV (Flash Video) 是 Adobe 公司推出的另一種視訊格式,是一種在網路上傳輸的流媒體資料儲存容器格式。其格式相對簡單輕量,不需要很大的媒體頭部資訊。整個 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 組成。因此載入速度極快。採用 FLV 格式封裝的檔案字尾為 .flv。
而我們所說的 HTTP-FLV 即將流媒體資料封裝成 FLV 格式,然後通過 HTTP 協議傳輸給客戶端。
HTTP-FLV 依靠 MIME 的特性,根據協議中的 Content-Type 來選擇相應的程式去處理相應的內容,使得流媒體可以通過 HTTP 傳輸。相較於 RTMP 協議,HTTP-FLV 能夠好的穿透防火牆,它是基於 HTTP/80 傳輸,有效避免被防火牆攔截。除此之外,它可以通過 HTTP 302 跳轉靈活排程/負載均衡,支援使用 HTTPS 加密傳輸,也能夠相容支援 Android,iOS 的移動端。
說了這麼多優點,也來順便說下 HTTP-FLV 的缺點,由於它的傳輸特性,會讓流媒體資源快取在本地客戶端,在保密性方面不夠好。因為網路流量較大,它也不適合做拉流協議。
上述兩個協議都是有Adobe公司推出的,而下面要講的 HLS (HTTP Live Streaming) 則是蘋果公司基於 HTTP 的流媒體傳輸協議。主要應用於 iOS 裝置,包含(iPhone, iPad, iPod touch) 以及 Mac OSX 提供音視訊直播服務和錄製內容(點播)等服務。
相對於常見的流媒體協議,HLS 最大的不同在於它並不是一下請求完整的資料流。它會在伺服器端將流媒體資料切割成連續的時長較短的 ts 小檔案,並通過 M3U8 索引檔案按序訪問 ts 檔案。客戶端只要不停的按序播放從伺服器獲取到的檔案,從而實現播放音視訊。
流媒體協議 RTMP, HTTP-FLV, HLS 簡單對比
協議 | 傳輸協議 | 格式 | 延時 |
rtmp | Tcp | flv | 1-3秒 |
http-flv | http | flv | 1-3秒 |
hls | http | m3u8 | 4-10秒 |
RTMP 協議為流媒體而設計,在推流中用的比較多,同時大多 CDN 廠商支援RTMP 協議。
HTTP-FLV 使用類似 RTMP流式的 HTTP 長連線,需由特定流媒體伺服器分發的,兼顧兩者的優點。以及可以複用現有 HTTP 分發資源的流式協議。它的實時性和 RTMP 相等,與 RTMP 相比又省去了部分協議互動時間,首屏時間更短,可擴充的功能也更多。
HLS 作為蘋果提出的直播協議,在 iOS 端佔據了不可撼動的地位,Android 端也同時提供相應的支援。
如何架構實現
rtmp 協議架構圖
排程服務閘道器是針對於外網服務呼叫, , 提供基於rest 查詢流對應的伺服器地址。
直播終端通過排程服務閘道器獲取的rtmp 服務地址,通過地址進行推流,rtmp服務獲取到資料後,然後轉推到其它的rtmp服務上,rtmp再把流推給訂閱的客戶端
http-flv 架構圖
以上是通過rtmp 服務轉推給http-flv 訂閱的客戶端
基於surging 微服務引擎如何實現
比如現在需要獲取live1/livestream直播地址, 那麼首先可以通過地址/locate 獲取wanip外網地址, routepath 是rtmp服務的服務路由路徑,key是直播需要傳過去地址livestream,然後rtmp 埠定義為76,那麼接下來獲取的地址就是
http://192.168.249.103:76/live1/livestream
surging 需要引用liveStream 模組,這樣就能支援直播協議rtmp,http-flv,hls(暫時還未實現),然後還需要通過配置surgingsetting, 配置如下:
"LiveStream": { "RtmpPort": 76, //rtmp 埠 "HttpFlvPort": 77, //HttpFlv 埠 "EnableLog": true, //是否啟用log "RouteTemplate": "live1", //直播服務路由規則名稱,可以根據規則設定,比如叢集節點2,可以設定live2, 叢集節點3,可以設定live3 "ClusterNode": 2 //叢集節點數裡,會根據routetemplate 轉推流 }
然後可以通過ffmpeg或者obs進行推流,以ffmpeg 工具為例,可以輸入以下命令
ffmpeg -re -i D:/大H包.HDTC1280高清國語中字版.mp4 -c copy -f flv rtmp://127.0.0.1:76/live1/livestream2
客戶端採用PotPlayer進行播放,比如可以新增地址rtmp://127.0.0.1:76/live1/livestream2 ,如果你部署了另外一臺rtmp服務,設定的是65埠,那麼可以新增
rtmp://127.0.0.1:65/live1/livestream2進行播放
可以支援一臺N個推流,N個訂閱播放,如下圖:
總結
surging 現在分為兩個版本,一個是社群版本surging ,一個是企業版本microsurging/SurgingVista, 企業版不僅功能強大,支援流媒體服務等協議元件和中介軟體,並且還支援多語言定製化需求,完全可以滿足各大公司的需要,如有意見,可以和作者聯絡。