無線視頻監(jiān)控系統(tǒng)中分發(fā)服務(wù)器的研究及實現(xiàn)

曹型兵，李 津，薛 萌

(重慶郵電大學(xué)a.通信工程應(yīng)用研究所;b.通信新技術(shù)應(yīng)用研究所，重慶 400065)

責(zé)任編輯:任健男

隨著監(jiān)控系統(tǒng)的大量應(yīng)用，監(jiān)控系統(tǒng)的功能越來越多，結(jié)構(gòu)越來越復(fù)雜，從而傳輸?shù)男畔⒘考眲∨蛎洠瑐鹘y(tǒng)的監(jiān)控系統(tǒng)對于如此龐大的信息量，暴露出越來越多的局限性，總體而言，可以歸納成為:1)網(wǎng)絡(luò)帶寬有限性和用戶數(shù)不斷增加。每個用戶都可能向多個監(jiān)控點請求實時視頻，每個監(jiān)控點也可能向多個用戶傳輸實時視頻，這樣就出現(xiàn)了多路重復(fù)傳輸?shù)囊曨l，勢必造成信息量的增加。在廣域網(wǎng)中，可能會出現(xiàn)網(wǎng)絡(luò)擁塞。2)用戶的動態(tài)性增減對監(jiān)控系統(tǒng)的影響。用戶在接收視頻數(shù)據(jù)之前要先向監(jiān)控點進行視頻請求，當(dāng)同時請求的用戶數(shù)達到監(jiān)控點處理的最大值后，視頻網(wǎng)絡(luò)傳輸量也會大量增加，從而導(dǎo)致圖像質(zhì)量嚴重下降，出現(xiàn)丟包、圖像抖動等現(xiàn)象。

為了解決上述問題，本文研究設(shè)計了視頻分發(fā)服務(wù)器，該模型可以較好地保證用戶的視頻圖像質(zhì)量，有效減少上述不良現(xiàn)象的出現(xiàn)。

1 無線視頻監(jiān)控系統(tǒng)的組成

無線視頻監(jiān)控系統(tǒng)結(jié)構(gòu)圖如圖1所示。

攝像頭是無線視頻監(jiān)控系統(tǒng)最前端的組成部分，負責(zé)視頻數(shù)據(jù)的采集，然后通過有線傳遞給視頻服務(wù)器，構(gòu)造復(fù)雜的攝像頭叫做云臺，方向可轉(zhuǎn)動，進行多角度監(jiān)控。

圖1 無線視頻監(jiān)控系統(tǒng)結(jié)構(gòu)圖

本系統(tǒng)的視頻服務(wù)器采用了TI公司的DaVinci［1］解決方案，主要用來處理攝像頭傳輸過來的原始視頻數(shù)據(jù)，攝像頭采集到信息后直接交給視頻監(jiān)控終端，視頻監(jiān)控終端進行H.264編碼［2］和封裝數(shù)據(jù)，并通過無線網(wǎng)絡(luò)發(fā)送數(shù)據(jù)流到轉(zhuǎn)發(fā)服務(wù)器。

轉(zhuǎn)發(fā)存儲局域網(wǎng)是整個有線傳輸?shù)暮诵模D(zhuǎn)發(fā)即把接收到的視頻服務(wù)器發(fā)過來的數(shù)據(jù)分發(fā)到多個客戶端，如果客戶有錄像請求，則把數(shù)據(jù)發(fā)送到存儲服務(wù)器，這兩個過程并不矛盾，可以同時進行。

客戶端即客戶使用的設(shè)備終端，包括計算機、電視墻等，向上文所述的各個服務(wù)器發(fā)送指令，進行指定功能的實現(xiàn)。

2 視頻轉(zhuǎn)發(fā)的思路分析

在分析視頻轉(zhuǎn)發(fā)可行性之前，有必要先對視頻幀的結(jié)構(gòu)進行分析，視頻幀由多個RTP包組成，相同RTP包的時間戳是相同的，相鄰視頻幀的時間戳［3］相差一個固定數(shù)值，相同幀的每個RTP包的序列號不同，且在視頻幀中依次遞增，視頻幀的最后一個包存在一個mark位，用來區(qū)分不同的幀。

視頻數(shù)據(jù)被視頻服務(wù)器從攝像頭采集，視頻數(shù)據(jù)通過H.264編碼［2］被打包成RTP包格式，然后對RTP包進行UDP封裝，最后以視頻服務(wù)器把視頻數(shù)據(jù)以UDP包格式發(fā)送給轉(zhuǎn)發(fā)服務(wù)器。由于網(wǎng)絡(luò)環(huán)境的不穩(wěn)定，轉(zhuǎn)發(fā)服務(wù)器必須向視頻服務(wù)器對接收到的視頻流的質(zhì)量進行反饋，這需要用到與RTP相對應(yīng)的RTCP協(xié)議。轉(zhuǎn)發(fā)服務(wù)器向客戶端和存儲服務(wù)器傳輸數(shù)據(jù)流是以UDP包封裝的RTP包格式，故用到UDP［4］和RTP協(xié)議。轉(zhuǎn)發(fā)服務(wù)器與系統(tǒng)中其他部分間的協(xié)議交互如圖2所示。

圖2 轉(zhuǎn)發(fā)服務(wù)器與視頻監(jiān)控系統(tǒng)中其他部分間的協(xié)議交互圖

客戶端對視頻數(shù)據(jù)的請求可能實時更新，存在同時傳輸多路視頻的情況，由于請求的不確定性和多路視頻流轉(zhuǎn)發(fā)同時轉(zhuǎn)發(fā)的可能性，采取單線程輪詢的方式是不合適的，因此本設(shè)計決定采用多線程的方式。一個主線程負責(zé)處理轉(zhuǎn)發(fā)信息，多個子線程根據(jù)轉(zhuǎn)發(fā)信息開啟或關(guān)閉，從而達到多路視頻同時轉(zhuǎn)發(fā)，每個子線程轉(zhuǎn)發(fā)一路視頻到多個目的IP的目的。

視頻流在轉(zhuǎn)發(fā)服務(wù)器中以RTP包為基礎(chǔ)重新打包，這時候轉(zhuǎn)發(fā)的只是RTP負載，RTP頭會重新添加，因此所有包的時間戳都是相同的［5－8］?？蛻舳撕痛鎯Ψ?wù)器接收到RTP包后進行后續(xù)的排序組幀，根據(jù)前面所述，相同幀的所有包的時間戳是相同的，相鄰幀的RTP包的時間戳相差一個固定值，即通常所說的時間戳增量。時間戳應(yīng)該由RTP包頭的mark位決定，遇到mark位后，下一個RTP包增加一個時間戳增量［3］，時間戳增量由以下公式?jīng)Q定

式中:FrameRate為幀率，本設(shè)計采用最常用的25幀/秒(f/s);ClockFrequency為時鐘頻率，本設(shè)計采用90 kHz，根據(jù)計算可得時間戳增量為3 600。

3 視頻轉(zhuǎn)發(fā)的具體實現(xiàn)

3.1 以控制子線程啟閉為目的的主線程的實現(xiàn)

主線程操作流程圖如圖3所示。

圖3 主線程操作流程圖

主線程操作流程步驟為:

1)建立一個全局分發(fā)信息數(shù)組，該數(shù)組的元素是一個包括iFlag，iPos和iCount的結(jié)構(gòu)體。這是為了提高子線程運行時更新分發(fā)信息的效率。當(dāng)子線程的分發(fā)目的信息有改變時，子線程可以根據(jù)iFlag的值第一時間獲得該變化，根據(jù)iPos和iCount快速獲得分發(fā)目的信息在分發(fā)鏈表中的起始位置和數(shù)量。

2)建立一個線程作為主線程，此線程一直保持開啟狀態(tài)，直到程序最終關(guān)閉。

3)定義一個定時器，以保證對數(shù)據(jù)庫的定時掃描。該定時器時間間隔根據(jù)實際情況設(shè)定，以500 ms～2 s為宜，本設(shè)計設(shè)定為1 s。

4)主線程定時掃描數(shù)據(jù)庫，以獲取包括分發(fā)目的端口號和IP的分發(fā)信息。

5)進行分發(fā)信息的對比，以更新分發(fā)子線程的轉(zhuǎn)發(fā)目的或啟閉分發(fā)子線程。這是最復(fù)雜的一個步驟，本設(shè)計自定義了一個算法進行實現(xiàn)，該算法包括兩部分:當(dāng)前與上次獲得的分發(fā)線程轉(zhuǎn)發(fā)目的信息的對比，當(dāng)前與上次獲得的分發(fā)線程啟閉信息的對比。第一個對比通過對分發(fā)信息鏈表的端口和IP地址的組合數(shù)據(jù)進行排序、差分計算、鏈表更新等幾部分實現(xiàn)，第一個對比與其類似，只是對比元素換成了端口號，且必須去掉重復(fù)元素。這一步驟保證了視頻分發(fā)的實時更新，提高了執(zhí)行效率。

6)根據(jù)分發(fā)信息對比結(jié)果進行子線程啟閉以及子線程轉(zhuǎn)發(fā)目的的更新。線程開啟采用常用的WINAPI函數(shù)CreateThread［9］，線程關(guān)閉采用了更改標(biāo)記位，運用返回值的方式。線程開啟所用的端口號參數(shù)通過建立vector，并以依次獲得的方式進行傳遞。當(dāng)上述流程結(jié)束后，一個循環(huán)結(jié)束，等待定時器到達，以繼續(xù)另一個循環(huán)，即重復(fù)步驟4)～步驟6)。

3.2 視頻轉(zhuǎn)發(fā)子線程的實現(xiàn)

視頻分發(fā)子線程的流程圖如圖4所示，具體步驟如下:

1)建立RTP會話。視頻傳輸是以RTP包為基礎(chǔ)的，建立RTP會話可以建立視頻服務(wù)器和轉(zhuǎn)發(fā)服務(wù)器之間的連接，形成一條傳輸RTP包的通道。

2)設(shè)定RTP會話所需的各種參數(shù)，包括設(shè)定自己的時間戳單元、是否接收RTP數(shù)據(jù)包、設(shè)定接收RTP包的接收端口等。

3)進行RTP會話檢錯。主要檢測當(dāng)前端口是否被占用以及傳輸?shù)腞TP包大小是否超出RTP會話傳輸?shù)淖畲笾怠TP會話允許的傳輸最大數(shù)據(jù)包大小默認為1 400 byte。

4)看該線程是否應(yīng)該終止，如果符合終止條件，關(guān)閉該線程，本設(shè)計關(guān)閉線程采用返回值的方式，否則直接執(zhí)行下一步。

圖4 視頻分發(fā)子線程操作流程圖

5)接收視頻服務(wù)器發(fā)送的RTCP格式的sr包，通過一系列的計算獲得丟包率、累計丟包數(shù)、接收到的擴展的最高序列號以及到達時間間隔抖動(IJ)的參數(shù)。其中IJ根據(jù)公式計算得到，計算方法如下:假定Si是包i中的RTP時間戳，Ri是包i到達時刻。對于2個包i和j，到達時刻抖動［10］根據(jù)公式 J=J+(|D(i－1，i)|－ J)/16計算，其中D為當(dāng)前包和前一包(i－1)的偏差，可以用公式D(i，j)=(Rj－Sj)－(Ri－Si)獲得。計算完上述參數(shù)后，封裝成RTCP格式的rr包，然后發(fā)送給視頻服務(wù)器。視頻服務(wù)器根據(jù)接收到的rr包對視頻流的發(fā)包速率、發(fā)包大小等參數(shù)進行調(diào)整，以使視頻更流暢。

6)進行轉(zhuǎn)發(fā)目的IP和端口的設(shè)定，可進行自身的轉(zhuǎn)發(fā)。自身轉(zhuǎn)發(fā)可把目的IP設(shè)為127.0.0.1，目的端口根據(jù)自身需要增加一個值。接收數(shù)據(jù)源，并轉(zhuǎn)發(fā)RTP包。轉(zhuǎn)發(fā)的RTP包的時間戳根據(jù)mark位進行設(shè)定，如果接收到的當(dāng)前包無mark位標(biāo)記，該包的時間戳增量為0，否則，該包的時間戳增量設(shè)為3 600，即該包的下一包的時間戳增加3 600。

7)刪除剛剛轉(zhuǎn)發(fā)的RTP包。這樣做是為了節(jié)約內(nèi)存，采用jrtplib自帶的DeletePacket函數(shù)實現(xiàn)。

8)RTP會話結(jié)束，關(guān)閉該會話。通過發(fā)送RTCP的bye包結(jié)束該RTP會話。

4 運用該轉(zhuǎn)發(fā)機制前后視頻效果的對比

本文是在Windows系統(tǒng)下，以VC++6.0為開發(fā)平臺，用C++語言進行開發(fā)的，因為使用了成熟的WINAPI函數(shù)和JRTPLIB庫函數(shù)，所以該程序具有比較好的穩(wěn)定性。

轉(zhuǎn)發(fā)前后均采用了VLC播放器進行解碼播放，圖5和圖6是直接對同一時間、同一場景的轉(zhuǎn)發(fā)前后的視頻截圖對比。從播放效果來看，轉(zhuǎn)發(fā)前后視頻均播放流暢，沒有明顯差異，轉(zhuǎn)發(fā)之后視頻未出現(xiàn)馬賽克效應(yīng)，用wireshark抓包發(fā)現(xiàn)，轉(zhuǎn)發(fā)前發(fā)送5 000個包，轉(zhuǎn)發(fā)后接收到4 955個，丟包率僅為0.9%，在不影響播放效果的情況下，這屬于正常范圍。不足之處在于，轉(zhuǎn)發(fā)后視頻存在1～2 s的延時，在一般情況下這是允許的，但是在要求嚴格的特殊情況下，這種延時是要予以解決的。

圖5 轉(zhuǎn)發(fā)前視頻截圖

圖6 轉(zhuǎn)發(fā)后視頻截圖

5 結(jié)論

本文對在無線視頻監(jiān)控系統(tǒng)中進行視頻分發(fā)的可行性進行了分析，并用C++語言在Windows平臺上實現(xiàn)，最后用VLC播放器播放。測試結(jié)果顯示，轉(zhuǎn)發(fā)后畫面流暢，播放效果良好。但是筆者認為還應(yīng)從減少時延、進一步減少丟包率等方面加以改進，并進行長時間的觀測和更多路視頻的轉(zhuǎn)發(fā)，以使程序更加穩(wěn)定。

［1］張海濤，蔡文寰，董有爾.基于DM642的圖像處理系統(tǒng)設(shè)計及應(yīng)用［J］.現(xiàn)代電子技術(shù)，2008，12(27):125－127.

［2］畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)——H.264/AVC［M］.北京:人民郵電出版社，2005.

［3］RFC3984，RTP payload format for H.264 video［S］.2005.

［4］TANENBAUM A S.計算機網(wǎng)絡(luò)［M］.北京:清華大學(xué)出版社，2004.

［5］PERKINS C.RTP:audio and video for the Internet［M］.Boston，USA:Addison－Wesley Professional，2006.

［6］王祥，黃廷輝.基于RTP協(xié)議的實時視頻監(jiān)控系統(tǒng)的實現(xiàn)［J］.大眾科技，2008(8):64－65.

［7］趙進，葉梧，馮穗力.基于RTP協(xié)議族的流媒體系統(tǒng)設(shè)計和實現(xiàn)［J］.計算機工程，2005(2):195－197.

［8］李校林，劉海波，張杰，等.RTR/RTCP，RTSP在無線視頻監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)［J］.電視技術(shù)，2011，35(19):89 －92.

［9］孫鑫，余安萍.VC++深入詳解［M］.北京:電子工業(yè)出版社，2006.

［10］RFC3550，real－time transport protocol［S］.2008.