如何基於surging架設流媒體影片推流（影片講解）

fanly11發表於2024-05-15

前言

隨著直播行業大火，各種直播類產品和產品層出不窮，能夠滿足各方人員的需求和互動，也使得鬥魚、虎牙、抖音都隨著直播業的大火而欣欣向榮，

大家也對直播平臺瞭解不少，也參與使用，但是怎麼樣才能研發出影片直播平臺呢？那麼針對於這個問題就是我今天想給大家講解的一些東西，首先要對直播協議有所瞭解，然後怎麼樣使用作者研發的surging 去搭建直播平臺，首先接下來，我就給大家簡單介紹下常見的直播協議。

影片培訓地址：https://pan.baidu.com/s/13iOJlRnpsknm7NG6booUUw

社群版本開源地址：https://github.com/fanliang11/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 3.mp4 -c:v libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ar 44100 -ac 2 -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, 企業版不僅功能強大，支援流媒體服務等協議元件和中介軟體，並且還支援多語言定製化需求，完全可以滿足各大公司的需要，如有意見，可以和作者聯絡。

相關文章