楊偉偉,胡黎瑋,孟利民,胡海勇
(1.浙江省光纖通信技術(shù)重點研究實驗室,浙江杭州310023;2.浙江鴻程計算機系統(tǒng)有限公司,浙江杭州310023)
在美國、韓國和歐洲等國家和地區(qū),由于3G網(wǎng)絡(luò)的廣泛商用化,無線視頻監(jiān)控發(fā)展已相當(dāng)成熟;而在國內(nèi),3G網(wǎng)絡(luò)正處于發(fā)展和壯大階段,基于3G網(wǎng)絡(luò)的無線監(jiān)控正逐步替代以GPRS和CDMA1X為基礎(chǔ)的無線監(jiān)控[1]。GPRS和CDMA1X網(wǎng)絡(luò)可實際提供的上行速率分別僅為25kbps和75kbps左右;而3G技術(shù)可在室內(nèi)、室外和車載環(huán)境中分別支持2Mkbps、384kbps和144kbps的傳輸速率,可以更好地滿足無線視頻監(jiān)控的應(yīng)用要求。H.264編碼壓縮技術(shù)是ITU-T和ISO/IEC聯(lián)合開發(fā)組共同開發(fā)的最新國際視頻編碼標(biāo)準(zhǔn)[2]。本文采用H.264視頻壓縮技術(shù),設(shè)計和實現(xiàn)了基于3G網(wǎng)絡(luò)的無線視頻監(jiān)控系統(tǒng),該系統(tǒng)可用于實際的現(xiàn)場監(jiān)控。
在本項目設(shè)計中,采用支持H.264編解碼的GM8180開發(fā)板來進(jìn)行二次開發(fā)。攝像頭捕獲的模擬視頻首先由GM8180的編碼器產(chǎn)生H.264壓縮數(shù)據(jù),然后壓縮后的數(shù)據(jù)采用實時傳輸協(xié)議打包(RTP)并通過3G網(wǎng)絡(luò)發(fā)送到客戶端(電腦)進(jìn)行解碼播放。3G網(wǎng)絡(luò)模塊采用中興的MC8630模塊來完成,該模塊通過USB接口與GM8180開發(fā)板相連。在發(fā)送前,需先進(jìn)行該模塊的撥號上網(wǎng)工作。最后在接收端,對收到的RTP視頻進(jìn)行解碼播放。整個系統(tǒng)的設(shè)計方案如圖1所示:
圖1 系統(tǒng)方案設(shè)計圖
H.264具有以下優(yōu)點:在相同的還原質(zhì)量下平均減少50%的比特率,提高網(wǎng)絡(luò)的使用率;能夠提供連續(xù)、流暢的高質(zhì)量圖像;容錯能力強、能夠解決網(wǎng)絡(luò)傳輸中丟包等錯誤;網(wǎng)絡(luò)適應(yīng)性強,可實現(xiàn)在不同網(wǎng)絡(luò)上傳輸[3]。H.264的算法基本上可以分為兩層:(1)視頻編碼層(VCL,Video Coding Layer),負(fù)責(zé)高效的視頻內(nèi)容表示,高編碼效率主要靠該層來實現(xiàn);(2)網(wǎng)絡(luò)抽象層(NAL,Network Abstraction Layer),該層主要負(fù)責(zé)按照網(wǎng)絡(luò)所要求的方式對數(shù)據(jù)包進(jìn)行打包和傳送。
實時傳輸協(xié)議RTP(Real time Transport Protoco1)是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP通常使用UDP來傳送數(shù)據(jù)。每一個RTP數(shù)據(jù)包由包頭和負(fù)載兩個部分組成。相關(guān)頭部包括版本號、標(biāo)志位、序列號、時間戳、同步源等等(可參考文檔RFC3550)。
2.2.1 NAL的負(fù)載格式
在傳輸H.264數(shù)據(jù)時,因為H.264的結(jié)構(gòu)分層,只需要考慮NAL包的傳輸。最新的RFC3984標(biāo)準(zhǔn)中提供了針對H.246媒體流的RTP負(fù)載格式。主要有3種類型的負(fù)載格式:單個NAL單元分組、片分組和聚合分組[4]。當(dāng)NAL包過長時,為了防止丟掉整包,必須進(jìn)行分片發(fā)送。當(dāng)NAL包不是很大時,直接把整個NAL作為RTP的數(shù)據(jù)載荷發(fā)送。本項目采用單個NAL單元分組和片分組,不考慮聚合。
2.2.2 NAL數(shù)據(jù)的發(fā)送
每個RTP包的時間戳設(shè)置如下:若該NAL無需分片發(fā)送(長度小于閾值),則設(shè)置默認(rèn)的時間戳增量為10;若該NAL需要分片發(fā)送(長度大于閾值),則該NAL的所有分片都設(shè)置為相同的時間戳:第一個分片包的時間戳增量為10,后面分片包增量為0。即屬于同一NAL的所有分片采用相同時間戳。發(fā)送流程如圖2所示:
圖2 NAL數(shù)據(jù)發(fā)送流程圖
2.2.3 NAL數(shù)據(jù)的接收
在接收端接收RTP包時,分3個層次來管理接收到得包。首先,根據(jù)RTP包的SSRC(源標(biāo)識符號)來區(qū)分不同的視頻源;其次,根據(jù)RTP包的時間戳來區(qū)分不同的NAL包,不同NAL包的時間戳增量為10;最后,如果是分片包,根據(jù)RTP包的序列號來區(qū)分同一NAL包中的不同分片。結(jié)構(gòu)如圖3所示:
圖3 NAL數(shù)據(jù)接收緩存結(jié)構(gòu)
該緩沖設(shè)計的優(yōu)點:如上的緩存設(shè)計,可以自動糾正數(shù)據(jù)包的亂序(如果數(shù)據(jù)從不同網(wǎng)絡(luò)路由傳送,原本后面的數(shù)據(jù)包比前面的數(shù)據(jù)包先到達(dá)的可能性會很大),而且可以根據(jù)數(shù)據(jù)包的時間戳信息丟棄那些超時的數(shù)據(jù)包。最后,在播放的時候,不僅可以根據(jù)NAL管理隊列中的數(shù)量來自動調(diào)節(jié)播放速率,而且還可以根據(jù)SSRC靈活選擇視頻源。
本系統(tǒng)播放器的實現(xiàn)采用DirectShow構(gòu)架,由VS2005開發(fā)平臺完成。DirectShow是微軟公司在ActiveMovie和Video for Windows的基礎(chǔ)上推出的新一代基于COM的流媒體處理的開發(fā)包,它給出了一種全新的多媒體數(shù)據(jù)處理模型,以filter(濾波器)為核心概念,封裝了采集、壓縮和解壓縮等一系列算法[5]。DirectShow分如下3種filter,如圖4所示:
(1)Source Filter:負(fù)責(zé)處理不同類型的數(shù)據(jù)源,將數(shù)據(jù)引入下一級filter;
(2)Transform Filter:負(fù)責(zé)從上級filter獲取數(shù)據(jù)流進(jìn)行變換,生成輸出流。變換操作包括:編解碼、格式轉(zhuǎn)化、壓縮解壓縮等;
(3)Render Filter:處于Filter Graph的最后一級。負(fù)責(zé)接收上級數(shù)據(jù)流并把數(shù)據(jù)提交給外設(shè)。
圖4 本項目采用的Directshow方案
本項目中,采用ffdshow插件提供的ffdshow Video Decoder來進(jìn)行H.264的解碼,而提交給外設(shè)播放的組建Render Filter由directshow自身提供的Video Renderer實現(xiàn)。網(wǎng)絡(luò)RTP數(shù)據(jù)的接收封裝于Source Filter中,該Source Filter基于“推數(shù)據(jù)”模型,當(dāng)收到NAL數(shù)據(jù)包時,該模型中的FillBuffer()函數(shù)把NAL數(shù)據(jù)推下解碼濾波器和渲染濾波器,以此實現(xiàn)H.264的數(shù)據(jù)播放。
經(jīng)過實際測試,基于RTP協(xié)議的H.264視頻的傳輸可以實際應(yīng)用于CDMA2000無線網(wǎng)絡(luò)中,而基于Directshow的播放器更是由于其結(jié)構(gòu)清晰,設(shè)計過程模塊化,可以高效率地實現(xiàn)數(shù)據(jù)接收和解碼的獨立優(yōu)化。該項目的實現(xiàn)具有廣泛的應(yīng)用價值,不僅可以實現(xiàn)大型商場、公眾場合的監(jiān)控,還可應(yīng)用于車載環(huán)境中。
[1]白立崗.基于3G網(wǎng)絡(luò)和H.264標(biāo)準(zhǔn)的公交車無線視頻監(jiān)控系統(tǒng)研究[J].公路交通科技,2009,52(4):1-2.
[2]劉 瑋.Visual C++視頻/音頻開發(fā)實用工程案例精選[M].北京:人民郵電出版社,2004:55-70.
[3]畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)[M].北京:人民郵電出版社,2001:10-40.
[4]樊姍.基于 R TP的H.264視頻傳輸技術(shù)的研究[D].濟南:山東大學(xué),2008.
[5]陸其明.DirectShow開發(fā)指南[M].北京:清華大學(xué)出版社,2003:10-30.