一、前言

某項目中需要集成視頻管理平臺，實現(xiàn)分布在各省公司的攝像及接入，對視頻進行統(tǒng)一管理。本項目中視頻管理平臺采用GB/T28181實現(xiàn)的監(jiān)控設備接入管理平臺，支持在開放互聯(lián)網(wǎng)和局域網(wǎng)對監(jiān)控設備進行遠程接入、遠程管理、遠程調(diào)閱、錄像回看等功能。本文對此記錄GB/T28181協(xié)議的原理和一些問題，以供后續(xù)參考。

相關資源：Nginx支持flv和mp4格式文件，同時支持Rtmp協(xié)議；同時打開rtmp的hls功能

二、視頻協(xié)議

2.1、相關術語

1）H265/H264視頻編碼：

• H.265：又稱為High Efficiency Video Coding (HEVC)，是H.264的后繼者，同樣由VCEG和MPEG聯(lián)合開發(fā)。H.265的目標是在H.264的基礎上進一步提高壓縮效率，理論上可以比H.264節(jié)省大約50%的比特率，同時保持相同的視頻質(zhì)量。相對于H.264，它能提供：更大的編碼單元（CU）尺寸，從64×64到8×8像素的自適應四叉樹結構；改進了運動預測和幀內(nèi)預測；支持更高效的熵編碼方法和更精細的量化參數(shù)控制。這些改進使得H.265在處理高清和超高清視頻時更加高效，但同時也意味著更高的計算復雜度，可能影響到實時編碼和解碼的性能?；贖.265的高效性，它更適合在高清和4K視頻的流媒體和存儲領域；
  \
• H.264*：全稱MPEG-4 Part 10或Advanced Video Coding (AVC)，是由ITU-T的視頻編碼專家組（VCEG）和ISO/IEC的動態(tài)圖像專家組（MPEG）聯(lián)合開發(fā)的一種視頻編碼標準。H.264的主要目標是在與早期標準（如MPEG-2和MPEG-4 Part 2）相同的視頻質(zhì)量下，提供大約兩倍的壓縮效率。這意味著使用H.264編碼的視頻文件可以比使用舊標準編碼的文件小一半左右，這對于網(wǎng)絡傳輸和存儲來說非常重要。通過塊運動補償預測、變換編碼、熵編碼（如CABAC或CAVLC）等多種技術實現(xiàn)了高效壓縮。對于與265的區(qū)別，首先H264/H265都是視頻壓縮標準，但265會比264更先進，一般能將文件大小壓縮后比264再降低約50%以上，可在相同質(zhì)量下使用更低的碼率，即H.265在相同碼率下可以提供更高的視頻質(zhì)量；而264相對于一些老設備更具兼容性，因H.265是較新的壓縮標準，不是所有的設備和平臺都支持，相比H.264是更為廣泛支持的標準，在包括手機、電視、電腦等多個平臺上廣泛應用，故一般取H.264即可。NALU（Network Abstraction Layer Unit）是NAL層的基本數(shù)據(jù)單位，由一個頭部（一個字節(jié)）和一個負載部分組成，其中頭部包含了控制信息，用于指示NAL單元的類型、重要性等級以及其他相關參數(shù)；負載部分包含了實際的編碼數(shù)據(jù)，如圖像數(shù)據(jù)、參數(shù)集數(shù)據(jù)等；而負載數(shù)據(jù)的結構和內(nèi)容取決于NAL單元的類型。：
  
  2）輸出HTTP-FLV、HTTP-MP4
• HTTP-FLV：將音視頻數(shù)據(jù)封裝成 FLV格式文件，然后通過 HTTP 協(xié)議傳輸給客戶端。它具有低延遲特定，內(nèi)容延遲可以做到 2-5 秒；只要瀏覽器支持 FlashPlayer 就能簡易的播放；它的地址是http://開頭的，是基于HTTP協(xié)議的，可以簡單地理解為RTMP的HTTP協(xié)議版本，功能和工作原理是相似的，且RTMP切片數(shù)據(jù)功能，HTTP-FLV也是支持的，但HTTP-FLV協(xié)議一般只能用作拉流觀看。實際體驗中， HTTP-FLV延遲會略高于RTMP，但是HTTP-FLV相對RTMP適配更多的播放場景。Nginx中已經(jīng)集成 nginx-http-flv-module支持該協(xié)議，Nginx的HTTP-FLV插件是包含RTMP功能的，所以一般HTTP-FLV的流媒體服務，推流是以RTMP協(xié)議，拉流是用HTTP-FLV協(xié)議。綜上，目前比較流行的方案是，直播源推流是RTMP協(xié)議，直播拉流觀看是HTTP-FLV協(xié)議。
• HTTP-MP4：基于HTTP的MP4協(xié)議，將音視頻數(shù)據(jù)封裝成封裝成mp4格式。MP4 文件的數(shù)據(jù)都是封裝在一個又一個名為 Box 的單元中。一個 MP4 文件由若干個 Box/FullBox 組成，每個 Box 包含了 Header 和 Data。所有的Metadata（媒體描述元數(shù)據(jù)），包括定義媒體的排列和時間信息的數(shù)據(jù)都包含在這樣的一些結構box中。Metadata 對媒體數(shù)據(jù)（比如視頻幀）引用說明，而媒體數(shù)據(jù)在這些引用文件中的排列關系全部在第一個主文件中的metadata描述，這樣就會導致視頻時長越大文件頭就會越大、加載越慢。

• 4K流媒體代表(40962160分辨率)，8K流媒體高清代表(81924320分辨率)
• 720P(1280*720分辨率) ，1080P(1920 * 1080分辨率)
• RTMP：RTMP協(xié)議是既可以推流、也可以拉流的協(xié)議。RTMP和HTTP-FLV都是建立在FLV封裝之上的，RTMP一般用作直播源推流，HTTP-FLV一般用作直播觀看；RTMP地址是rtmp://開頭的，且推流地址與播放地址是一樣的。相對于HTTP方式，很多防火墻會墻掉 RTMP，但是一般不會墻 HTTP，因此 HTTP FLV 出現(xiàn)奇怪問題的概率會很小，FLV 是最簡單的流媒體封裝，HTTP 是最廣泛的協(xié)議，這兩個組合在一起維護性更高，比 簡單很多。RTMP通信是建立在TCP長連接通道上的，在封裝音視頻數(shù)據(jù)時會強制切片，限制每個數(shù)據(jù)包的大小，這在一定程度保證了實時性，有一定的弱網(wǎng)抵抗能力，因為每個數(shù)據(jù)包都不會太大，所以當某個數(shù)據(jù)包校驗失敗時，重新發(fā)送的成本不會太大，但也由于合并數(shù)據(jù)包會加大CPU壓力，所以是有一定的性能消耗的。RTMP具備低延遲，內(nèi)容延遲可以做到 2-5 秒。
  
  
  \
• WebRTC是一種點對點的視頻/語音通話協(xié)議。由于WebRTC是基于UDP的，建立通信后，會不斷以流式發(fā)送數(shù)據(jù)，所以延遲會比RTMP還要低。在一些交互性較高的直播場景，如直播帶貨等場景，會使用WebRTC作為推流和觀看協(xié)議 WebRTC的延遲理論上可以達到1秒內(nèi)。WebRTC協(xié)議支持推流和拉流，地址一般是以webrtc://開頭的，且推流和拉流地址一般是一樣的。WebRTC雖然是點對點的協(xié)議，但是應用在直播場景的話，是需要搭建WebRTC服務器作為流媒體服務的，流媒體服務軟件可以使用SRS，SRS是國內(nèi)研發(fā)的一個比較流行的開源流媒體服務軟件，目前4.0已經(jīng)囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流協(xié)議。
  \
• RTSP/Onvif協(xié)議：一般不用作直播場景，RTSP一般用作攝像頭、監(jiān)控等硬件設備的實時視頻流觀看與推送上。盡管RTSP協(xié)議也支持推流/拉流，且支持TCP、UDP切換以及其他諸多優(yōu)點。但是泛用性不足，特別是現(xiàn)在的瀏覽器都不支持RTSP的播放。RTMP 和 RTSP 都是流媒體傳輸協(xié)議，它們之間的主要區(qū)別：1）RTMP 是一種基于 TCP 的實時傳輸協(xié)議，而 RTSP 是一種基于 UDP 的實時傳輸協(xié)議。2）傳輸方式：RTMP 是一種單向傳輸協(xié)議，信息只能從服務器端傳輸?shù)娇蛻舳?。?RTSP 支持雙向傳輸，允許服務器端和客戶端之間進行實時通信。3）控制協(xié)議：RTSP 是一種控制協(xié)議，它可以用于控制媒體流的播放、暫停、停止等操作。而 RTMP 不是一種控制協(xié)議，它只負責媒體流的傳輸。4）安全性：RTMP 提供了較低的安全性，因為它使用 TCP 協(xié)議進行傳輸，容易受到中間人攻擊。而 RTSP 提供了較高的安全性，因為它使用 UDP 協(xié)議進行傳輸，并支持加密和認證。5）應用場景：RTMP 主要用于直播和視頻點播應用，而 RTSP 主要用于實時視頻監(jiān)控和安防監(jiān)控等應用。

3）HLS：(HTTP Live Streaming)是Apple的動態(tài)碼率自適應技術。主要用于PC和Apple終端的音視頻服務。包括一個m3u(8)的索引文件，TS媒體分片文件和key加密串文件。HLS協(xié)議一般只用作拉流觀看，嚴格來說，HLS其實是一個 文本協(xié)議，而并非流媒體協(xié)議，它的延遲較高（ts0，segment-time：5，10s）。HLS只請求基本的HTTP報文，與實時傳輸協(xié)議（RTP)不同，HLS可以穿過任何允許HTTP數(shù)據(jù)通過的防火墻或者代理服務器，它也很容易使用內(nèi)容分發(fā)網(wǎng)絡來傳輸媒體流。HLS一般主用于通過HTTP協(xié)議下載靜態(tài)視頻文件，HLS協(xié)議的文件由兩部分組成：一是多個只有幾秒長度的 .ts碎片 視頻文件，另一個是記錄這些視頻文件地址的.m3u8索引文件；HLS觀看地址是以http://開頭、.m3u8結尾的，實際上這個地址就是索引文件的地址，客戶端獲取到索引文件后，就可以下載對應的碎片視頻文件并開始播放了；.m3u8索引文件會記錄所有的碎片視頻文件地址，HLS在點播的場景下，優(yōu)勢是更加明顯的。由于HLS的相關文件是無狀態(tài)的靜態(tài)文件，且每個文件的大小是有限的，所以負載均衡、CDN加速的效果更佳明顯。另.m3u8索引文件支持二級索引，就是高清、標清、流暢等多個觀看地址可以整合到一個索引文件。播放器可以根據(jù)當前帶寬自動切換不同的觀看地址，大部分網(wǎng)頁播放器的“自動”也是因為這個。HLS最大的優(yōu)點：支持HTML5 就可以直接打開播放，這意味著可以把一個直播鏈接進行轉發(fā)分享后用戶通過瀏覽器就能播放，不需要安裝任何獨立的 APP，HLS協(xié)議可以用于點播和直播觀看，可適配多種播放場景。采用HLS協(xié)議的點播視頻，會比.mp4、.flv的視頻更快地播放出來，且在加載中跳轉視頻也會更加順滑。

采用HLS協(xié)議的直播場景，視頻流數(shù)據(jù)每幾秒會打包成一個以.ts為后綴的碎片視頻文件，每生成一個新的視頻文件都會同步更新.m3u8索引文件。且碎片視頻文件的個數(shù)是有上限的，當達到上限后，默認會將最舊的視頻文件刪除且更新.m3u8索引文件。所以在直播的場景下，客戶端也需要不斷定時重新獲取.m3u8索引文件；即HLS協(xié)議并不適合直播的場景。直播場景下，由于需要生成靜態(tài)文件，直播延遲很大，大概在5-30秒左右，使用直播CDN的話，由于邊緣節(jié)點同步等問題，直播延遲甚至可能會達到1分鐘左右。

注：由于HLS協(xié)議的視頻文件、索引文件都是無狀態(tài)的靜態(tài)文件，是直接寫入磁盤的 ，所以如果長時間且多個直播流同時處理，會造成磁盤寫入壓力過大，機械磁盤可能會磁道會損壞，固態(tài)硬盤的壽命會加速衰減。這種情況下，最好掛載一段內(nèi)存空間作為HLS相關文件的寫入位置，以減輕磁盤寫入壓力過大的問題。

4）流（stream）：數(shù)據(jù)在網(wǎng)絡上按時間先后次序傳輸和播放的連續(xù)音/視頻數(shù)據(jù)流。之所以可以按照順序傳輸和播放連續(xù)是因為在類似 RTMP、FLV 協(xié)議中，每一個音視頻數(shù)據(jù)都被封裝成了包含時間戳信息頭的數(shù)據(jù)包。而當播放器拿到這些數(shù)據(jù)包解包的時候能夠根據(jù)時間戳信息把這些音視頻數(shù)據(jù)和之前到達的音視頻數(shù)據(jù)連續(xù)起來播放。而像MP4、MKV 等這類封裝，必須拿到完整的音視頻文件才能播放，因為里面的單個音視頻數(shù)據(jù)塊不帶有時間戳信息，播放器不能將這些沒有時間戳信息數(shù)據(jù)塊連續(xù)起來，所以就不能實時的解碼播放。

WebSocket

GA/T 1400協(xié)議
數(shù)字視頻錄像機（DVR）
網(wǎng)絡視頻錄像機（NVR）
SIP協(xié)議：SIP（Session Initiation Protocol，會話發(fā)起協(xié)議）是一個用于建立，更改和終止多媒體會話的應用層控制協(xié)議，其中的會話可以是IP電話、多媒體分發(fā)及多媒體會議。SIP協(xié)議采用Client/Server模型，主要通過與代理服務器之間的通信來完成用戶呼叫的建立過程。

2.2、GB28181網(wǎng)絡視頻協(xié)議

GB28181協(xié)議是指遵循國家標準GB/T 28181—2016《公共安全視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)信息傳輸、交換、控制技術要求》中所要求的進行視頻處理的約定標準。它也是我國公安部提出的一個通用的視頻監(jiān)控聯(lián)網(wǎng)協(xié)議。它規(guī)定了視頻監(jiān)控系統(tǒng)中前端設備、平臺服務器、客戶端之間的通信協(xié)議和數(shù)據(jù)格式，旨在實現(xiàn)不同廠家、不同設備之間的互聯(lián)互通。其中：

1.該標準規(guī)定了公共安全視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)的互聯(lián)結構， 傳輸、交換、控制的基本要求和安全性要求， 以及控制、傳輸流程和協(xié)議接口等技術要求，是視頻監(jiān)控領域的國家標準。
2.GB28181協(xié)議信令層面使用的是SIP（Session Initiation Protocol）協(xié)議；
3.流媒體傳輸層面使用的是實時傳輸協(xié)議（Real-time Transport Protocol，RTP）協(xié)議；

GB28181協(xié)議數(shù)據(jù)包封裝格式：

如上圖所示，視頻連網(wǎng)系統(tǒng)在進行視音頻傳輸及控制時應建立兩個傳輸通道：會話通道和媒體流通道

• 會話通道：用于在設備之間建立會話并傳輸系統(tǒng)控制命令
• 媒體流通道：用于傳輸視音頻數(shù)據(jù),經(jīng)過壓縮編碼的視音頻流采用流媒體協(xié)議 RTP/RTCP傳輸

2.3、常見視頻管理架構

三、問題及故障

3.1、視頻斷流

現(xiàn)場遠程會議室錄像機是通過國標GB28181協(xié)議注冊到視頻管理平臺后，視頻播放了一會兒就出現(xiàn)了斷流的現(xiàn)象。

處理：現(xiàn)場抓包設備查和sip協(xié)議查看視頻流推送通信過程，設備端會主動發(fā)bye，導致斷流；然后更換網(wǎng)絡環(huán)境，測試對比排除；當現(xiàn)場配置有防火墻時，對外的端口未能恰當開放，會導致斷流現(xiàn)象。

eg1：相關經(jīng)驗表明，當設備網(wǎng)絡較差時，設備會出現(xiàn)斷流，超過指定的超時時間30s(各平臺默認值不同)，就會主動清除流媒體服務，但是redis中的流數(shù)據(jù)還在，而當設備在錄像時，自動?；顣膔edis中取保活流數(shù)據(jù)，所以就會出現(xiàn)設備狀態(tài)顯示正在播放，但是流已經(jīng)消失的情況。這時，就需要檢查對流的判斷，確保異常后可重新拉流，現(xiàn)場實際為：斷流后會重試拉流。

3.2、視頻串流

?GB28181協(xié)議下頻繁出現(xiàn)串流和斷流的問題?主要涉及到幾個方面：設備配置沖突、網(wǎng)絡問題、協(xié)議實現(xiàn)的不一致性以及服務?；顧C制的問題，主要出現(xiàn)在網(wǎng)絡方面。

1）攝像設備配置沖突：

如果現(xiàn)場兩臺設備配置沖突，比如：配置參數(shù)SIP用戶ID必須為唯一值（一般會根據(jù)地區(qū)編碼設置不同ID），否則會向視頻管理平臺進行不間斷地注冊，這樣就會導致這兩臺設備的視頻流沖突，一會是A設備的流，一會是B設備的流。
\

2）網(wǎng)絡問題?：

在網(wǎng)絡通信過程中，隨著視頻流并發(fā)和資源下載等負載增高，出現(xiàn)通過國標GB28181協(xié)議注冊到視頻監(jiān)控平臺后頻繁斷流，可能是因為現(xiàn)場網(wǎng)絡環(huán)境存在問題，如：防火墻設置導致端口未能開放，進而影響視頻流的正常傳輸?？赏ㄟ^開啟對應端口后，嘗試查看視頻流是否可恢復正常?。
eg1：當設備網(wǎng)絡較差時，設備會斷流，超過指定的時間30s(各平臺默認值不同)，就會主動清
除流媒體服務，但是redis中的流數(shù)據(jù)還在，而當設備在錄像時，自動?；顣膔edis中取?；盍鲾?shù)據(jù)，所以就會出現(xiàn)設備狀態(tài)顯示正在播放，但是流已經(jīng)消失的情況。

3?）協(xié)議實現(xiàn)的不一致性?：

GB28181協(xié)議在實施過程中，由于不同廠商的實現(xiàn)可能存在差異，導致協(xié)議解析出現(xiàn)問題，進而影響到服務穩(wěn)定性。例如，部分機型不按照標準ps協(xié)議封包，導致級聯(lián)平臺中的ssrc直接默認為0，無法使用ssrc校驗碼流，從而引發(fā)串流問題。此外，rtp碼流無法避免串流和異常碼流攻擊，即使采用ssrc校驗也不能完全避免?。

4?）服務keep-alive機制的問題?：

在設備進行播放?；顣r，如果對流信息判斷不當，可能導致斷流現(xiàn)象。例如，如果設備端主動發(fā)送bye信令，而服務端未能正確處理這種情況，就會導致視頻流意外斷開。解決這一問題的方法包括對流信息進行正確判斷，并在必要時自動重新拉流?。

5）通道占用問題：

相關經(jīng)驗中，當通過數(shù)據(jù)庫查看設備狀態(tài)實際離線后（即它的通道實際也就離線了），但頁面檢查會發(fā)現(xiàn)設備通道是在線狀態(tài)，故前臺也會顯示該設備在線，然實際是該攝像頭使用了其他通道的標識，導致最終出現(xiàn)串流。故在代碼層面應檢測設備時如果處于離線狀態(tài)，只需將關聯(lián)的通道也置為離線狀態(tài)即可。