摘 要：文中針對視頻監(jiān)控信號對網(wǎng)絡(luò)帶寬要求高，難以通過公網(wǎng)遠程傳輸?shù)葐栴}，提出了基于RTMP協(xié)議的實時視頻遠程傳輸解決方案，通過開發(fā)視頻轉(zhuǎn)換軟件將橋梁現(xiàn)場視頻信號轉(zhuǎn)換為RTMP碼流，并將其推流至云平臺端搭建的Nginx流媒體服務(wù)器上。客戶端通過開發(fā)Web端和安卓移動視頻播放軟件，實現(xiàn)了橋梁視頻監(jiān)控信息的跨平臺展示應(yīng)用，提升了橋梁安全的實時監(jiān)管能力。

　　關(guān)鍵詞：RTMP協(xié)議;流媒體;Nginx服務(wù)器;Web;編碼技術(shù);視頻監(jiān)控

　　0 引 言

　　近年來，隨著我國交通基礎(chǔ)設(shè)施建設(shè)的跨越式發(fā)展，各類跨江跨海大橋建立的健康監(jiān)測系統(tǒng)逐漸成為保障橋梁安全的重要手段。視頻監(jiān)控憑借技術(shù)成熟，監(jiān)測方式直觀可靠等優(yōu)點已成為橋梁健康監(jiān)測系統(tǒng)的標配。但視頻信號相較數(shù)字類監(jiān)測信號對網(wǎng)絡(luò)帶寬要求較高，常出現(xiàn)卡頓、掉幀等問題。同時考慮橋梁現(xiàn)場惡劣的工況及數(shù)據(jù)安全要求，導(dǎo)致目前只能采用高速光纖專網(wǎng)實現(xiàn)視頻信號的局域網(wǎng)傳輸，大大限制了網(wǎng)絡(luò)傳輸距離和應(yīng)用范圍。

　　本文提出了一種基于RTMP(Real Time Messaging Protocol，RTMP)協(xié)議的視頻監(jiān)控數(shù)據(jù)遠程傳輸方案，在不改變橋梁監(jiān)測系統(tǒng)網(wǎng)絡(luò)架構(gòu)的基礎(chǔ)上，實現(xiàn)了視頻監(jiān)控信號的遠程傳輸和多平臺展示應(yīng)用[1-2]。

　　1 編碼協(xié)議簡介

　　1.1 RTMP協(xié)議

　　RTMP協(xié)議是一種進行實時數(shù)據(jù)通信的網(wǎng)絡(luò)協(xié)議，主要用來在支持Flash/AIR平臺和支持RTMP協(xié)議的流媒體服務(wù)器之間進行音視頻數(shù)據(jù)通信[3-4]。

　　RTMP協(xié)議是建立在TCP協(xié)議之上的應(yīng)用層協(xié)議，其數(shù)據(jù)包由一個固定長度的包頭和最大長度為128 B的包體組成。RTMP協(xié)議數(shù)據(jù)包格式如圖1所示。

　　協(xié)議包頭中MessageType為消息類型，PayloadLength為報文長度，TimeStamp為消息時間戳，StreamID為視頻流ID。協(xié)議包體主要由基本消息頭(ChunkBasicHeader)、負載消息頭(ChunkMessageHeader)、擴展時間戳(ExtendedTimeStamp)和消息塊數(shù)據(jù)(ChunkData)組成。

　　為保證在低網(wǎng)絡(luò)帶寬下視頻流的傳輸，在RTMP協(xié)議下視頻消息塊被拆分為若干個小的數(shù)據(jù)塊，各數(shù)據(jù)塊通過ChunkMessageHeader消息頭可重新組裝成完整的消息塊。數(shù)據(jù)采集端將視頻流分割成較小的數(shù)據(jù)塊后以TCP協(xié)議發(fā)送至服務(wù)器端，客戶端獲取服務(wù)器端數(shù)據(jù)塊后重新將其組裝成完整的視頻消息塊，實現(xiàn)視頻流的流暢播放，從而解決了低帶寬情況下的視頻延遲和卡頓問題。

　　1.2 H.264編碼技術(shù)

　　H.264是當(dāng)前一種主流的視頻壓縮編碼標準。與H.261，H.263等視頻編碼標準相比，H.264協(xié)議采用DCT變換編碼加DPCM差分編碼，并融合了運動估計、多幀預(yù)測、基于內(nèi)容的變長編碼等先進技術(shù)，使其編碼壓縮效率大幅提升，進而有效提升視頻質(zhì)量及其網(wǎng)絡(luò)適應(yīng)能力。

　　H.264協(xié)議為解決不同應(yīng)用中網(wǎng)絡(luò)傳輸?shù)牟町悊栴}，在架構(gòu)層面定義了兩個層級。

　　(1)視頻編碼層(VCL)：通過視頻信息的編碼，實現(xiàn)視頻內(nèi)容的高效展示;

　　(2)網(wǎng)絡(luò)提取層(NAL)：判斷當(dāng)前網(wǎng)絡(luò)環(huán)境，并采用相應(yīng)的提取算法打包和傳輸視頻數(shù)據(jù)。

　　H.264編碼架構(gòu)如圖2所示。

　　2 總體技術(shù)路線

　　本文結(jié)合以往項目經(jīng)驗，提出基于RTMP協(xié)議的視頻監(jiān)控信號的遠程傳輸方案，總體技術(shù)路線如下：

　　(1)橋梁現(xiàn)場視頻攝像機將采集的原始視頻流數(shù)據(jù)通過光纖內(nèi)網(wǎng)傳輸?shù)奖O(jiān)控中心的視頻處理服務(wù)器;

　　(2)自主開發(fā)RTMP碼流轉(zhuǎn)換軟件并將其部署在視頻處理服務(wù)器上，將橋梁現(xiàn)場傳輸?shù)脑家曨l信號轉(zhuǎn)換為RTMP碼流，并通過加密公網(wǎng)將RTMP信號推流至具有公網(wǎng)IP的云服務(wù)器端;

　　(3)在云服務(wù)器端部署并配置Nginx流媒體服務(wù)Server端，實現(xiàn)RTMP視頻數(shù)據(jù)的中繼轉(zhuǎn)換功能;

　　(4)在客戶端開發(fā)基于Web端和安卓移動端的視頻播放軟件，從Nginx服務(wù)器獲取并展示視頻信號，實現(xiàn)橋梁視頻監(jiān)控信息的實時展示[5-6]。

　　RTMP視頻監(jiān)控網(wǎng)絡(luò)架構(gòu)如圖3所示。

　　3 關(guān)鍵技術(shù)研究

　　3.1 RTMP碼流轉(zhuǎn)換開發(fā)

　　目前主流的RTMP碼流轉(zhuǎn)換方法是采用FFmpeg將RTSP視頻信號轉(zhuǎn)換為RTMP流媒體信號，但FFmpeg存在丟包率高、多路信號傳輸支持性差等缺點。

　　經(jīng)過多方比選驗證，本文最終采用EasyRTMP直播組件進行二次開發(fā)，該組件集成了RTMP基本協(xié)議與異步推送、環(huán)形緩沖區(qū)、網(wǎng)絡(luò)擁塞自動丟幀、事件回調(diào)、緩沖器、關(guān)鍵幀檢索等功能，可兼容市面上大部分RTMP流媒體服務(wù)器。

　　EasyRTSP直播組件具有Windows，ARM，Linux等不同跨平臺版本[7-8]。實際開發(fā)中采用C++語言引用EasyRTSPClient.dll類庫編寫視頻流接收及RTMP轉(zhuǎn)換功能，其代碼邏輯流程如圖4所示。

　　本模塊通過RTSPSourceCallback回調(diào)函數(shù)不斷監(jiān)聽視頻數(shù)據(jù)，當(dāng)監(jiān)聽到數(shù)據(jù)類型為EASY_SDK_VIDEO_FRAME_FLAG時，啟動RTMP碼流轉(zhuǎn)換代碼塊，其處理核心邏輯代碼如下：

　　if(_mediatype== EASY_SDK_VIDEO_FRAME_FLAG)

　　{

　　pChannel->fPusherInfo.rtmpHandle= EasyRTMP_Create();1 [2]

　　推薦閱讀：物聯(lián)網(wǎng)技術(shù)計算機信息化論文投稿