基于３Ｇ無線網絡實時傳輸ＭＰＥＧ－４流媒體的設計與實現

摘要：首先介紹了視頻監控系統所涉及的一些基礎理論（MPEG－4；RTP/RTCP），簡述了嵌入式移動視頻監控系統的實現方案；然后給出了系統的總體設計框架，著重對基于無線傳輸的嵌入式移動視頻監控系統的傳輸部分設計進行了詳細描述。

關鍵詞：MPEG－4； RTP/RTCP； 視頻監控； 無線傳輸

中圖分類號：TP393．04

文獻標志碼：A

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

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

1MPEG－4影像編碼技術

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

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

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

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

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

采用RTP來實現MPEG－4數據流的傳輸具有以下優勢：

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

b)可通過傳輸控制協議RTCP來監視MPEG－4傳輸的性能。

c)通過RTP翻譯器可實現數據流類型的轉換。

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

2RTP/RTCP

RTP（real－time transport protocol）是一種提供端到端傳輸服務的實時傳輸協議，用來支持在單目標廣播和多目標廣播網絡服務中傳輸實時數據，是針對Internet上多媒體數據流的一個傳輸協議，多用于傳輸交互式的音、視頻[4，5]。與傳統的注重高可靠性數據傳輸的傳輸層協議相比，它更加側重于數據傳輸的實時性。RTP包括數據部分和控制部分。對于其數據部分，協議提供的服務包括時間戳標志、丟包探測、數據序列、傳輸控制和加密傳輸等；控制部分則采用按固定周期T發送RTCP包來實現QoS信息的反饋、循環探測和參與會話成員的評估。

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

每個RTP包由包頭和不定長的媒體數據組成。其中，包頭的前12 Byte是固定的。其結構如圖2所示。

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

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

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

3系統設計實現方案

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

本文所實現的基于3G無線網絡的MPEG－4實時流媒體傳輸是嵌入式移動視頻監控系統中網絡傳輸部分的子模塊。本文所關注的網絡傳輸部分由于受到3G無線信道的帶寬限制，采用了圖像壓縮傳輸的方式，監控信號經過音/視頻采集設備的捕獲與3G網絡相連，采用基于Linux的JRTPLIB函數庫來實現RTP的實時傳輸。傳輸部分的系統構架如圖5所示。整個結構由三個主要部分組成：服務器端、客戶端和3G網絡部分。其中服務器端的任務是提供配置接口，完成音/視頻數據采集、事件監控等監控事務，并且與客戶端通信，發送媒體數據和通知消息。從客戶端應用程序來看，服務器端存在兩個模塊，即遠程管理服務器和媒體服務器。前者負責接收控制命令，反饋服務器狀態；后者負責傳輸媒體數據。客戶端可以接收從媒體服務器傳來的媒體數據，但是不可以直接對媒體服務器進行配置。

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

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

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

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

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

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

3．2實時網絡傳輸方案

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

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) //數據分段

{ SetDefaultMark(true); }

else

{ SetDefaultMark(1); }

len -= size;

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

{ break; }

pbuffer += size;

} while(len > 0);

return 0;

}

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

4結束語

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

參考文獻：

[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協議實時傳輸MPEG－4流媒體文件[J]. 計算機工程與設計，2004，25(8):1409－1410.

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

[5]施博學，王志良，劉冀偉. 基于RTP實時遠程圖像傳輸研究與實現[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]卓力，沈蘭蓀，朱青. 視頻流關鍵技術的研究進展[J]. 電子學報， 2002(8)： 1213－1218.

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