曹型兵，李 津，薛 萌

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

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

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

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

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

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

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

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

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

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

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

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

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

視頻數(shù)據(jù)被視頻服務(wù)器從攝像頭采集，視頻數(shù)據(jù)通過(guò)H.264編碼［2］被打包成RTP包格式，然后對(duì)RTP包進(jìn)行UDP封裝，最后以視頻服務(wù)器把視頻數(shù)據(jù)以UDP包格式發(fā)送給轉(zhuǎn)發(fā)服務(wù)器。由于網(wǎng)絡(luò)環(huán)境的不穩(wěn)定，轉(zhuǎn)發(fā)服務(wù)器必須向視頻服務(wù)器對(duì)接收到的視頻流的質(zhì)量進(jìn)行反饋，這需要用到與RTP相對(duì)應(yīng)的RTCP協(xié)議。轉(zhuǎn)發(fā)服務(wù)器向客戶端和存儲(chǔ)服務(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é)議交互圖

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

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

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

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

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

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

圖3 主線程操作流程圖

主線程操作流程步驟為:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文是在Windows系統(tǒng)下，以VC++6.0為開發(fā)平臺(tái)，用C++語(yǔ)言進(jìn)行開發(fā)的，因?yàn)槭褂昧顺墒斓腤INAPI函數(shù)和JRTPLIB庫(kù)函數(shù)，所以該程序具有比較好的穩(wěn)定性。

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

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

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

5 結(jié)論

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

［1］張海濤，蔡文寰，董有爾.基于DM642的圖像處理系統(tǒng)設(shè)計(jì)及應(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.計(jì)算機(jī)網(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é)議的實(shí)時(shí)視頻監(jiān)控系統(tǒng)的實(shí)現(xiàn)［J］.大眾科技，2008(8):64－65.

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

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

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

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