鄒 玲,李 麗,鄭 偉
(湖北工業(yè)大學(xué)電氣與電子工程學(xué)院,湖北 武漢430068)
隨著網(wǎng)絡(luò)應(yīng)用逐漸滲透各個(gè)領(lǐng)域.利用寬帶網(wǎng)絡(luò)進(jìn)行遠(yuǎn)程的網(wǎng)絡(luò)視頻監(jiān)控,不但使用方便,而且非常經(jīng)濟(jì).遠(yuǎn)程視頻監(jiān)控系統(tǒng)結(jié)構(gòu)建立在互聯(lián)網(wǎng)上,將會(huì)使操作維護(hù)更加方便,也增加了系統(tǒng)的實(shí)時(shí)性.
系統(tǒng)基于Internet通過(guò)以太網(wǎng)卡采用TCP/IP協(xié)議實(shí)現(xiàn)監(jiān)控的存儲(chǔ)與傳輸.應(yīng)用體系采用四層(B/S)結(jié)構(gòu).使得系統(tǒng)管理、更新變得簡(jiǎn)易;使數(shù)據(jù)庫(kù)更加安全,不會(huì)因?yàn)椴僮魇д`而對(duì)系統(tǒng)產(chǎn)生影響.使用IE瀏覽器內(nèi)嵌ActiveX控件調(diào)用客戶端管理模塊,使整個(gè)應(yīng)用系統(tǒng)更加靈活穩(wěn)定.任何互聯(lián)網(wǎng)環(huán)境下均可以接入此系統(tǒng).在交互式通信時(shí)采用了多線程技術(shù),同步進(jìn)行解碼和顯示.
目前遠(yuǎn)程監(jiān)控視頻傳輸方式[1]分為:1)視頻基帶傳輸;2)光纖傳輸;3)網(wǎng)絡(luò)傳輸;4)微波傳輸;5)雙絞線傳輸(平衡傳輸);6)寬頻共纜傳輸.本文采用網(wǎng)絡(luò)傳輸方式,這是一種解決城域間遠(yuǎn)距離、點(diǎn)位極其分散的監(jiān)控傳輸方式,具有實(shí)時(shí)性且管理方便,缺點(diǎn)是:受目前網(wǎng)絡(luò)帶寬和速度的限制,動(dòng)畫延時(shí)明顯.
為使實(shí)時(shí)監(jiān)控的延遲最小化,可采用視頻流的方案解決這一問(wèn)題.視頻流不需要監(jiān)控接收端對(duì)監(jiān)控視頻信息進(jìn)行整段的劃分下載,而是在監(jiān)控接收端創(chuàng)建緩沖區(qū),進(jìn)行接收信息的臨時(shí)存儲(chǔ),在信息量達(dá)到可以流暢播放之后,監(jiān)控端即可開始顯示監(jiān)控視頻.當(dāng)監(jiān)控接收端的緩沖區(qū)接收到第一個(gè)數(shù)據(jù)塊時(shí),就開始準(zhǔn)備視頻播放器的加載,此時(shí)緩沖區(qū)繼續(xù)接受其他視頻信息塊,當(dāng)信息量足夠流暢播放視頻時(shí),監(jiān)控平臺(tái)即可播放監(jiān)控信息,保證視頻播放的實(shí)時(shí)性和連續(xù)性,一般可以將延遲控制在10s左右.
基于互聯(lián)網(wǎng)的監(jiān)控傳輸一般采用 MPEG2/4、H.264音視頻壓縮編碼格式傳輸監(jiān)控信號(hào).而H.264編碼具有極高的數(shù)據(jù)壓縮比.在同等圖像質(zhì)量條件下,H.264的數(shù)據(jù)壓縮比要比 MPEG-4高1.5~2倍.在網(wǎng)絡(luò)傳輸過(guò)程中所需要的帶寬更少,也更加經(jīng)濟(jì).在MPEG-2需要6Mbps的傳輸速率匹配時(shí),H.264只需要1~2Mbps的傳輸速率.因而適用于速率受限的網(wǎng)絡(luò)傳輸方式.
根據(jù)以上對(duì)傳輸方式和傳輸格式的分析,遠(yuǎn)程監(jiān)控可以采用基于H.264編碼方式的RTP視頻流方式對(duì)網(wǎng)絡(luò)視頻進(jìn)行傳輸.
H.264編碼分兩層結(jié)構(gòu),包括視頻編碼層(VCL)和網(wǎng)絡(luò)適配層(NAL).其中,視頻編碼層負(fù)責(zé)對(duì)視頻數(shù)據(jù)傳輸中所承載的視頻內(nèi)容進(jìn)行描述和定義,它獨(dú)立于網(wǎng)絡(luò);而網(wǎng)絡(luò)適配層則負(fù)責(zé)使用下層網(wǎng)絡(luò)的分段格式來(lái)封裝數(shù)據(jù),使其適于網(wǎng)絡(luò)傳輸.其中,NAL由一系列的數(shù)據(jù)單元 NALU(Network Abstraction Layer Unit)組成,根據(jù)NALU的不同,其數(shù)據(jù)量也各不相同.每個(gè)NALU都由NALU頭(NALU Header)和載荷數(shù)據(jù)(RBSP)組成(圖1).
圖1 NALU單元頭格式
服務(wù)器通過(guò)把視頻數(shù)據(jù)用RTP進(jìn)行打包封裝.應(yīng)用RTP的封裝規(guī)范[2](包括同步源和時(shí)戳)對(duì)H.264的視頻編碼數(shù)據(jù)進(jìn)行封裝.RTP荷載結(jié)構(gòu)通過(guò)荷載的第一個(gè)字節(jié)對(duì)信息進(jìn)行識(shí)別,也共享為RTP荷載頭.封裝時(shí)將NAL單元(NALU)放入RTP載荷中,并對(duì)RTP的頭標(biāo)值進(jìn)行設(shè)置(圖2).
圖2 服務(wù)器端打包流程
系統(tǒng)采用IP協(xié)議進(jìn)行網(wǎng)絡(luò)傳輸(圖3),發(fā)送端需要在使用IP/UDP/RTP的協(xié)議時(shí),將各報(bào)頭數(shù)據(jù)進(jìn)行封裝,包括IP頭(20字節(jié)以上),UDP頭(8字節(jié)以上)和RTP頭(12字節(jié)以上).然后按照RTP的信息格式放入視頻數(shù)據(jù),對(duì)RTP包頭進(jìn)行配置,包括Timestamp(時(shí)間信息),SSRC(同步源)以及Sequence Number(數(shù)據(jù)包序列)等參數(shù),形成IP數(shù)據(jù)包,通過(guò)互聯(lián)網(wǎng)進(jìn)行發(fā)送,接收端通過(guò)對(duì)RTP數(shù)據(jù)進(jìn)行識(shí)別,接收有效RTP包中的NALU數(shù)據(jù),實(shí)現(xiàn)從發(fā)送端到接收端的視頻流數(shù)據(jù)傳輸.
圖3 RTP遠(yuǎn)程網(wǎng)絡(luò)監(jiān)控傳輸方式
系統(tǒng)采用QoS(Quality of Service,服務(wù)質(zhì)量,是網(wǎng)絡(luò)的一種安全機(jī)制,是用來(lái)解決網(wǎng)絡(luò)延遲和阻塞等問(wèn)題的一種技術(shù))的反饋信息[3],探測(cè)網(wǎng)絡(luò)傳輸質(zhì)量,并根據(jù)網(wǎng)絡(luò)速率動(dòng)態(tài)調(diào)整發(fā)送端的采集編碼參數(shù)設(shè)置,從而保證傳輸?shù)腝oS.對(duì)網(wǎng)絡(luò)傳輸速率進(jìn)行反饋控制,即接收端對(duì)丟包率進(jìn)行統(tǒng)計(jì),然后發(fā)給傳輸端,發(fā)送方根據(jù)丟包率調(diào)整傳輸速率,避免網(wǎng)絡(luò)傳輸擁塞的一種策略.此處使用RTP協(xié)議進(jìn)行反饋控制,RTP信息流在傳輸?shù)浇邮斩藭r(shí),由接收端統(tǒng)計(jì)接收狀況以及發(fā)射機(jī)報(bào)告(SR)而生成接收機(jī)報(bào)告(RR),反饋給傳輸端.根據(jù)此反饋信息,傳輸端會(huì)對(duì)視頻流信息傳輸速率進(jìn)行控制和動(dòng)態(tài)調(diào)整,從而避免網(wǎng)絡(luò)阻塞.[4]
ASP.Net開發(fā)Web應(yīng)用時(shí),主要是通過(guò)ADO組件對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作,具有易用、高速、占用內(nèi)存和磁盤空間少的特點(diǎn).系統(tǒng)B/S結(jié)構(gòu)在交互式通信時(shí)采用了多線程技術(shù),同步進(jìn)行解碼和顯示的工作.[7]
因?yàn)椴捎昧诉h(yuǎn)程視頻流緩沖方式傳輸視頻,要保證接收的數(shù)據(jù)完整準(zhǔn)確并且流暢,需要對(duì)傳輸差錯(cuò)速率進(jìn)行控制.差錯(cuò)控制是在傳輸中利用編碼方法對(duì)傳輸中產(chǎn)生的差錯(cuò)進(jìn)行控制,以提高數(shù)字消息傳輸?shù)臏?zhǔn)確性,這是一種重要的數(shù)字通信保障技術(shù).一般來(lái)說(shuō),差錯(cuò)控制的方法有兩種:自動(dòng)請(qǐng)示重發(fā)(ARQ)和前向糾錯(cuò)(FEC).
網(wǎng)絡(luò)數(shù)據(jù)傳輸糾錯(cuò)一般通過(guò)校驗(yàn)來(lái)處理,如CRC-5CRC-12校驗(yàn)算法[6],以檢查發(fā)送端發(fā)送的網(wǎng)絡(luò)數(shù)據(jù)包到接收端是否正確.發(fā)送方有一個(gè)CRC(Cyclic Redundancy Check,循環(huán)冗余校驗(yàn)),接收方比較計(jì)算出的CRC和接收到的CRC是否一致即可判斷網(wǎng)絡(luò)是否出錯(cuò).
首先控制臺(tái)對(duì)服務(wù)器端發(fā)送accept()請(qǐng)求信息,服務(wù)器在通過(guò)accept()返回的信息后與監(jiān)控前端進(jìn)行通信,對(duì)監(jiān)控器發(fā)送信號(hào),監(jiān)控端接收到信號(hào)后進(jìn)行相應(yīng)的操作,并將圖像結(jié)果反饋給用戶(圖4).
在信息量過(guò)大時(shí)如果不加以限制,超額的網(wǎng)絡(luò)流量會(huì)導(dǎo)致設(shè)備反映緩慢,造成網(wǎng)絡(luò)延遲.因此,有必要在傳輸中引入速率控制.系統(tǒng)根據(jù)參數(shù)信息初步確定發(fā)送速率,然后由RR反饋信息動(dòng)態(tài)調(diào)整,調(diào)整視頻分辨率來(lái)改變速率,當(dāng)視頻分辨率略微降低,在傳輸同等時(shí)間的視頻時(shí)可以明顯降低傳輸速率,只要達(dá)到較高的客觀視頻質(zhì)量即可,沒(méi)有必要為了降低傳輸率而降低幀數(shù).
利用RTP數(shù)據(jù)報(bào)的序列號(hào),發(fā)送方在第一次發(fā)送數(shù)據(jù)的時(shí)候生成一個(gè)初始隨機(jī)數(shù),之后發(fā)送的數(shù)據(jù)按照順序序列號(hào)依次遞增.這樣,接收方就可以在收到Qos信息后,自動(dòng)核對(duì)RTP的傳輸序列號(hào),統(tǒng)計(jì)丟包情況.通過(guò)Qos對(duì)RTP數(shù)據(jù)報(bào)序列號(hào)進(jìn)行檢測(cè),同時(shí)結(jié)合視頻流傳輸方案對(duì)視頻接收對(duì)象進(jìn)行替換,將按照RTP數(shù)據(jù)報(bào)序列號(hào)接收的視頻依次進(jìn)行交替,保證視頻接收的順序正確無(wú)誤.
圖4 通信流程
嵌入式web客戶端采用數(shù)據(jù)報(bào)式的sockets和客戶機(jī)通信發(fā)送基于RTP/UDP/IP協(xié)議的視頻數(shù)據(jù).要對(duì)遠(yuǎn)程視頻傳輸進(jìn)行控制,需要通過(guò)socket進(jìn)行遠(yuǎn)程控制.遠(yuǎn)程視頻監(jiān)控系統(tǒng)使用C#語(yǔ)言與ASP.Net進(jìn)行web程序和管理類庫(kù)的設(shè)計(jì),基于Sockets的底層通信實(shí)現(xiàn)對(duì)服務(wù)器的遠(yuǎn)程控制.使用
服務(wù)器根據(jù)客戶端的accept()將建立一個(gè)會(huì)話Session,使用兩個(gè)端口分別進(jìn)行RTP傳輸和RTCP傳輸.對(duì)于不同的會(huì)話,根據(jù)客戶方的網(wǎng)絡(luò)地址和端口進(jìn)行UDP調(diào)用,需要分別為rtp和rtcp創(chuàng)建兩個(gè)socket套接字rtp_socket和rtcp_socket.并通過(guò)sendto()接口,使用rtcp_socket和rtp_socket分別發(fā)送數(shù)據(jù)流信息和報(bào)告信息.
會(huì)話結(jié)構(gòu)定義如下所示.
typedef SessionStruct
{struct{PayloadProfile*profile; //負(fù)載屬性
float payload_type; //負(fù)載的類型定義
unsigned float ssrc; //源標(biāo)識(shí)符定義
}send,recv; //會(huì)話的發(fā)送與接收
RtpStream rtp_msg; //數(shù)據(jù)流信息
RtcpStream rtcp_msg; //報(bào)告流信息
}SessionDef;
信息流結(jié)構(gòu)定義如下所示.
typedef StreamStruct
{socket_Rtp socket; //信息流socket
struct addr_in addr_remote; //發(fā)送目標(biāo)
unsigned long send_num; //序列標(biāo)識(shí)
stream_states_msg states; //記錄狀態(tài)信息
unsigned float send_msg_last; //有效發(fā)送時(shí)間信息
unsigned float recv_msg_first; //收到信息時(shí)間
}StreamDef;
基于Internet瀏覽器與服務(wù)器端架構(gòu)的遠(yuǎn)程視頻監(jiān)控系統(tǒng)的操作管理平臺(tái)以ActiveX插件形式嵌入在web當(dāng)中,免去了下載并使用安裝程序的繁瑣步驟.同時(shí),為互聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控的查看與控制提供了更及時(shí)更方便的管理.其主要問(wèn)題在于對(duì)大量視頻數(shù)據(jù)的實(shí)時(shí)傳輸.視頻監(jiān)控的傳輸可根據(jù)系統(tǒng)的網(wǎng)絡(luò)狀況和應(yīng)用場(chǎng)景選擇或構(gòu)建相適應(yīng)的網(wǎng)絡(luò)傳輸方式,包含網(wǎng)絡(luò)架構(gòu)選擇(局域網(wǎng)/廣域網(wǎng))、傳輸方式選擇(有線/無(wú)線)、傳輸介質(zhì)選擇(網(wǎng)線/光纖).隨著TD-LTE、Wi-Fi、專網(wǎng)等無(wú)線、有線寬帶技術(shù)的成熟和應(yīng)用,大流量數(shù)據(jù)的遠(yuǎn)程傳送更加方便,這也掃除了網(wǎng)絡(luò)監(jiān)控在大范圍應(yīng)用中的傳輸障礙.目前,在金融聯(lián)網(wǎng)監(jiān)控等項(xiàng)目中通常采用自建光纖網(wǎng)絡(luò)或局域網(wǎng)絡(luò)實(shí)現(xiàn)1000M帶寬網(wǎng)絡(luò).這種千兆帶寬資源,在前端安裝100路1080P全實(shí)時(shí)高清網(wǎng)絡(luò)攝像機(jī)(即使按每路占用資源4Mbps計(jì)算),占用總帶寬資源不到50%;如果采用720P傳輸,帶寬還可以減少一半.這樣,完全可以有效支持網(wǎng)絡(luò)監(jiān)控的實(shí)際應(yīng)用,遠(yuǎn)程視頻監(jiān)控系統(tǒng)將會(huì)有更廣闊的發(fā)展空間.
[1]吳之惠,徐海峰,劉賢德.視頻采集在視頻監(jiān)控系統(tǒng)中的應(yīng)用[J].微計(jì)算機(jī)信息,2007(4):138-140.
[2]柳 偉,陳 旭,梁永生.H.264/SVC的 RTP封裝算法及其應(yīng)用[J].計(jì)算機(jī)工程與應(yīng)用,2010(19):27-32.
[3]楊海濤,王萬(wàn)良,劉鋒光,等.具有數(shù)據(jù)流和視頻流的Internet的遠(yuǎn)程控制系統(tǒng)[J].計(jì)算機(jī)工程,2006(3):254-256.
[4]唐智偉.基于 H.323協(xié)議的 H.264視頻傳輸[D].湘潭:湘潭大學(xué)圖書館,2008.
[5]陳 磊,金建祥,金敏凡.“基金會(huì)現(xiàn)場(chǎng)總線(FF)技術(shù)”講座 第3講FF總線中的差錯(cuò)控制與流量控制[J].自動(dòng)化儀表,2001(8):57-59.
[6]徐昌彪,隆克平.無(wú)線網(wǎng)絡(luò)中差錯(cuò)控制與擁塞控制策略的分析[J].重慶郵電學(xué)院學(xué)報(bào)(自然科學(xué)版),2001(1):31-32.
[7]龐文堯.基于C/S模式的遠(yuǎn)程控制系統(tǒng)研究開發(fā)[D].杭州:浙江大學(xué)圖書館,2003.
[8]張海軍,張建軍,楊印根,等.RTP傳輸控制的研究及實(shí)時(shí)視頻監(jiān)視系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].信息化縱橫,2009(5):54-61.
[9]陳 韜,張占軍,洪 君.流媒體的RTP傳輸與QoS管理策略研究[J].裝甲兵工程學(xué)院學(xué)報(bào),2005(3):25-28.
[10]彭 強(qiáng),楊天武,陳維榮,等.分布式遠(yuǎn)程視頻監(jiān)控系統(tǒng)視頻傳輸技術(shù)研究[J].鐵道學(xué)報(bào),2002(2):49-54.