SRS在安防領域的應用

1. SRS簡介

SRS是一個開源的流媒體協議，可以將攝像機的視頻流數據推送到SRS服務端，播放端可以從SRS實時拉取視頻流數據。

2. SRS支持的協議

SRS支持的協議包含兩部分：輸入協議和輸出協議

說明：左邊輸入協議，右邊輸出協議

 

2.1 瀏覽器無插件播放方案

RTMP最流行的直播協議，PayLoad負載類型為FLV，由於Flash被谷歌禁用，很多瀏覽器就不得不尋找無插件播放。現在也經常會將攝像頭的RTSP視頻流經FFMpeg轉為RTMP推流到SRS，SRS會將RTMP視頻轉為各種協議輸出，如HTTP-FLV、HLS、WebRTC等等。

 

• HLS：蘋果的切片協議，就是將每個視頻包數據一段一段的發送，瀏覽器需要下載完成一個完整的切片才能播放，嚴格上說並不能是一個流媒體協議，只能是一個文件傳輸協議

• HTTP-FLV：目前流行的一個協議，利用了HTTP Chunked特性，HTTP Body數據類型就是FLV（即PayLoad類型），與RTMP的負載類型差不多，瀏覽器接收到數據之后使用flv.js這個庫重新組裝數據，即可實時播放。但是它不是一個滿足W3C標准的流媒體協議，而且實際使用中延時相對WebRtc較高，和RTMP差不多效果。且播放時間長的話音視頻同步會出現問題，有待解決改善。另外手機端IOS不支持。推送到RTMP格式數據可以直接在播放端拉取HTTP-FLV數據，具體詳見SRS的說明文檔。

• WebRTC：是當前最火的流媒體協議。優點對前端的開發者比較方便，只需要幾行代碼就可以實現圖像采集渲染編解碼。缺點是底層技術棧難度較大。延時低，基於UDP

 

2.2 安防中的協議

1. RTSP：PayLoad負載類型為RTP，主要在內網中使用，實際上每個攝像頭都可以理解成是一個RTSP的Server端，如果你要看視頻的話就需要主動到攝像頭那里拉流，攝像頭自己是不會主動推流給你；所以處在公網的瀏覽器是不能獲取到內網的視頻的。

2. GB-28181協議：國標協議，是公安一所聯合幾個攝像頭廠家定制的協議 ，目的是為了解決RTSP存在的問題（外網不能訪問內網的攝像頭數據），該協議能夠主動注冊，且向外推流的協議，最早的2011版是基於UDP，后來公網中丟包比較嚴重，后來又做了一個基於TCP的補充協議。打包方式是RTP+PS。

說明：PS打包適用本地存儲和局域網傳輸，TS打包適用網絡數據傳輸。

 

3. SRS使用場景

3.1 常見使用場景

• 視頻直播，主播使用OBS推流到SRS，轉封裝成HTTP-FLV流或者是蘋果的HLS。SRS一般不做轉碼，如果有需要做轉碼可以通過OBS或者FFmpeg，如原來經常會將攝像頭的RTSP流轉為RTMP流到SRS，每個瀏覽器或者桌面客戶端程序可以直接拉取RTMP視頻流數據進行播放。

• WebRTC通話，WebRTC可以點對點，也可用於多人通話，視頻會議等。低延時場景。

• 安防監控領域：可以使用FFmpeg拉取RTSP視頻流再轉為RTMP推送到SRS，也可以直接使用GB-28181協議直接推流，客戶端使用WebRTC播放

• 廣電領域，使用SRT協議推流。

 

3.2 安防端場景

 

設備端：攝像頭和NVR等設備

邊緣端：一般會配置一個視頻網關，負責拉流並轉推到雲端，同時也支持一些控制指令和邊緣存儲等

雲端：指揮調度系統，SRS的功能是用於視頻流的轉發。

實時：對於視頻網關來說，接收一幀轉發一幀，中間不需要進行一些sleep處理

回放：實際就是讀取文件推流，讀文件的速度很快，不進行sleep控制就會瘋狂推送，壓榨完你的CPU，接收端播放也很快，所以需要sleep，如幀率是25的視頻，兩幀之間間隔就是40ms，所以每一幀之間要延時了40毫秒，再推送下一幀。

回放控制業務：

• 快進：常規的修改是sleep縮小時間，如二倍數修改為20ms，4倍數10ms，8倍數5ms，但是這樣並不可行，

  • 帶寬限制，速度增加，同一時間傳輸的視頻數據量也會成倍增大，即相應的碼率成倍增加，所以如果這種模式快進帶寬是一個限制。如1080p正常播是4M，如果按這種方式播放的話：2倍數碼率對應着8M，4倍數碼率就對應着16M，8倍數就對應着32M，對帶寬消耗很大

  • CPU性能，主要是視頻編碼能力也要成倍增加，而軟件編解碼很耗資源，另外對於客戶端的CPU壓力也很大，即需要解碼的視頻流也變大。

  比較好的解決是使用抽幀的方式：隔一定的時間間隔就將一些幀丟掉，這里需要注意不能把I幀丟掉，其保留了一個完整的圖像數據，后面的P幀需要依賴I幀解碼。所以一般都會有一個根據速率和帶寬和I幀間隔的算法，如二倍速是我們把時間間隔減半（增加一些帶寬和CPU的消耗），四倍數時只發送I幀，8倍速時就每兩個I幀發送1個I幀數據，16倍數時就每隔4個I幀發送一個。

• 慢放：發送時間間隔加長即可

• Seek:t：拖拽

• 雲台控制：對延時要求較高，現階段一般采用WebRtc協議進行控制。延時一般一秒可滿足需求

• 暫停：SRS有一個機制如果5秒接收不到數據，就會認為流斷開了，會觸發unpublish事件

 

3.3 常見問題

1. 導致延時的幾個因素

   a. 硬件設備

   b. 編解碼

   c. 網絡傳輸：

   包括應用層（HLS、RTMP、Http-Flv等）以及傳輸層（TCP（網絡不好的情況下會重傳導致延時卡頓）和UDP）

   緩存： 服務端有一個GOP參數，該參數的設置是為了縮短首屏時間，如果不在乎首屏的等待時間可以將GOP緩存關閉也會減少延時。另一個是播放端也會有緩存，緩存的目的是為了用戶體驗避免卡頓。

   d. 性能優化

   合並讀寫，該功能實際是為了減少IO的讀寫操作，開啟后就不會收到一幀轉發一幀而是收到幾幀數據之后一次性的轉發，即只調用一次系統IO，這樣也會導致延時，如果不在乎這個並發數就可以將這個功能關掉，可以降低延時。

    

2. Onvif/RTSP不支持

   Onvif：設備支持不健全

   RTSP：內網協議外網不能訪問

3. 不支持H265？

   SRS支持H265，但是瀏覽器不支持