??? 摘 要：為了機(jī)房的安全以及更好地管理，設(shè)計(jì)了機(jī)房實(shí)時(shí)監(jiān)視系統(tǒng)。采用H26x視頻編碼技術(shù)和RTP協(xié)議來實(shí)現(xiàn)，并且討論了基于RTP/RTCP協(xié)議的視頻實(shí)時(shí)傳輸中的控制方法。
??? 關(guān)鍵詞：實(shí)時(shí)傳輸協(xié)議；RTP／RTCP；H．26x ；G.729
?
??? 視頻監(jiān)控一直是人們十分關(guān)注的應(yīng)用技術(shù)熱點(diǎn)之一，它以其直觀、方便、信息內(nèi)容豐富而廣泛應(yīng)用于安保、生產(chǎn)管理等場合,成為金融、商業(yè)、交通乃至住宅、社區(qū)等領(lǐng)域安全防范監(jiān)控的重要手段,它為這些行業(yè)的安全防范和環(huán)境監(jiān)控起到了不可忽視的作用。傳統(tǒng)的機(jī)房都只能安排工作人員現(xiàn)場進(jìn)行管理，不能遠(yuǎn)程監(jiān)控、自由指揮，費(fèi)時(shí)、費(fèi)力，而且不能周密、全方位的監(jiān)視每個(gè)使用者，因此，為了機(jī)房的安全和更有效的管理，本文設(shè)計(jì)了機(jī)房實(shí)時(shí)視頻管理系統(tǒng)。該系統(tǒng)需要解決兩個(gè)方面的問題，一個(gè)是視頻圖像的編碼問題，另一個(gè)是其在網(wǎng)絡(luò)中的傳輸問題，而且兩方面是緊密聯(lián)系的。本研究提出基于RTP/RTCP協(xié)議構(gòu)建的機(jī)房實(shí)時(shí)視頻傳輸控制系統(tǒng)，傳輸層通信使用 UDP Socket 完成。
1 系統(tǒng)的組成與功能詳述
??? 機(jī)房監(jiān)控系統(tǒng)是由現(xiàn)場監(jiān)控設(shè)備、監(jiān)控服務(wù)器和監(jiān)控客戶端構(gòu)成?，F(xiàn)場監(jiān)控設(shè)備包括數(shù)字?jǐn)z像機(jī)、控制云臺、矩陣主機(jī)和模擬數(shù)字化設(shè)備、紅外線、雷達(dá)等。而監(jiān)控服務(wù)器對現(xiàn)場監(jiān)控設(shè)備發(fā)來的信息進(jìn)行驗(yàn)證、分發(fā)、處理和保存，并同時(shí)可以讓監(jiān)控客戶端通過視頻或通過Internet查看現(xiàn)場信息。這樣大大提高了監(jiān)控系統(tǒng)的覆蓋面和靈活性。系統(tǒng)模型如圖1所示。
?
?
2 傳統(tǒng)的TCP和UDP協(xié)議
??? TCP協(xié)議即傳輸控制協(xié)議，該協(xié)議首先要通過三次握手來建立連接，再利用“發(fā)送-等待確認(rèn)-再發(fā)送”機(jī)制來保證數(shù)據(jù)傳輸?shù)目煽啃?，但是顯然造成了對寶貴的網(wǎng)絡(luò)資源的嚴(yán)重浪費(fèi)，降低了傳輸效率，而且因?yàn)檫@種控制機(jī)制的時(shí)延太長，靈活性太差，不能滿足實(shí)時(shí)的音視頻數(shù)據(jù)的傳輸要求。而UDP協(xié)議，即用戶數(shù)據(jù)報(bào)協(xié)議，它為應(yīng)用程序之間提供面向無連接的、不可靠的數(shù)據(jù)報(bào)的傳輸服務(wù)。它是一個(gè)非常簡單的協(xié)議，沒有使用確認(rèn)機(jī)制來確保報(bào)文到達(dá)，沒有對傳入的報(bào)文重新排序的功能，也不提供反饋信息來控制機(jī)器之間信息流動的速度。所以UDP的報(bào)文傳輸可能出現(xiàn)丟失、重復(fù)、延遲以及亂序的錯(cuò)誤。所以說單獨(dú)的UDP協(xié)議也不適合實(shí)時(shí)的音視頻數(shù)據(jù)的傳輸。
3 RTP/RTCP協(xié)議及其傳輸控制方法
3.1 RTP/RTCP協(xié)議[1]
??? RTP協(xié)議主要是用來傳輸實(shí)時(shí)音/視頻數(shù)據(jù)，它包括RTP和RTCP兩種數(shù)據(jù)包。RTP包用于實(shí)時(shí)數(shù)據(jù)端到端傳輸，RTP包最大的特點(diǎn)就是其提供了時(shí)間戳(即發(fā)送數(shù)據(jù)塊首字節(jié)的創(chuàng)建時(shí)間)和序列號，以達(dá)到數(shù)據(jù)的同步和重組。而在RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失數(shù)據(jù)包的情況和數(shù)據(jù)包到達(dá)時(shí)延抖動等信息，通過該信息可以計(jì)算出如下有關(guān)的服務(wù)質(zhì)量參數(shù)：數(shù)據(jù)包丟失比、數(shù)據(jù)包時(shí)間片丟失比、數(shù)據(jù)包丟失率、數(shù)據(jù)包時(shí)間片丟失率、有效數(shù)據(jù)傳輸率、數(shù)據(jù)包傳輸率、吞吐量、吞吐率數(shù)據(jù)包到達(dá)時(shí)延抖動、往返傳播時(shí)延等等。通過這些參數(shù)可以監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量、通信帶寬以及網(wǎng)上傳送的信息。
3.2實(shí)時(shí)傳輸控制的方法
??? 遠(yuǎn)程網(wǎng)絡(luò)傳輸不可靠性主要表現(xiàn)在[2]:
??? (1)數(shù)據(jù)包“亂序到達(dá)”，先發(fā)送數(shù)據(jù)包有可能后到；
??? (2)在Internet環(huán)境下，網(wǎng)絡(luò)傳輸帶寬變動會引起發(fā)送的數(shù)據(jù)包丟失；
??? (3)數(shù)據(jù)包到達(dá)的時(shí)延過大而產(chǎn)生抖動會引起數(shù)據(jù)的失真。
3.2.1 利用RTP/RTCP進(jìn)行傳輸控制
??? RTP/RTCP能很好地解決上述問題。發(fā)送端和接收端應(yīng)遵循以下步驟：
??? (1)在接收端緩沖區(qū)中依靠RTP包中的序列號來調(diào)整到達(dá)數(shù)據(jù)包的順序，使之與發(fā)送時(shí)的數(shù)據(jù)順序一致。
??? (2)分析RTCP控制包。
??? (3)評估網(wǎng)絡(luò)狀態(tài)。采用某種判斷依據(jù)，評估實(shí)際的網(wǎng)絡(luò)擁塞狀況，以決定是否對帶寬需求進(jìn)行動態(tài)控制以改善服務(wù)質(zhì)量。
??? (4)調(diào)整所需帶寬。如接收端用戶可以設(shè)置可接受的最大和最小帶寬。
??? 為了改進(jìn)遠(yuǎn)程視頻傳輸系統(tǒng)的穩(wěn)定性，需建立一個(gè)傳輸控制模型，這樣可通過網(wǎng)絡(luò)狀況的反饋及時(shí)調(diào)整采樣頻率以及編碼格式以適應(yīng)當(dāng)前的網(wǎng)絡(luò)傳輸要求。RTCP利用主要的兩種控制包SR和RR反饋的信息如數(shù)據(jù)包丟失比、數(shù)據(jù)包丟失率、吞吐量和吞吐率、數(shù)據(jù)包到達(dá)時(shí)延抖動J(interarrival jitter)和往返傳播時(shí)延等來調(diào)節(jié)實(shí)時(shí)傳輸，并調(diào)整系統(tǒng)的打包格式、發(fā)包速率來保證流暢地傳輸數(shù)據(jù)和清晰地播放視頻。其服務(wù)質(zhì)量動態(tài)反饋控制的原理如圖2所示。
?
?
3.2.2 利用TCP進(jìn)行的新型傳輸控制
??? TCP不適合實(shí)時(shí)音視頻數(shù)據(jù)的傳輸。但是RTP協(xié)議可以利用TCP來實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)男碌目刂?，這種控制方法很獨(dú)特、新穎。因?yàn)槔肦TCP雖然可以實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)目刂疲渲饕窃谠炊撕徒邮斩酥g的參數(shù)交流，因而只能大概、初略地估計(jì)線路的阻塞程度，從而調(diào)整發(fā)送速率。隨著計(jì)算機(jī)網(wǎng)絡(luò)的迅速發(fā)展，擁塞控制機(jī)制的目標(biāo)從單獨(dú)地避免擁塞趨向于怎樣有效地利用網(wǎng)絡(luò)資源。RTCP中的控制將丟包和傳輸延遲的增長作為網(wǎng)絡(luò)出現(xiàn)擁塞的指示，沒有依賴于網(wǎng)絡(luò)的中間節(jié)點(diǎn)。在實(shí)際網(wǎng)絡(luò)中，引起網(wǎng)絡(luò)擁塞的因素是很多的：可能由于中間節(jié)點(diǎn)隊(duì)列溢出引起丟包，也可能是由于設(shè)備故障或者鏈路干擾導(dǎo)致節(jié)點(diǎn)校驗(yàn)錯(cuò)誤引起丟包；可能由于中間節(jié)點(diǎn)隊(duì)列長度增長引起延遲增加，也可能由于傳輸路徑很長(如衛(wèi)星鏈路)或者鏈路層數(shù)據(jù)包重傳引起延遲增加。因此，利用TCP協(xié)議，可以反映網(wǎng)絡(luò)的中間節(jié)點(diǎn)對擁塞的影響程度，從而采用多種擁塞控制機(jī)制來保證服務(wù)質(zhì)量。可以大致地將其劃分為3類：(1)基于丟包反饋地協(xié)議LCA(loss-based congestion avoidance); (2)基于路徑延時(shí)反饋地協(xié)議DCA(delay-based congestion avoidance); (3)基于顯式反饋的協(xié)議ECN(explicit congestion notification)。
??? 即在源端發(fā)送一些TCP探測包，經(jīng)過中間網(wǎng)絡(luò)節(jié)點(diǎn)，到達(dá)接收端，接收端再發(fā)送TCP數(shù)據(jù)包，與源端進(jìn)行交流，從而達(dá)到傳輸控制。TCP用于RTP傳輸控制如圖3所示。
?
4 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)
??? 系統(tǒng)的實(shí)現(xiàn)是在Visualc++6.0環(huán)境下[3-4]，采用H.263/H.264視頻編碼，G726音頻壓縮編碼。傳輸控制子系統(tǒng)是基于RTP/RTCP協(xié)議構(gòu)建，通過傳輸層的UDP Socket完成實(shí)時(shí)傳輸。
4.1 現(xiàn)場監(jiān)控設(shè)備的實(shí)現(xiàn)
??? 現(xiàn)場監(jiān)控設(shè)備通過網(wǎng)絡(luò)初始化后，實(shí)現(xiàn)與服務(wù)器的連接。通過監(jiān)控設(shè)備開啟錄音和攝像程序，不間斷地采集現(xiàn)場音視頻信息,然后經(jīng)過G.729音頻、H.263/H.264視頻編碼壓縮，再經(jīng)過封包并通過網(wǎng)絡(luò)傳給服務(wù)器。待監(jiān)控設(shè)備收到數(shù)據(jù)采集結(jié)束的信息通知后，才停止采集過程。該部分主要是完成數(shù)據(jù)的采集、打包、壓縮以及數(shù)據(jù)的存儲和發(fā)送。數(shù)據(jù)發(fā)送結(jié)構(gòu)如圖4所示。系統(tǒng)的模塊組成框圖如圖5所示。
?
?
4.2 監(jiān)控服務(wù)器的實(shí)現(xiàn)
??? 監(jiān)控服務(wù)器端是本智能系統(tǒng)的核心部分，功能多，設(shè)計(jì)復(fù)雜[5-6]。主要是根據(jù)監(jiān)控信息進(jìn)行相關(guān)的數(shù)據(jù)處理并完成對監(jiān)控客戶端的數(shù)據(jù)實(shí)時(shí)傳輸和實(shí)時(shí)監(jiān)控。服務(wù)器端主要分為如下模塊：網(wǎng)絡(luò)管理、協(xié)議分發(fā)、代理模塊、管理模塊、登錄管理、終端管理、監(jiān)控端管理、文件管理、數(shù)據(jù)庫管理、日志管理及UI(用戶接口)等模塊。系統(tǒng)結(jié)構(gòu)如圖6所示。
?
4.3 監(jiān)控客戶端的實(shí)現(xiàn)
??? 監(jiān)控客戶端主要包括兩類用戶：常規(guī)固定監(jiān)控客戶端和移動手機(jī)監(jiān)控客戶端。主要負(fù)責(zé)日常的監(jiān)控管理，可以通過網(wǎng)絡(luò)Web和手機(jī)監(jiān)控播放器兩種模式查看現(xiàn)場信息。如進(jìn)行視頻監(jiān)控、保存回放、連續(xù)錄像、文件檢索以及網(wǎng)絡(luò)傳輸?shù)榷喾N功能綜合的多元化需求。系統(tǒng)結(jié)構(gòu)如圖7所示。
?
5 監(jiān)視系統(tǒng)的應(yīng)用
??? 本系統(tǒng)的一種實(shí)現(xiàn)形式就是直接使用機(jī)房的計(jì)算機(jī)，通過安裝攝像頭或紅外線探頭，采集視頻圖像，壓縮編碼后，通過機(jī)房內(nèi)部網(wǎng)絡(luò)傳輸?shù)綑C(jī)房管理控制中心，方便機(jī)房管理人員了解機(jī)房內(nèi)學(xué)生上機(jī)的情況。另一種形式是把視頻采集編碼程序通過DSP編譯和優(yōu)化[7-8]，然后移植到DSP平臺上，通過網(wǎng)絡(luò)傳送到接收端實(shí)時(shí)顯示[9-10]。在Internet網(wǎng)絡(luò)上進(jìn)行視頻實(shí)時(shí)傳送，需要進(jìn)行QOS服務(wù)質(zhì)量控制，否則傳輸質(zhì)量滿足不了要求，效果也很差。本系統(tǒng)由于采用RTP/RTCP協(xié)議進(jìn)行傳輸質(zhì)量控制，在Internet網(wǎng)絡(luò)上實(shí)現(xiàn)的效果也非常好，在家里、網(wǎng)吧等也可以實(shí)時(shí)看到機(jī)房的情況，滿足了機(jī)房實(shí)時(shí)視頻監(jiān)視的需要[11]。
??? 針對機(jī)房的安全以及機(jī)房使用的管理情況設(shè)計(jì)了機(jī)房實(shí)時(shí)監(jiān)視系統(tǒng)。該系統(tǒng)通過在局域網(wǎng)和Internet網(wǎng)絡(luò)上的多次實(shí)驗(yàn)，表明在局域網(wǎng)環(huán)境下，網(wǎng)絡(luò)通信較為簡單，傳輸質(zhì)量較好，在Internet網(wǎng)絡(luò)環(huán)境下，跳幀現(xiàn)象明顯，通過有效的傳輸質(zhì)量控制，傳輸幀率一般保持在每秒15～30幀，圖像效果很好，當(dāng)視頻背景快速移動時(shí)，運(yùn)算復(fù)雜度增大，傳輸幀率會降低，須即時(shí)調(diào)整，確保傳輸質(zhì)量的穩(wěn)定。
參考文獻(xiàn)
[1] Sehulzrine H. RTP Profile for Audio and Video Conferences with Minimal Control.RFC1890，IETF，1996.2-10.
[2]?Basturk E, Birman A. Design and Implement of A QoS Capable Switch-router. Computer Networks and ISDN Systems，1999，31(1/2):19-32.
[3]?David J，KrL-glinski. K L. Inside? Visual C++. Waslling ton:Microsoft Press，1997; 206-223.
[4]?Anthony Jones，Jimohlund. Windows網(wǎng)絡(luò)編程技術(shù)[M]. 北京：機(jī)械工業(yè)出版社，2000
[5]?Sehulzrinne.H. RTP Profile for Audio and Video Conference switch Minimal Control[S].InternetRFC1890.1996-01
[6]?Sen S，Cao L，RexfordJ，etal. Optimal Patching scheme for efficient multimedia Streaming .Proe.Int.Conf.011 Network and Operating System Support for Digital Audio and Video，1999，(6):1024-1032.
[7]?王飛. MpEG -4標(biāo)準(zhǔn)及多媒體應(yīng)用.電子技術(shù)，2001(3):17-22.
[8]?吳國勇，邱學(xué)剛. 網(wǎng)絡(luò)視頻：流媒體技術(shù)與應(yīng)用. 北京：北京郵電大學(xué)出版社，2001。
[9]?徐京，魯士文.TCP/IP網(wǎng)絡(luò)環(huán)境下的視頻圖像傳輸.計(jì)算機(jī)工程與應(yīng)用，1999(12):98-100.
[10]?凍 堅(jiān)，陳偉. Visual C++網(wǎng)絡(luò)高級編程. 北京：人民郵電出版社，2002.7-95.
[11]?馮 嘩，馮忠義，曹寧.基于socket網(wǎng)絡(luò)編程接口實(shí)現(xiàn)局域網(wǎng)上視頻傳輸?shù)膽?yīng)用研究. 微計(jì)算機(jī)信息，1998，14(5).