基于TMS320DM642和H.264的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)設(shè)計
掃描二維碼
隨時隨地手機看文章
摘要:文中給出了一種基于TMS320DM642和H.264的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的設(shè)計方案,并對其主要硬件TMS320DM642和H.264編碼器進行了詳細描述,論述了編碼器優(yōu)化的基礎(chǔ)上,同時給出了H.264編碼碼流的網(wǎng)絡(luò)傳輸方法。實驗結(jié)果證明,利用這個方案所設(shè)計的硬件平臺和軟件,可以實現(xiàn)H.264編碼碼流的網(wǎng)絡(luò)實時傳輸。
關(guān)鍵字:TMS320DM642;實時傳輸控制協(xié)議;RFC3984;H.264
0 引言
隨著英特網(wǎng)的普及,人們可以從網(wǎng)絡(luò)上得到的信息越來越多。以前,人們只能得到文字和一些簡單的圖形信息,能夠得到的視頻信息是很少的。造成這種現(xiàn)象的主要原因是視頻信息的數(shù)據(jù)量是非常巨大的,如果想傳輸它,就必須有很大的網(wǎng)絡(luò)帶寬,而如此大的網(wǎng)絡(luò)帶寬在現(xiàn)實中是需要耗費巨大的成本才能完成的。視頻的編碼標準就是在這個前提下被提出來的。
視頻編碼技術(shù)到現(xiàn)在為止已發(fā)展了很多年了,各種研究機構(gòu)和標準化組織也已經(jīng)提出了很多解決辦法,但到現(xiàn)在為止視頻編碼的標準主要分為兩大類:一類是國際標準化組織和國際電工委員會第一聯(lián)合技術(shù)組制定的MPEG系列標準;另一類是ITU針對多媒體通信制定的H.26x系列視頻編碼標準。H.264只是視頻編碼標準,它對音頻方面沒有任何的規(guī)定,但是它的壓縮效率高、圖像質(zhì)量好并且傳輸碼率很低,所以它非常適合于視頻的網(wǎng)絡(luò)傳輸。
在本文中,首先描述的是設(shè)計的硬件系統(tǒng),它是H.264算法和網(wǎng)絡(luò)協(xié)議對應的C代碼運行的平臺。核心器件是TMS320 DM642,它是TI公司專門針對多媒體傳輸或網(wǎng)絡(luò)視頻的監(jiān)控設(shè)計并生產(chǎn)的一款DSP芯片。在此硬件平臺下對于EDMA和網(wǎng)絡(luò)接口的高效使用是極其重要的;其次描述的是H.264編碼器的優(yōu)化。由于H.264算法是極其復雜的,所以要實現(xiàn)視頻編碼的實時性也就成為一件難事。因此,就必須對代碼進行優(yōu)化,以達到視頻序列能夠在網(wǎng)絡(luò)中實時傳輸?shù)哪康?;最后描述的是H.264編碼碼流的網(wǎng)絡(luò)傳輸。在此部分主要介紹H.264編碼器中的NAL層和RTP傳輸層的對接,將NAL層的數(shù)據(jù)按照RFC3984協(xié)議的規(guī)定對數(shù)據(jù)進行打包。
1 硬件平臺
視頻監(jiān)控系統(tǒng)的硬件是H.264算法和網(wǎng)絡(luò)傳輸協(xié)議運行的基本硬件平臺,圖1所示為本系統(tǒng)設(shè)計的硬件系統(tǒng)框圖。
設(shè)計中用到的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)絡(luò)通信等設(shè)備及接口,特別適用于網(wǎng)絡(luò)視頻監(jiān)控、數(shù)字廣播以及基于數(shù)字視頻/圖像處理的消費類電子產(chǎn)品等高速DSP應用領(lǐng)域。本系統(tǒng)中用到的外圍接口主要有:視頻接口、存儲器接口、網(wǎng)絡(luò)接口和串口。
圖像A/D轉(zhuǎn)換芯片用的是SAA7115,它負責將模擬視頻信號轉(zhuǎn)換成為數(shù)字視頻信號。NORFLASH用的是spansion公司的Am29LV033C,它的作用是負責永久性的存儲完成H.264編碼算法和網(wǎng)絡(luò)傳輸協(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。[!--empirenews.page--]
硬件系統(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)絡(luò)傳輸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)化。線性匯編代碼是對影響速度的關(guān)鍵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ù)聲明進行排序、識別文件變量的特征。
[!--empirenews.page--]
3 H.264編碼碼流的網(wǎng)絡(luò)傳輸設(shè)計
3.1 H.264編碼器NAL層和VCL層的分離
在H.264的編碼中,網(wǎng)絡(luò)抽象層和視頻編碼層是分開的。H.264編碼器NAL和VCL的分層結(jié)構(gòu)如圖3。視頻編碼層負責視頻序列的壓縮編碼,網(wǎng)絡(luò)抽象層負責使H.264的編碼碼流能夠適應各種網(wǎng)路。這種分層結(jié)構(gòu)可以使設(shè)計出來的系統(tǒng)即擁有高效率的編碼特性又擁有良好的網(wǎng)絡(luò)適應性。
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ù)刂?,必須選擇一個新的SSRC標志符。
4 結(jié)束語
本文首先給出了用于運行H.264算法和網(wǎng)絡(luò)協(xié)議的硬件平臺,然后介紹了H.264的優(yōu)化方法,最后在研究了RTP協(xié)議RFC3984的基礎(chǔ)上介紹了H.264編碼碼流的網(wǎng)絡(luò)傳輸方法。總之,本文主要就是完成H.264編碼碼流的實時網(wǎng)絡(luò)傳輸。由于時間和精力有限,只是用到了RTP協(xié)議,為了提高可靠性。還可加入RTCP協(xié)議,使其能夠得到更好的服務質(zhì)量。另外,若在此基礎(chǔ)上再去研究速率控制和差錯控制方法,并應用于本系統(tǒng),可以進一步提高視頻顯示質(zhì)量。