基于３Ｇ無線網(wǎng)絡(luò)實時傳輸ＭＰＥＧ－４流媒體的設(shè)計與實現(xiàn)

摘要：首先介紹了視頻監(jiān)控系統(tǒng)所涉及的一些基礎(chǔ)理論（MPEG－4；RTP/RTCP），簡述了嵌入式移動視頻監(jiān)控系統(tǒng)的實現(xiàn)方案；然后給出了系統(tǒng)的總體設(shè)計框架，著重對基于無線傳輸?shù)那度胧揭苿右曨l監(jiān)控系統(tǒng)的傳輸部分設(shè)計進(jìn)行了詳細(xì)描述。

關(guān)鍵詞：MPEG－4； RTP/RTCP； 視頻監(jiān)控； 無線傳輸

中圖分類號：TP393．04

文獻(xiàn)標(biāo)志碼：A

文章編號：1001－3695(2008)06－1856－04

多媒體應(yīng)用技術(shù)的飛速發(fā)展促使人們越來越多地在日常生活、學(xué)習(xí)和工作中采用多媒體手段來解決問題，尤其是視頻監(jiān)控系統(tǒng)，在銀行、商場、城市交通、公共安全等各個領(lǐng)域都有著廣泛的應(yīng)用。多媒體監(jiān)控技術(shù)是一門集計算機(jī)技術(shù)、通信技術(shù)和多媒體技術(shù)于一體的綜合技術(shù)。目前新興的基于嵌入式技術(shù)的MPEG－4多媒體監(jiān)控系統(tǒng)與傳統(tǒng)的多媒體監(jiān)控系統(tǒng)相比具有體積小、成本低、穩(wěn)定性高、實時性好、更適宜存儲和傳輸?shù)葍?yōu)點，具有良好的應(yīng)用與發(fā)展前景。隨著數(shù)據(jù)通信的無線化，人們也越來越期待多媒體通信的無線化，特別是在一些鋪設(shè)固定網(wǎng)絡(luò)有困難但又有多媒體通信需求的地方，實現(xiàn)無線多媒體通信就更加有必要了。且隨著第三代移動通信技術(shù)（3G）在我國的不斷演進(jìn)與實現(xiàn)，移動流媒體技術(shù)的發(fā)展，尤其是適合于無線視頻傳輸?shù)臄?shù)據(jù)傳輸帶寬的發(fā)展為無線視頻監(jiān)控帶來了新的契機(jī)。正是在這樣的需求背景下，確定了本文的研究內(nèi)容——基于3G無線網(wǎng)絡(luò)實時傳輸MPEG－4流媒體的設(shè)計與實現(xiàn)。

1MPEG－4影像編碼技術(shù)

MPEG－4標(biāo)準(zhǔn)是由ISO/IEC組織為了實現(xiàn)將自然音/視頻和合成音/視頻以音/視頻對象的形式編碼而提出的一種編碼標(biāo)準(zhǔn)。MPEG－4標(biāo)準(zhǔn)與前期的MPEG－1和MPEG－2標(biāo)準(zhǔn)實質(zhì)上的不同在于它是基于對象（object－based）編碼而不再是像MPEG－1和MPEG－2那樣簡單地將圖像分為一些矩形幀。它根據(jù)圖像的內(nèi)容，將其中的對象(物體、人物、背景)分離出來分別進(jìn)行幀內(nèi)和幀間的編碼壓縮，并允許在不同的對象之間靈活分配碼率，對重要的對象分配較多的字節(jié)，對次要的對象分配較少的字節(jié)，從而大大提高了壓縮比，使其在靈活的碼率范圍內(nèi)（5 Kbps~10 Mbps）獲得較好的效果。MPEG－4對運動圖像中的內(nèi)容進(jìn)行編碼，其編碼對象稱為 AV對象(audio video object， AVO)，標(biāo)準(zhǔn)的基本內(nèi)容就是高效率的編碼、存儲和傳輸 AVO。它使用場景描述（scene description）來安排音/視頻對象在一個音/視頻場景中的位置，從而使用戶可與場景進(jìn)行交互。MPEG－4擁有一個開放的體系結(jié)構(gòu)，并非一定要實現(xiàn)MPEG－4的完整體系才可以傳輸解碼MPEG－4文件。針對不同的應(yīng)用，可以選擇傳輸解碼MPEG－4體系的子集。MPEG－4主要包含了三部分，即系統(tǒng)、視頻和音頻。視/音頻部分分別定義了視/音頻比特流的語法和語義，它們構(gòu)成了MPEG－4的基本流(elementary streams，ES)。系統(tǒng)層主要解決基本碼流的同步及多路復(fù)合等問題，包含了表現(xiàn)時間戳(PTS)、解碼時間戳（DTS）等重要信息。MPEG－4具有兩種形式的終端系統(tǒng)結(jié)構(gòu)：a)簡化型的MPEG－4終端，即僅執(zhí)行MPEG－4規(guī)范中的一部分的終端系統(tǒng)，如RFC3016中定義的僅執(zhí)行MPEG－4視頻而不執(zhí)行MPEG－4系統(tǒng)功能的終端[1]。在這種簡化的MPEG－4終端模型中，對MPEG－4系統(tǒng)的規(guī)范是不存在的。但是基本碼流這個概念是保留的（MPEG組織是這樣定義基本碼流的：在壓縮層上，從一個源實體到一個目標(biāo)實體的單一媒體數(shù)據(jù)的連續(xù)流）。在基本碼流中可單獨被訪問數(shù)據(jù)的一部分稱為訪問單元AU。一個AU是具有時間屬性的最小數(shù)據(jù)實體，每個AU有邊界信息、隨機(jī)接入點和惟一的時間戳，且每個AU都具有一套媒體獨立的基本性質(zhì)，即合成時間戳（CTS）、取景（framing）和可能的解碼時間戳（DTS）。傳輸不是依靠媒體數(shù)據(jù)的自然屬性而是僅僅依賴于AU的性質(zhì)。MPEG－4的音、視頻文檔分別描述了音、視頻比特流具體是怎樣被分割成AU實體的。b）終端系統(tǒng)結(jié)構(gòu)是完整型的MPEG－4終端，如一個既執(zhí)行MPEG－4系統(tǒng)規(guī)范又執(zhí)行MPEG－4音、視頻規(guī)范（音/視頻為可選）的終端系統(tǒng)。圖1顯示了分層結(jié)構(gòu)的完整型MPEG－4終端。

壓縮層處理單獨的音、視頻媒體流，MPEG－4的壓縮方案在ISO/IEC14496－2[2]和14496－3中有詳細(xì)說明。該壓縮方案在帶寬跨越幾個kbps到數(shù)十Mbps之間獲得了有效的編譯碼效率。經(jīng)過壓縮層壓縮編碼后的音/視頻變成相應(yīng)的ESs、二進(jìn)制格式場景（BIFS）、對象描述符（OD）和初始對象描述符（IOD）。壓縮層是用訪問單元來組織基本碼流的。

主要提供流間同步功能的同步層（SL）定義了一個關(guān)于攜帶媒體數(shù)據(jù)或控制數(shù)據(jù)（ODs和BIFS）的基本碼流的同類型封裝規(guī)范。整數(shù)或者分?jǐn)?shù)AUs被封裝進(jìn)SL包或者SL－PDU中。同步層將基本碼流分割裝入SL包，每個SL包包含一個頭部字段。該頭部字段中的編碼信息通過壓縮層和同步層間的接口——基本碼流接口（ESI）來傳遞。SL包的凈荷中裝載了比特流框架(AU)或是AU片斷。同步層的語法配置信息是通過一個叫做SLConfigDescriptor的結(jié)構(gòu)體來配置的。

MPEG－4中的傳輸層是由ISO/IEC 14496－6定義的傳輸多媒體綜合框架（DMIF）構(gòu)成的。同步層到DMIF的接口叫做DMIF應(yīng)用接口（DAI）。該接口提供內(nèi)容位置的獨立程序用于建立MPEG－4會話和接入傳輸信道。傳輸層由FlexMux和TransMux構(gòu)成。其中，TransMux不在MPEG－4的定義之中，但對該層的接口已被定義，從而使MPEG－4的設(shè)計可以獨立于不同的傳輸系統(tǒng)，可以使用的傳輸協(xié)議包括RTP/UDP/IP、MPEG－2、AAL2/ATM、H.223、DAB等。

MPEG－4分成了十幾個不同的檔次（profile），檔次越高，其所支持的技術(shù)越多，并且向前兼容。MPEG－4的級別（level）主要是對視頻流碼率、圖像大小、緩存大小等的限制。

采用RTP來實現(xiàn)MPEG－4數(shù)據(jù)流的傳輸具有以下優(yōu)勢：

a)能使MPEG－4的FlexMux流和采用其他編碼形式的流在RTP凈荷中自動保持同步，如在移動網(wǎng)絡(luò)中可傳輸和同步MPEG－4視頻及AMR音頻。

b)可通過傳輸控制協(xié)議RTCP來監(jiān)視MPEG－4傳輸?shù)男阅堋?/p>

c)通過RTP翻譯器可實現(xiàn)數(shù)據(jù)流類型的轉(zhuǎn)換。

d)RTP合成器可將MPEG－4的FlexMux流和來自其他終端的實時數(shù)據(jù)流合成為一個整體的數(shù)據(jù)流傳輸。所以本文研究了基于RTP/UDP/IP協(xié)議棧來實現(xiàn)MPEG－4流媒體的傳輸[3]。

2RTP/RTCP

RTP（real－time transport protocol）是一種提供端到端傳輸服務(wù)的實時傳輸協(xié)議，用來支持在單目標(biāo)廣播和多目標(biāo)廣播網(wǎng)絡(luò)服務(wù)中傳輸實時數(shù)據(jù)，是針對Internet上多媒體數(shù)據(jù)流的一個傳輸協(xié)議，多用于傳輸交互式的音、視頻[4，5]。與傳統(tǒng)的注重高可靠性數(shù)據(jù)傳輸?shù)膫鬏攲訁f(xié)議相比，它更加側(cè)重于數(shù)據(jù)傳輸?shù)膶崟r性。RTP包括數(shù)據(jù)部分和控制部分。對于其數(shù)據(jù)部分，協(xié)議提供的服務(wù)包括時間戳標(biāo)志、丟包探測、數(shù)據(jù)序列、傳輸控制和加密傳輸?shù)龋豢刂撇糠謩t采用按固定周期T發(fā)送RTCP包來實現(xiàn)QoS信息的反饋、循環(huán)探測和參與會話成員的評估。

RTP只提供了一種框架性的機(jī)制，對于一個基于RTP的具體應(yīng)用還需要有一個詳細(xì)的規(guī)范和/或制訂連續(xù)媒體的打包方案（即詳細(xì)的RTP包凈荷格式規(guī)范），因此體現(xiàn)出該協(xié)議的簡單性和靈活性。RTP本身并不能為不丟失數(shù)據(jù)包和按順序傳送數(shù)據(jù)包提供可靠的傳輸機(jī)制，也不提供流量控制或擁塞控制，甚至RTP不提供任何機(jī)制來確保把數(shù)據(jù)及時遞送到接收端或者確保其他的服務(wù)質(zhì)量。RTP數(shù)據(jù)包的分割和重組是由其下層的協(xié)議（如UDP）來完成的，同時由其緊密相關(guān)的子協(xié)議RTCP來監(jiān)測QoS和傳送參與傳輸者的信息，從而實現(xiàn)了數(shù)據(jù)與控制信息的分離。它同時支持單播和個數(shù)從2~O(107)的多播擴(kuò)展。典型情況下，基于RTP的應(yīng)用都是采用UDP來作為傳輸層協(xié)議，以便利用UDP的多路技術(shù)和校驗和服務(wù)，但基于傳輸獨立性的考慮，目前RTP支持的下層協(xié)議還包括ST－II、IPv6、ATM－AAL5等；RTP還支持速率自適應(yīng)、源標(biāo)志和數(shù)據(jù)的加密及認(rèn)證等功能[6]。

每個RTP包由包頭和不定長的媒體數(shù)據(jù)組成。其中，包頭的前12 Byte是固定的。其結(jié)構(gòu)如圖2所示。

其中：payload type字段（PT）用于說明音/視頻數(shù)據(jù)類型和編碼的方式，該值在會話期間允許改變；SSRC字段即同步源標(biāo)志，用于幫助接收方利用發(fā)送方生成惟一的數(shù)值來區(qū)分多個不同的數(shù)據(jù)流，其取值必須是一個嚴(yán)格的隨機(jī)數(shù)，值在沖突之后可能會改變；sequence number字段的設(shè)立是為了安全起見，讓發(fā)送端從一個隨機(jī)的初始值開始，每發(fā)送一個RTP數(shù)據(jù)包序列號增加1，收端可以根據(jù)序列號重新排列數(shù)據(jù)包的順序，并對丟失、損壞和重復(fù)的數(shù)據(jù)包進(jìn)行檢測；填充字段P（padding）是為了加密功能而設(shè)定的，如果設(shè)置了填充位，表示在該RTP包的末尾含有非有效負(fù)載數(shù)據(jù)的填充位；標(biāo)志位M（marker）由具體的應(yīng)用框架定義，如RTP的MPEG－4負(fù)載格式中，標(biāo)志位設(shè)為1表示這是VOP的最后一個（或僅有一個）RTP包，用于延時調(diào)整；CC域的值表示CSRC作用標(biāo)志的個數(shù)，是為了混合器而設(shè)立的；CSRC標(biāo)志列表僅出現(xiàn)在有混合器插入時。

RTP的時間戳（timestamp）是實現(xiàn)實時流最重要的信息之一：發(fā)送端依照即時的采樣在數(shù)據(jù)包中隱蔽地設(shè)置了時間標(biāo)簽。接收端收到數(shù)據(jù)包后，就依照時間標(biāo)簽按照正確的速率恢復(fù)成原始的實時數(shù)據(jù)。該值表示每個RTP包中數(shù)據(jù)第一個凈荷字節(jié)的采樣時刻，主要用于同步和計算時延。其初始值是隨機(jī)設(shè)置的，對固定頻率的音頻每次取樣時間戳的值增加1。時鐘頻率與數(shù)據(jù)格式有關(guān)，不能使用系統(tǒng)時鐘（如8 000 Hz采樣的語音信息，每20 ms采樣160次，則時間戳設(shè)置為160，該時間間隔可以理解為兩個相鄰的采樣時刻之間的靜默時間長度。典型的音頻時間間隔為20~100 ms）。不同的音頻凈荷類型采用不同的固定速率，而對于視頻則采用固定的90 kHz頻率，但幾個視頻幀有可能會采用相同的時間戳；同時也可能通過多個RTP包來分割一個視頻幀，這幾個連續(xù)的RTP包具有相同的時間戳。

RTCP數(shù)據(jù)包與RTP數(shù)據(jù)包不同，RTP數(shù)據(jù)包僅僅只有一種形式，可以通過擴(kuò)展頭部等方法實現(xiàn)靈活的數(shù)據(jù)包內(nèi)部結(jié)構(gòu)；但是RTCP數(shù)據(jù)包有幾種類型，如發(fā)送端報告（SR）、接收端報告（RR）、源描述符（SDES）、結(jié)束標(biāo)志（BYE）、應(yīng)用程序說明（APP）等。由RTCP發(fā)送和接收報告（SR和RR）來提供數(shù)據(jù)傳輸服務(wù)質(zhì)量的回饋。多個RTCP包可以不需要任何介于其間的分隔符而連接形成一個RTCP復(fù)合包。一個典型的RTCP復(fù)合包格式如圖3所示。每個單獨的RTCP包可以被相互獨立地進(jìn)行處理。

3系統(tǒng)設(shè)計實現(xiàn)方案

結(jié)合以上對音/視頻壓縮編碼標(biāo)準(zhǔn)以及對網(wǎng)絡(luò)實時傳輸協(xié)議的分析，簡要介紹嵌入式移動視頻監(jiān)控系統(tǒng)的設(shè)計思路。整個系統(tǒng)結(jié)構(gòu)（圖4）由前端設(shè)備、3G無線網(wǎng)絡(luò)傳輸部分和后端接收管理平臺三個主要部分組成。系統(tǒng)的前端由音/視頻采集設(shè)備和嵌入式軟件構(gòu)成，用于音/視頻數(shù)據(jù)捕獲、編碼壓縮、RTP/RTCP封裝和USB控制模塊對系統(tǒng)的配置管理等。音/視頻的捕獲和MPEG－4、CAT編碼由Z228應(yīng)用處理器完成。3G無線網(wǎng)絡(luò)傳輸部分完成網(wǎng)絡(luò)的發(fā)送與數(shù)據(jù)獲取，讓前端采集終端綁定一個固定的3G手機(jī)號碼（被叫），當(dāng)后端監(jiān)控管理平臺使用配備3G手機(jī)號碼（主叫）的一個3G通信模塊撥打終端號碼，且此主叫號碼位于采集終端中預(yù)設(shè)的手機(jī)號碼列表中時，就接通數(shù)據(jù)鏈路，并根據(jù)要求傳回實時監(jiān)控數(shù)據(jù)。3G模塊采用了基于重郵信科的TD－SCDMA基帶芯片C3220設(shè)計的TDM200無線模塊。后端接收管理平臺的作用是音/視頻同步、RTP/RTCP解封裝和由接收端計算機(jī)完成的解碼顯示等。后端接收終端設(shè)備的功能同樣由Z228應(yīng)用處理器完成。接收端計算機(jī)通過后端接收終端設(shè)備向具有特定號碼的前端采集設(shè)備申請建立連接，通過鑒權(quán)后發(fā)出傳送數(shù)據(jù)指令，由前端采集設(shè)備經(jīng)過3G數(shù)據(jù)通道向后端計算機(jī)傳回監(jiān)控信息。

本文所實現(xiàn)的基于3G無線網(wǎng)絡(luò)的MPEG－4實時流媒體傳輸是嵌入式移動視頻監(jiān)控系統(tǒng)中網(wǎng)絡(luò)傳輸部分的子模塊。本文所關(guān)注的網(wǎng)絡(luò)傳輸部分由于受到3G無線信道的帶寬限制，采用了圖像壓縮傳輸?shù)姆绞剑O(jiān)控信號經(jīng)過音/視頻采集設(shè)備的捕獲與3G網(wǎng)絡(luò)相連，采用基于Linux的JRTPLIB函數(shù)庫來實現(xiàn)RTP的實時傳輸。傳輸部分的系統(tǒng)構(gòu)架如圖5所示。整個結(jié)構(gòu)由三個主要部分組成：服務(wù)器端、客戶端和3G網(wǎng)絡(luò)部分。其中服務(wù)器端的任務(wù)是提供配置接口，完成音/視頻數(shù)據(jù)采集、事件監(jiān)控等監(jiān)控事務(wù)，并且與客戶端通信，發(fā)送媒體數(shù)據(jù)和通知消息。從客戶端應(yīng)用程序來看，服務(wù)器端存在兩個模塊，即遠(yuǎn)程管理服務(wù)器和媒體服務(wù)器。前者負(fù)責(zé)接收控制命令，反饋服務(wù)器狀態(tài)；后者負(fù)責(zé)傳輸媒體數(shù)據(jù)?？蛻舳丝梢越邮諒拿襟w服務(wù)器傳來的媒體數(shù)據(jù)，但是不可以直接對媒體服務(wù)器進(jìn)行配置。

客戶端只能通過遠(yuǎn)程管理服務(wù)器對媒體服務(wù)器進(jìn)行配置。從軟件實現(xiàn)方面來看，傳輸功能的實現(xiàn)是由兩個函數(shù)庫來完成的。其中，媒體庫medialib用于完成流媒體的管理及配置等功能，而遠(yuǎn)程管理協(xié)議的支持庫rmlib封裝了遠(yuǎn)程控制協(xié)議服務(wù)器、客戶端的通信相關(guān)事務(wù)。媒體服務(wù)器設(shè)計與傳輸協(xié)議無關(guān)，因此將medialib的API設(shè)計成媒體客戶端與服務(wù)器之間的事務(wù)抽象成為一系列動作，都使用描述符來表示自身，而應(yīng)用層不必關(guān)心描述符的具體內(nèi)容。在遠(yuǎn)程管理協(xié)議的支持庫rmlib的管理下，遠(yuǎn)程管理服務(wù)器在某一端口通過socket來啟動偵聽，由客戶端向服務(wù)端發(fā)起TCP連接，服務(wù)端每收到一個命令包，即會回復(fù)一個反饋命令包，以此來建立連接進(jìn)而傳輸流媒體。從實現(xiàn)方面來看，傳輸部分被分解為圖5中幾個模塊。

3．1視頻壓縮編碼方案

根據(jù)第一部分中對MPEG－4影像編碼技術(shù)的描述與分析，由于當(dāng)前的移動計算技術(shù)的固有限制，如計算能力的限制、帶寬限制和不可靠的傳輸?shù)龋沟肕PEG－4高效的碼率壓縮、交互和分級特性尤其適合于在窄帶移動網(wǎng)上實現(xiàn)多媒體通信。因此，本項目最終采用MPEG－4視頻壓縮標(biāo)準(zhǔn)作為首選。Z228集成了一個支持MPEG－4格式的視頻硬件編/解碼器，支持最高達(dá)VGA (640×480)分辨率的MPEG－4格式視頻編/解碼，最高幀率30 fps，最大比特率達(dá)到8 Mbps，支持MPEG－4的簡單profile（0～3 levels）和高級簡單profile（4～6 levels），支持VBR和CBR兩種速率控制。該硬件MPEG－4編/解碼器能以極低的功耗來壓縮/解壓高質(zhì)量的視頻流。MPEG－4編碼器在系統(tǒng)中使用的框圖如圖6所示。

編碼器在ARM核的控制下從輸入緩存中讀入YUV圖像（一種圖形格式，圖像按照亮度和兩種色度來表示，每四個亮度點Y 配一個色度點U 和一個色度點V）進(jìn)行編碼，再將MPEG－4的碼流輸出到輸出緩存中。某些時候，部分輸出內(nèi)容是由CPU 完成的，如編碼時，輸出碼流的頭之類。CPU 運行指令管理輸入/輸出緩存，并且配置編碼器的寄存器。除了輸入和輸出緩存，編碼器還需要一些額外的緩存來作為緩沖或倒數(shù)據(jù)用。編碼器掛在AMBA 總線上，同時帶有master 和slave 接口。寄存器通過slave接口映射到內(nèi)存空間，輸入/輸出的數(shù)據(jù)通過master接口直接讀寫內(nèi)存。

編碼器的工作原理如圖7所示。

當(dāng)從攝像頭捕獲的圖像進(jìn)入到外部存儲器后，編碼器的軟件部分就會由ARM編程控制來填寫MPEG－4碼流的頭部信息和VOP的頭部信息(1)。然后，編碼器的軟件部分向硬件部分的寄存器中寫入控制信息并驅(qū)動硬件開始工作(2)。硬件開始讀取輸入的當(dāng)前幀圖像(3)和（與其相關(guān)的用于運動估計的）參考幀P－VOP(4)；同時硬件會寫給外部RAM下一個VOP運動估計的相關(guān)圖像信息(5)。最后，硬件把已編好的碼流寫入存儲器，同時寫入的還有由軟件寫好的MPEG－4碼流頭部信息(8)。被分段的MPEG－4數(shù)據(jù)流由三個部分組成，如果啟用了數(shù)據(jù)分段功能，硬件就會將其中的兩個分段寫入單獨的緩存區(qū)(6)，之后再將它們結(jié)合到一個流中(7）（8)。

3．2實時網(wǎng)絡(luò)傳輸方案

除了在網(wǎng)絡(luò)終端采用良好的視、音頻壓縮標(biāo)準(zhǔn)使視頻采集系統(tǒng)的視頻質(zhì)量得到保證外，良好的網(wǎng)絡(luò)通信設(shè)計和通信協(xié)議的選擇對于遠(yuǎn)程視頻數(shù)據(jù)傳輸?shù)膶崟r性以及控制命令的準(zhǔn)確性也是至關(guān)重要的，筆者必須在現(xiàn)有的基于TCP/IP的因特網(wǎng)基礎(chǔ)上輔以相關(guān)的協(xié)議。根據(jù)第2章中對于網(wǎng)絡(luò)傳輸?shù)慕榻B，本文選擇了RTP/RTCP來提供實時流服務(wù)。發(fā)送端將音/視頻流封裝到RTP包內(nèi)通過IP網(wǎng)絡(luò)傳送給接收端；同時接收來自接收端的RTCP包對QoS進(jìn)行反饋控制。接收端主要是完成RTP包的解封裝。筆者采用了可在Linux平臺上進(jìn)行實時傳輸編程的JRTPLIB函數(shù)庫來實現(xiàn)實時的流媒體傳輸。由于RTP并不作為一個獨立的網(wǎng)絡(luò)層實現(xiàn)，它采用應(yīng)用層組幀的理念，作為應(yīng)用程序代碼的一部分[7]，針對一個具體媒體的應(yīng)用需要額外的文檔定義封裝規(guī)則，筆者自己編寫了用RTP封裝分組的程序代碼[8]，然后將RTP分組交給UDP接口。采用了JTHREAD作為線程庫，完成多線程的操作。發(fā)送端部分程序如下：

int JRTPServer :: SendBuffer(const void *data， size_t len)

{char* pbuffer = (char*)data; //存放MPEG－4碼流的緩存

do

{const int maxpayloadsize = RTP_DEFAULTPACKETSIZE－sizeof(RTPHeader) －sizeof(uint32_t)；//RTP_MAXCSRCS

const int size=(len>maxpayloadsize)?maxpayloadsize:len;

if (len <= maxpayloadsize) //數(shù)據(jù)分段

{ SetDefaultMark(true); }

else

{ SetDefaultMark(1); }

len -= size;

if (SendPacket(pbuffer， size) < 0)

{ break; }

pbuffer += size;

} while(len > 0);

return 0;

}

由于無線傳輸視頻終端具有更大的靈活性和便利性，需要在終端內(nèi)集成一個無線傳送模塊?，F(xiàn)在常用的無線模塊有Wavecom、Siemens、Benq等廠家生產(chǎn)的GPRS、CDMA1x的基于2.5G技術(shù)的模塊。但是這些模塊傳送數(shù)據(jù)時由于受到帶寬的限制，不能很好地滿足本系統(tǒng)的需求；而且在我國，由于采用不同的網(wǎng)絡(luò)技術(shù)，3G模塊又有WCDMA、CDMA2000以及TD－SCDMA三種。其中，TD－SCDMA是我國自主知識產(chǎn)權(quán)的代表[9]，所以筆者采用了基于重郵信科的TD－SCDMA基帶芯片C3220設(shè)計的TDM200無線模塊。該模塊支持384 Kbps的數(shù)據(jù)速率，采用AT命令接口，擁有16位API主機(jī)接口，采用1 KB雙口RAM通信，用于與主機(jī)的信令和數(shù)據(jù)通信，兩個UART用于調(diào)試跟蹤，并且TDM200集成了完整的射頻電路和TD－SCDMA的基帶處理器，能很好地滿足系統(tǒng)的需求。Z228通過TDM200的UART2與其采用AT命令方式進(jìn)行通信。經(jīng)過分析，Z228與TDM200的I/O電平均為3.3 V兼容，因此，筆者分配了Z228的UART2口與TDM200的UART2口直接連接進(jìn)行通信。

4結(jié)束語

本文系統(tǒng)地研究了嵌入式監(jiān)控系統(tǒng)的視頻壓縮編碼標(biāo)準(zhǔn)，為了能夠在有限帶寬的無線傳輸環(huán)境下傳輸監(jiān)控數(shù)據(jù)，需要采用圖像質(zhì)量較高，而且碼流較小的壓縮編碼算法，如MPEG－4標(biāo)準(zhǔn)；另外，傳統(tǒng)的TCP不適宜用于傳輸實時流媒體，需要采用RTP/RTCP來傳送監(jiān)控視頻流。因此本文實現(xiàn)了在3G無線網(wǎng)絡(luò)中基于RTP/UDP/IP的MPEG－4實時流媒體傳輸。最后，給出了基于無線傳輸?shù)囊苿右曨l監(jiān)控系統(tǒng)總體設(shè)計方案，并著重分析了它的視頻壓縮編碼部分和實時網(wǎng)絡(luò)傳輸部分的實現(xiàn)方式。從實驗調(diào)試結(jié)果來看，本系統(tǒng)能在無線環(huán)境下較好地完成實時監(jiān)控功能。下一步的工作重點是在視頻編碼方面，如果時間允許、處理器能力能夠達(dá)到的情況下，可采用具有更高壓縮比、效果更好的H.264編碼標(biāo)準(zhǔn)，使用高性能的視頻專用DSP來完成。這樣既可提高系統(tǒng)性能，又能夠達(dá)到視頻編碼的靈活性。

參考文獻(xiàn)：

[1]KIKUCHI Y， TOSHIBA，NOMURA T，et al. RTP payload format for MPEG－4 audio/visual streams[S]. 2000:1－21.

[2]MPEG99/N2688， ISO/IEC JTC1/SC29/WG11， 14496－2: information technology－generic coding of audio－visual objects－part2:visual[S]. 1999.

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

[4]董振亞，張擁軍，彭宇行. 基于RTP的MPEG－4視頻傳輸[J]. 計算機(jī)應(yīng)用研究，2003，20(7)：52－55.

[5]施博學(xué)，王志良，劉冀偉. 基于RTP實時遠(yuǎn)程圖像傳輸研究與實現(xiàn)[J]. 微計算機(jī)信息，2005，21(2):178－179.

[6]TURLETTI T，HUITEMA C. RFC 2032， RTP payload format for H.261 video streams [S]. 1996.

[7]HOLFODER W. Interactive remote recording and play back of multicast video conference[J]. Computer Communication， 1998，21 (15):1285－1294.

[8]SCHULZRINNE H，HOFFMAN D， SPEER M， et al. RTP payload format for MPEG－4 elementary streams[S]. 1998.

[9]卓力，沈蘭蓀，朱青. 視頻流關(guān)鍵技術(shù)的研究進(jìn)展[J]. 電子學(xué)報， 2002(8)： 1213－1218.

注：本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文