楊明極，許雪松，李天池

(哈爾濱理工大學(xué) 測(cè)控技術(shù)與通信工程學(xué)院，黑龍江哈爾濱150080)

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

1 移動(dòng)視頻服務(wù)器簡(jiǎn)介

隨著第三代通信網(wǎng)絡(luò)的覆蓋和移動(dòng)互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，在無(wú)線網(wǎng)絡(luò)中傳輸實(shí)時(shí)視頻成為通信和計(jì)算機(jī)領(lǐng)域研究的熱點(diǎn)，適用于無(wú)線視頻傳輸?shù)膸挵l(fā)展為無(wú)線視頻系統(tǒng)的發(fā)展帶來(lái)了新的飛躍，而無(wú)線3G網(wǎng)絡(luò)以其高速的靈活性、便捷性、移動(dòng)性等特性成為了最佳網(wǎng)絡(luò)的傳輸環(huán)境[1]。信息技術(shù)的發(fā)展也推進(jìn)了社會(huì)的進(jìn)步，各個(gè)領(lǐng)域也把移動(dòng)視頻模塊應(yīng)用到各自的行業(yè)中，例如手機(jī)實(shí)時(shí)視頻在政府、電力、交通、金融、公安等部門(mén)有了廣泛的應(yīng)用。

本移動(dòng)視頻服務(wù)器基于3G網(wǎng)絡(luò)環(huán)境，視頻卡采集到實(shí)時(shí)視頻流，流媒體服務(wù)器采用了MPEG-4壓縮標(biāo)準(zhǔn)對(duì)視頻流進(jìn)行壓縮編碼。無(wú)線網(wǎng)絡(luò)的傳輸具有帶寬波動(dòng)大、高誤碼率、異類(lèi)性和嚴(yán)格的時(shí)延等問(wèn)題，因此本文采用RTP/RTCP協(xié)議端到端傳輸和控制，并經(jīng)過(guò)RTP(Realtime Transport Protocol)封裝的MPEG-4碼流傳輸?shù)绞謾C(jī)客戶(hù)端。系統(tǒng)總體模型如圖1所示。

2 MPEG-4編碼標(biāo)準(zhǔn)及RTP/RTCP協(xié)議

2.1 MPEG-4編碼標(biāo)準(zhǔn)

圖1 系統(tǒng)總體模型

MPEG-4對(duì)音視頻和圖形的壓縮采取了基于內(nèi)容的存取、傳輸，它提供了針對(duì)對(duì)象而非像素的瀏覽、訪問(wèn)、操作技術(shù)，并且給用戶(hù)提供了與可視內(nèi)容進(jìn)行交互的高水平能力。MPEG-4包括支持形狀編碼、運(yùn)動(dòng)估計(jì)與補(bǔ)償、紋理編碼、差錯(cuò)復(fù)原、分級(jí)編碼和Sprite編碼的各種應(yīng)用工具集組成[2]。在MPEG-4中，把視頻信號(hào)看成為不同的對(duì)象(object)組成，這些對(duì)象可以單獨(dú)地進(jìn)行編碼操作和直接訪問(wèn)，從而以?xún)?nèi)容為核心的描述方法的編碼標(biāo)準(zhǔn)有著更優(yōu)越的壓縮性能[3]。MPEG-4支持的功能可以分為基于內(nèi)容的交互性、高效的壓縮性和通用的訪問(wèn)性三種特性。

2.2 RTP/RTCP協(xié)議

RTP/RTCP協(xié)議是建立在因特網(wǎng)上的處理實(shí)時(shí)多媒體數(shù)據(jù)流的傳輸協(xié)議。RTP協(xié)議在一對(duì)一或一對(duì)多機(jī)制下協(xié)同工作，負(fù)責(zé)提供實(shí)現(xiàn)流和時(shí)間信息同步，RTP是建立在UDP協(xié)議上，所以不能為多媒體流數(shù)據(jù)提供可靠的傳輸機(jī)制，只能保障數(shù)據(jù)的實(shí)時(shí)傳輸而不能提供擁塞控制和流量控制[4]。而RTCP(RTP Control Protocol)是RTP的控制協(xié)議，負(fù)責(zé)管理傳輸在當(dāng)前應(yīng)用進(jìn)程之間交換的控制信息[5]。在RTP傳輸?shù)臅?huì)話(huà)期間，每個(gè)用戶(hù)端周期性的傳輸RTCP數(shù)據(jù)包，其中包括已經(jīng)發(fā)送或者丟失的數(shù)據(jù)包的相關(guān)信息，這時(shí)反饋到服務(wù)器端，而服務(wù)器端可根據(jù)反饋信息的調(diào)整數(shù)據(jù)流的傳輸[6]。在流媒體數(shù)據(jù)傳輸?shù)倪^(guò)程中，服務(wù)器端和客戶(hù)端的RTP和RTCP協(xié)議成對(duì)的協(xié)調(diào)使用，服務(wù)器程序啟動(dòng)RTP連接的同時(shí)會(huì)占用兩個(gè)供RTP和RTCP使用的端口[7]。QoS的監(jiān)控信息放在RTCP的數(shù)據(jù)報(bào)中，RTCP對(duì)服務(wù)質(zhì)量和網(wǎng)絡(luò)阻塞情況進(jìn)行動(dòng)態(tài)控制和反饋[8]。

3 服務(wù)器軟件結(jié)構(gòu)

本系統(tǒng)由視頻采集終端、視頻服務(wù)器端、3G通信傳輸網(wǎng)絡(luò)和手機(jī)客戶(hù)端組成。視頻采集終端負(fù)責(zé)視頻流的采集，視頻服務(wù)器端負(fù)責(zé)把接收到的視頻流通過(guò)MPEG-4壓縮編碼，并將標(biāo)準(zhǔn)的視頻碼流通過(guò)3G網(wǎng)絡(luò)傳輸至客戶(hù)端，服務(wù)器系統(tǒng)框圖如圖2所示。

圖2 視頻服務(wù)器框圖

視頻服務(wù)器的主要任務(wù)是通過(guò)RTP Sender和客戶(hù)端RTP Recv通信以及發(fā)送視頻流數(shù)據(jù)，而在客戶(hù)端監(jiān)控到視頻流的狀態(tài)信息和質(zhì)量信息，并通過(guò)RTCP/UDP/IP協(xié)議將反饋信息傳輸?shù)揭曨l服務(wù)器。在服務(wù)器中以RTCP控制信息提供給流媒體服務(wù)器，在網(wǎng)絡(luò)端口進(jìn)行TCP監(jiān)聽(tīng)，與已經(jīng)請(qǐng)求到連接的客戶(hù)端進(jìn)行流媒體數(shù)據(jù)通信，服務(wù)器收到客戶(hù)端監(jiān)聽(tīng)的RTP端口信息，并在RTP發(fā)送列表中加入客戶(hù)端的端口和IP地址。服務(wù)器在接收到了客戶(hù)端的信息之后，就開(kāi)始向請(qǐng)求服務(wù)的客戶(hù)端的相應(yīng)端口和IP地址發(fā)送視頻流數(shù)據(jù)，在通信結(jié)束后服務(wù)器收到Teardown信息后即停止向指定的客戶(hù)端發(fā)送數(shù)據(jù)?？蛻?hù)端向視頻服務(wù)器發(fā)送RTCP反饋信息，獲取到實(shí)時(shí)視頻流信息并向服務(wù)器發(fā)送客戶(hù)端的視頻模塊的通信監(jiān)聽(tīng)端口，客戶(hù)端初始化視頻解碼模塊和分配視頻緩沖區(qū)，接收到的視頻流通過(guò)流媒體播放器對(duì)解碼播放。

4 視頻服務(wù)器設(shè)計(jì)與實(shí)現(xiàn)

4.1 MPEG-4編碼的實(shí)現(xiàn)

Xvid是MPEG-4標(biāo)準(zhǔn)中的一個(gè)開(kāi)放源代碼的視頻解碼器，它在一定程度上繼承了OpenDivX EncoreZ，性能極大提高，目前被業(yè)界看作是MPEG-4中最快的解碼器之一，因此在本視頻服務(wù)器中采用XviD的開(kāi)源代碼庫(kù)xvidcore-1.0.1作為解碼庫(kù)。

在打開(kāi)視頻采集模塊之后，設(shè)置視頻輸入通道和緩沖，并直接把采集到的信號(hào)類(lèi)型RGB直接映射到內(nèi)存上，然后把RGB轉(zhuǎn)換成Xvid編碼器所支持的YUN格式傳給編碼端。編碼器的主要模塊由傳統(tǒng)的運(yùn)動(dòng)和紋理編碼和VOP形狀編碼部分構(gòu)成，零散的VO內(nèi)容被VOP的形狀信息整合成場(chǎng)景，實(shí)現(xiàn)Simple/Level 1框架將整個(gè)幀看作是一個(gè)矩形VOP，而不采用形狀編碼，基于VOP的編碼結(jié)構(gòu)圖如圖3所示。

圖3 基于VOP的編碼結(jié)構(gòu)圖

MPEG-4編碼標(biāo)準(zhǔn)是基于VOP的編碼結(jié)構(gòu)設(shè)計(jì)而實(shí)現(xiàn)的，根據(jù)CIR來(lái)判斷當(dāng)前的幀是Delta幀，Delta幀運(yùn)動(dòng)估計(jì)/補(bǔ)償模塊是按照宏塊進(jìn)行的，對(duì)像素差值根據(jù)不同的編碼質(zhì)量按照宏塊進(jìn)行半像素搜索，然后當(dāng)前的編碼模式由SAD計(jì)算確定。通過(guò)運(yùn)動(dòng)估計(jì)/補(bǔ)償以后，得到Delta幀的編碼模式為P-VOP。經(jīng)過(guò)預(yù)測(cè)補(bǔ)償后的殘差數(shù)據(jù)就是此時(shí)的編碼數(shù)據(jù)，同時(shí)需要獲取MV信息。在MV編碼過(guò)程中，分離出的垂直和水平的分量獨(dú)立編碼，還有右下方的MV編碼值利用之前3個(gè)值的均值來(lái)進(jìn)行預(yù)測(cè)。得到的此時(shí)MV預(yù)測(cè)值之間的差值限制在ME的搜索范圍(可變長(zhǎng)度和固定長(zhǎng)度的編碼)，其中編碼過(guò)程為:

4.2 視頻服務(wù)器實(shí)時(shí)傳輸設(shè)計(jì)

在流媒體服務(wù)器端，通過(guò)數(shù)據(jù)源組件獲取到由視頻采集卡采集到的數(shù)據(jù)流，探測(cè)組件與網(wǎng)絡(luò)發(fā)送端將經(jīng)過(guò)壓縮處理的視頻數(shù)據(jù)發(fā)送到手機(jī)客戶(hù)端，同時(shí)RTCP的通信狀態(tài)反饋給服務(wù)器的控制模塊，服務(wù)器根據(jù)客戶(hù)端傳送的命令啟動(dòng)實(shí)時(shí)源Filter，發(fā)送Filter和創(chuàng)建過(guò)濾器圖表。客戶(hù)端檢索到流媒體數(shù)據(jù)并啟動(dòng)接收Filter流，創(chuàng)建過(guò)濾器圖表并啟動(dòng)手機(jī)端的流媒體播放器。服務(wù)器和客戶(hù)端的RTP/RTCP通信過(guò)程如圖4所示。

圖4 RTP/RTCP通信流程圖

在MPEG-4編碼標(biāo)準(zhǔn)中，包含了RTP數(shù)據(jù)包通信字段所應(yīng)用的使用規(guī)范和分片規(guī)則，RTP內(nèi)容中的時(shí)間戳能夠獨(dú)一無(wú)二地替代VOP的分幀時(shí)間，為了達(dá)到使基本流配置信息在同一個(gè)RTP端口上進(jìn)行通信的目的，本文采用的是合并配置/基本流模式。在RTP信息包放在上層函數(shù)頭的后面或者開(kāi)始位置，把Group_of_videoObject-Plane()和配置信息嵌入其中，特定的RTP包接收特定的VOP，也就是每個(gè)RTP對(duì)應(yīng)著唯一的VOP時(shí)間相關(guān)的數(shù)據(jù)包，將視頻流包放到RTP數(shù)據(jù)包中進(jìn)行發(fā)送，其中RTP包的數(shù)據(jù)值不得超過(guò)路徑的最大傳輸單元MTU值。

數(shù)據(jù)源組件RTP Source Filter屬于Source Filter，它的主要過(guò)程是首先從文件讀出視頻數(shù)據(jù)或者從視頻采集卡獲取實(shí)時(shí)視頻數(shù)據(jù)，再傳送給網(wǎng)絡(luò)發(fā)送與探測(cè)組件，RTP Source Filter的接口定義如下:

IRTPSourceFilter接口代表的是設(shè)定數(shù)據(jù)源類(lèi)型，F(xiàn)ilter數(shù)據(jù)源的傳輸是利用Sample信息得到的，Sample則是實(shí)現(xiàn)和映射了固定數(shù)值大小的COM組件，通信中的服務(wù)器和客戶(hù)端的端口必須使用匹配相同的分配器。根據(jù)客戶(hù)端的反饋信息的要求把Sample設(shè)定為索引數(shù)字，在服務(wù)器端則啟動(dòng)實(shí)時(shí)視頻流作為數(shù)據(jù)源向Sample輸入內(nèi)容和有效數(shù)據(jù)長(zhǎng)度。在網(wǎng)絡(luò)發(fā)送和探測(cè)組件的過(guò)程中，RTP Send Filter與RTP Source Filter連接在一起，然后將RTP Source Filter傳送過(guò)來(lái)的視頻流使用RTP協(xié)議通過(guò)網(wǎng)絡(luò)組件發(fā)送出去，RTP Send Filter接口定義為:

流媒體客戶(hù)端設(shè)計(jì)了流媒體接收組件RTP Rec Filter，通過(guò)接收視頻流文件來(lái)構(gòu)建流媒體播放端，最后完成視頻的成功接收和播放。在客戶(hù)端中的接收模塊使用獨(dú)立的線程接收視頻流數(shù)據(jù)，通過(guò)數(shù)據(jù)緩沖將視頻流以Sample的形式提供給下一級(jí)的Filter。

5 實(shí)驗(yàn)結(jié)果

本文移動(dòng)視頻服務(wù)器在Windows操作系統(tǒng)環(huán)境下進(jìn)行開(kāi)發(fā)，通過(guò)3G網(wǎng)絡(luò)或無(wú)線與Internet連接。應(yīng)用CF無(wú)線網(wǎng)卡，基于IEEE802.11a標(biāo)準(zhǔn)無(wú)線局域網(wǎng)架構(gòu)多點(diǎn)到多點(diǎn)的通信模式，傳輸?shù)臒o(wú)線廣播為2.45 GHz頻段，應(yīng)用DSSS傳輸技術(shù)，最大速率為11 Mbit/s。實(shí)際中的傳輸速率為10～100 kbit/s，視頻的傳輸幀率為0.8～10 f/s，完成了服務(wù)器實(shí)時(shí)視頻的數(shù)據(jù)傳輸測(cè)試。其中視頻數(shù)據(jù)傳輸部分?jǐn)?shù)據(jù)如表1所示，實(shí)時(shí)視頻實(shí)驗(yàn)截圖如圖5所示。實(shí)驗(yàn)證明該服務(wù)器基本上滿(mǎn)足了實(shí)時(shí)視頻傳輸?shù)男枨蟆?/p>

表1 視頻實(shí)時(shí)數(shù)據(jù)傳輸部分?jǐn)?shù)據(jù)

6 結(jié)論

本文應(yīng)用MPEG-4視頻編碼標(biāo)準(zhǔn)和RTP/RTCP協(xié)議設(shè)計(jì)了一個(gè)基于智能手機(jī)的視頻傳輸服務(wù)器，分析了MPEG-4編碼標(biāo)準(zhǔn)和RTP/RTCP流媒體傳輸協(xié)議，實(shí)現(xiàn)了MPEG-4對(duì)視頻流的編碼和解碼，設(shè)計(jì)了基于RTP/RTCP的流媒體傳輸?shù)木幋a和對(duì)實(shí)時(shí)源Filter的處理過(guò)程，在手機(jī)端經(jīng)過(guò)測(cè)試證明服務(wù)器的實(shí)時(shí)性較好，實(shí)現(xiàn)了很好的效果。

圖5 視頻實(shí)驗(yàn)截圖

[1]KIKKUCHI Y，NOMURA T.RFC3016，RTP payload format for MPEG-4 audio/visual[S].2000.

[2]馮琪，裴海龍.視頻采集與實(shí)時(shí)傳輸系統(tǒng)的軟件實(shí)現(xiàn)方法研究[J].計(jì)算機(jī)應(yīng)用研究，2005，32(7):188-190.

[3]張宛方，蘇鴻根.基于RTP/UDP/IP協(xié)議實(shí)時(shí)傳輸MPEG-4流媒體文件[J].計(jì)算機(jī)工程與設(shè)計(jì)，2004，25(8):1409-1410.

[4]WU D，HOU Y T.Adaptive QoS control for MPEG-4 video communication over wireless channels[C]//Proc.2000 IEEE International Symposium on Circuits and Systems.[S.l.]:IEEE Press，2000:48-51.

[5]孫知信，陳亞當(dāng)，任至廣.基于P2P流媒體直播系統(tǒng)的數(shù)據(jù)傳輸策略[J].通信學(xué)報(bào)，2011，32(6):3-5.

[6]袁曉梅.視頻網(wǎng)絡(luò)直播與流媒體的融合[J].電視技術(shù)，2003，27(7):82-84.

[7]張曉，胡維華，徐小良.基于RTCP的移動(dòng)流媒體研究[J].計(jì)算機(jī)仿真，2009，26(5):170-172.

[8]劉洋志，楊明，黃鑫陽(yáng).多服務(wù)組的流媒體安全通信機(jī)制[J].電視技術(shù)，2006，30(3):56-57.