0 引言
    隨著英特網(wǎng)的普及，人們可以從網(wǎng)絡上得到的信息越來越多。以前，人們只能得到文字和一些簡單的圖形信息，能夠得到的視頻信息是很少的。造成這種現(xiàn)象的主要原因是視頻信息的數(shù)據(jù)量是非常巨大的，如果想傳輸它，就必須有很大的網(wǎng)絡帶寬，而如此大的網(wǎng)絡帶寬在現(xiàn)實中是需要耗費巨大的成本才能完成的。視頻的編碼標準就是在這個前提下被提出來的。
    視頻編碼技術到現(xiàn)在為止已發(fā)展了很多年了，各種研究機構和標準化組織也已經(jīng)提出了很多解決辦法，但到現(xiàn)在為止視頻編碼的標準主要分為兩大類：一類是國際標準化組織和國際電工委員會第一聯(lián)合技術組制定的MPEG系列標準；另一類是ITU針對多媒體通信制定的H．26x系列視頻編碼標準。H．264只是視頻編碼標準，它對音頻方面沒有任何的規(guī)定，但是它的壓縮效率高、圖像質(zhì)量好并且傳輸碼率很低，所以它非常適合于視頻的網(wǎng)絡傳輸。
    在本文中，首先描述的是設計的硬件系統(tǒng)，它是H．264算法和網(wǎng)絡協(xié)議對應的C代碼運行的平臺。核心器件是TMS320 DM642，它是TI公司專門針對多媒體傳輸或網(wǎng)絡視頻的監(jiān)控設計并生產(chǎn)的一款DSP芯片。在此硬件平臺下對于EDMA和網(wǎng)絡接口的高效使用是極其重要的；其次描述的是H．264編碼器的優(yōu)化。由于H.264算法是極其復雜的，所以要實現(xiàn)視頻編碼的實時性也就成為一件難事。因此，就必須對代碼進行優(yōu)化，以達到視頻序列能夠在網(wǎng)絡中實時傳輸?shù)哪康?；最后描述的是H．264編碼碼流的網(wǎng)絡傳輸。在此部分主要介紹H．264編碼器中的NAL層和RTP傳輸層的對接，將NAL層的數(shù)據(jù)按照RFC3984協(xié)議的規(guī)定對數(shù)據(jù)進行打包。

1 硬件平臺
    視頻監(jiān)控系統(tǒng)的硬件是H．264算法和網(wǎng)絡傳輸協(xié)議運行的基本硬件平臺，圖1所示為本系統(tǒng)設計的硬件系統(tǒng)框圖。

    設計中用到的RTP協(xié)議是主要針對于H．264編碼碼流進行處理的RFC3984協(xié)議。至于UDP和IP，由于，TI提供的各種類型的DSP套件是支持Socket套接字的，所以，在得到RTP層的打包數(shù)據(jù)后，就可以直接利用套接字對RTP層以后的數(shù)據(jù)流進行處理。
    系統(tǒng)中的TMS320DM642是TI公司C6000系列DSP，它的處理核心是C64x型的高性能數(shù)字信號處理器，具有極強的處理性能，這里用的DSP的核心頻率是600Mhz。它在使用時具有高度的靈活性和可編程性，而且外圍集成了非常完整的音頻、視頻和網(wǎng)絡通信等設備及接口，特別適用于網(wǎng)絡視頻監(jiān)控、數(shù)字廣播以及基于數(shù)字視頻／圖像處理的消費類電子產(chǎn)品等高速DSP應用領域。本系統(tǒng)中用到的外圍接口主要有：視頻接口、存儲器接口、網(wǎng)絡接口和串口。
    圖像A／D轉(zhuǎn)換芯片用的是SAA7115，它負責將模擬視頻信號轉(zhuǎn)換成為數(shù)字視頻信號。NORFLASH用的是spansion公司的Am29LV033C，它的作用是負責永久性的存儲完成H．264編碼算法和網(wǎng)絡傳輸協(xié)議的C代碼。在硬件系統(tǒng)剛剛上電啟動時，NOR FALSH中引導程序先被加載到DSP內(nèi)，然后，引導程序被執(zhí)行，引導程序會將應用程序加載到SDRAM中，最后，應用程序會在SDRAM中被執(zhí)行。SDRAM用的是三星的HY57V28162 0E，它的作用主要有兩個：一是存儲要執(zhí)行的應用程序，二是臨時存儲要被處理的圖像數(shù)據(jù)。串口在這里主要是輔助調(diào)試用的。EMAC接口是非常重要的，它是傳輸已經(jīng)處理的H．264編碼碼流的，這里用的是intel公司研發(fā)的LXT971A。
    硬件系統(tǒng)的工作過程如下：首先是模擬COMS攝像頭采集PAL制式的模擬視頻信號。然后圖像A／D轉(zhuǎn)換芯片SAA7115HL會將模擬視頻信號轉(zhuǎn)換成數(shù)字視頻信號并傳輸給TMS320DM642。TMS320DM642中的EDMA控制器會先將從A／D轉(zhuǎn)換器得到的視頻圖像存儲到SDRAM中，等到TMS320DM6 42處理器已經(jīng)準備好處理圖像的時候，再從SDRAM中將圖像取出來進行H．264格式的編碼壓縮。編碼完成之后，會得到H．264的編碼碼流，這個時候，再利用RTP／UDP／IP的協(xié)議棧將H．264的編碼碼流進行逐層打包并通過EMAC接口發(fā)送到因特網(wǎng)上。

2 H．264編碼器的優(yōu)化
    H．264的編碼器是非常復雜的，所以，當我們用C代碼實現(xiàn)其功能的時候，往往會面臨實時性的問題，即處理器無法在1s內(nèi)完成所要求的數(shù)據(jù)處理量。為了使視頻遠端顯示連續(xù)，必需使處理器在1s內(nèi)能夠壓縮編碼并通過網(wǎng)絡傳輸20幀以上的圖像。但是，在寫出第一版代碼時，會發(fā)現(xiàn)處理器根本就無法達到要求，在1s鐘之內(nèi)，它只能處理5-6幀的圖像，因此就必須對編碼器進行優(yōu)化，以求能夠達到實時性。
    一般來說，如果在DSP中實現(xiàn)H．264的編碼器優(yōu)化，那么優(yōu)化過程主要分為四個階段，分別是算法優(yōu)化、C代碼優(yōu)化、線性匯編的優(yōu)化、CCS編譯器下的選項優(yōu)化，它們被順序的完成。在DSP中實現(xiàn)H．264編碼器的優(yōu)化過程見圖2。

    H．264的編碼算法主要有：幀內(nèi)預測編碼、幀間預測編碼、DCT變換和量化、熵編碼，其中最消耗時間的是幀間預測編碼，它用的時間要占到整套算法運行時間80％左右，因此，幀間預測編碼算法的優(yōu)化也就成為H．264編碼器算法優(yōu)化的重點。
    實現(xiàn)編碼器C代碼的優(yōu)化，主要是注意在寫C代碼的時候要寫出高效簡潔的代碼，使在能夠保持算法基本功能的前提下，占用的處理器運算資源最少。如果C代碼級優(yōu)化完了之后，還不能滿足實時性，就必須用到線性匯編的優(yōu)化。線性匯編代碼是對影響速度的關鍵C代碼進行重寫。線性匯編代碼與C6000的匯編代碼類似，不同的是線性匯編代碼并不用像匯編代碼那樣要給出所有的信息，它可以對這些信息進行一些選擇，也可以由匯編優(yōu)化器確定，如指令使用的寄存器，指令使用的功能單元等，匯編優(yōu)化器會根據(jù)代碼的情況確定這些信息，并產(chǎn)生匯編文件。
    在優(yōu)化過程中，一般都會借助于編譯器自帶的優(yōu)化功能進行優(yōu)化。CCS中有優(yōu)化選項，來幫助我們對代碼進行進一步的優(yōu)化。優(yōu)化選項共有四個：o0、o1、o2、o3。o0級別的優(yōu)化內(nèi)容有：簡化控制流圖、分配變量到寄存器、進行循環(huán)旋轉(zhuǎn)、刪除未使用的代碼、簡化表達式和代碼；o1級別的優(yōu)化除了包括o0的內(nèi)容外還有：執(zhí)行局部復制／常量傳遞、刪除未使用的賦值語句、刪除局部共有表達式：o2級別的優(yōu)化除了包括o1的內(nèi)容外還有：進行軟件流水、進行循環(huán)優(yōu)化、刪除全局共有子表達式、刪除全局未使用的賦值語句、把循環(huán)中對數(shù)組的引用轉(zhuǎn)變?yōu)檫f增的指針形式、進行循環(huán)展開；o3級別的優(yōu)化除了包括o2的內(nèi)容外還有：刪除未使用的所有函數(shù)、內(nèi)聯(lián)小的函數(shù)、重新對函數(shù)聲明進行排序、識別文件變量的特征。

3 H．264編碼碼流的網(wǎng)絡傳輸設計
3．1 H．264編碼器NAL層和VCL層的分離
    在H．264的編碼中，網(wǎng)絡抽象層和視頻編碼層是分開的。H．264編碼器NAL和VCL的分層結(jié)構如圖3。視頻編碼層負責視頻序列的壓縮編碼，網(wǎng)絡抽象層負責使H．264的編碼碼流能夠適應各種網(wǎng)路。這種分層結(jié)構可以使設計出來的系統(tǒng)即擁有高效率的編碼特性又擁有良好的網(wǎng)絡適應性。

3．2 RFC3984協(xié)議的包頭格式及使用
    圖4為RTP固定頭字段格式，具體描述如下：

    版本V：2 bits此處的值為2．
    填充標識P：1 bit
    如果在分組的末尾包含填充字節(jié)，那么此處的值為1，注意，填充并不是有效載荷的內(nèi)容。
    貢獻源(CSRC)數(shù)目CC：4 bits
    標識位M：1 bit
    標識位可以用來表示特定層面的某些重要事件。
    載荷類型PT：7bits
    不同的音視頻編碼標準對應不同的音視頻編碼標準，有些已經(jīng)被完全規(guī)定好了，例如G．723音頻的RTP載荷類型定義為4，H．263定義為34。對于H．264的RTP載荷媒體類型，目前還沒有規(guī)定，可以根據(jù)需要自行定義。表1描述了媒體類型各種載荷類型。

    序號：16 bits
    每發(fā)送一個RTP數(shù)據(jù)分組，序號加1。接收者可以用它來檢測分組丟失和恢復分組順序。
    時間戳：32 bits
    時間戳反映了RTP數(shù)據(jù)分組中第一個字節(jié)的采樣時間。采樣時間必須來源于一個單調(diào)線性增長的時鐘。
    同步源SSRC：32 bits
    同步源應隨機選擇，但要確保同一個RTP會話中的唯一性。如果一個源改變了源傳輸?shù)刂罚仨氝x擇一個新的SSRC標志符。

4 結(jié)束語
    本文首先給出了用于運行H．264算法和網(wǎng)絡協(xié)議的硬件平臺，然后介紹了H．264的優(yōu)化方法，最后在研究了RTP協(xié)議RFC3984的基礎上介紹了H．264編碼碼流的網(wǎng)絡傳輸方法?？傊?，本文主要就是完成H．264編碼碼流的實時網(wǎng)絡傳輸。由于時間和精力有限，只是用到了RTP協(xié)議，為了提高可靠性。還可加入RTCP協(xié)議，使其能夠得到更好的服務質(zhì)量。另外，若在此基礎上再去研究速率控制和差錯控制方法，并應用于本系統(tǒng)，可以進一步提高視頻顯示質(zhì)量。