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

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

　　0 引 言

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

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

　　1 編碼協(xié)議簡(jiǎn)介

　　1.1 RTMP協(xié)議

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

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

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

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

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

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

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

　　(1)視頻編碼層(VCL)：通過(guò)視頻信息的編碼，實(shí)現(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é)合以往項(xiàng)目經(jīng)驗(yàn)，提出基于RTMP協(xié)議的視頻監(jiān)控信號(hào)的遠(yuǎn)程傳輸方案，總體技術(shù)路線如下：

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

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

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

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

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

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

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

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

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

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

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

　　if(_mediatype== EASY_SDK_VIDEO_FRAME_FLAG)

　　{

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

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