楊明極，許雪松，李天池

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

責任編輯:任健男

1 移動視頻服務(wù)器簡介

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

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

2 MPEG-4編碼標準及RTP/RTCP協(xié)議

2.1 MPEG-4編碼標準

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

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

2.2 RTP/RTCP協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

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

圖4 RTP/RTCP通信流程圖

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

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

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

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

5 實驗結(jié)果

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

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

6 結(jié)論

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

圖5 視頻實驗截圖

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

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

[3]張宛方，蘇鴻根.基于RTP/UDP/IP協(xié)議實時傳輸MPEG-4流媒體文件[J].計算機工程與設(shè)計，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]孫知信，陳亞當，任至廣.基于P2P流媒體直播系統(tǒng)的數(shù)據(jù)傳輸策略[J].通信學報，2011，32(6):3-5.

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

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

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