引言
當前在視頻監控,視頻會議,網絡流媒體等方面數字視頻編碼成為最核心,最基本的技術手段,尤其是視頻監控現已成為最為普通的安保設備之一。基于電腦硬盤為存儲體的數字DVR已日漸取代模擬DVR。數字DVR的最關鍵技術就是視頻壓縮技術,而視頻壓縮技術又含有兩大選擇。首先是視頻壓縮采用何種算法標準,當前視頻算法的國際標準有MPEG2、MPEG4、H.264,H.264以其高壓縮效率,在低碼率下優良的圖像質量成為目前視頻監控系統中首選的壓縮方式。
但任何事物都有其兩面性,H.264編碼的高效率,優質圖像是用算法的復雜性來換取的。H.264編碼器的復雜性是MPEG2的4-5倍。第二個選擇是用什么芯片來實現,TI公司的TMS320DM642芯片,是一款專門用作媒體處理的高速DSP,其強大的圖像處理能力為在監控系統中實時實現H.264編碼提供了可能。為了降低成本,還必須充分運用DM642本身的資源,使一顆DM642能處理更多路的視頻,這就是高效率優化的目的,本文首先對整個視頻監控的硬件平臺做了介紹,后結合DM642的結構特點,提出整個編碼軟件的框架的安排,對于占用系統資源最多的運動估計提出基于DSP的優化方法,最后以整數DCT為例,討論了編寫匯編代碼的技巧。
硬件平臺的介紹
整個視頻監控的硬件系統的框架如圖1所示。DM642芯片為了適應數字媒體處理的需求,增加了三個可配置的視頻端口(VP0,VP1,和VP2),這些視頻口外設為常用的編解碼設備提供了無縫接口。因而不需要外加可編程邏輯器件和FIFO就可滿足系統設計的要求。
為了節省成本,提高DSP芯片的利用率,在一塊板卡可以同時處理多路的音視頻,壓縮卡與主機間的數據吞吐量會很大,為了保證數據存儲的實時性,系統采用PCI板卡,其與主機通信數據傳輸速率最高達528MB/s(66MHz,64bit),完全滿足大容量高速實時傳輸系統的需求。
圖1 硬件系統框架
由于每個視頻口可以接收兩路8/10bit的視頻信號,視頻信號經過SAA7144A/D轉換輸出為8位BT.656格式的數字視頻數據。這樣就能利用一顆DM642芯片處理最多6路視頻輸入。每個視頻端口的BT.656視頻采集模式采集8bit或是10bit4:2:2格式的亮度和色度信號,并將它們復用到一個數據流里,視頻數據以Cb,Y,Cr,Y,Cb,Y,Cr的順序傳送,其中Cb,Y,Cr代表同一位置的亮度和色度樣點,緊接著后面的Y代表下一個位置的亮度樣點。數據流經解復用后亮度和色度信息分別存放到各自的Y,Cb,CrFIFO中,再經EDMA搬移到SDRAM中,以備CPU讀取進行壓縮編碼。編碼后的視頻流再經PCI口存入到電腦的硬盤上,從而完成整個視頻監控的流程。
編碼器整體框架的安排
JM代碼是很多可選的H.264標準軟件之一,它關心H.264全部的功能在代碼上得到體現,所有的情況都得考慮,例如幀編碼,場編碼都有,內存的分派沒有考慮到系統的實際情況,適合用來幫助理解H.264標準,不太適合移植到DSP平臺上。為了高效的組織利用DM642有限的片內資源,就得重新組織代碼,包括數據結構,數據存放的位置,程序存放的位置,精簡地來安排程序。
首先要考慮的是L2的配置問題,第二級L2(256kB)是一個統一的程序/數據空間,可以整體作為SRAM映射到存儲空間,也可整體作為第二級cache,或者二者的比例的組合使用。因為一旦二級緩存也不命中的話,那么讀取數據申請將轉由EDMA來完成,CPU至少有13個cycle的延遲。所以我們總是盡量把程序和數據放在片內存儲器內。但是即使全部將L2配置成SRAM也只有256kB大小,以CIF格式圖像為例,待編碼的一幀圖像大小是148.5kB,再加上運動估計的參考圖像就大大超過256kB了。所以在配置L2時,筆者選擇的是SRAM224kB,L2cache32kB。首先考慮要放到SRAM的是表格,全局變量,棧數據和一些調用頻繁的核心程序,如運動搜索,DCT變換,量化……而整個待編碼圖像和參考圖像就只能放在片外存儲空間了。
既然圖像數據被存放到了片外存儲空間中,就要涉及到數據在片內存儲跟片外存儲間的數據搬移,這可交由DM642強大的EDMA引擎來完成,EDMA工作時不占用CPU的周期,把CPU從繁重的搬移數據的工作中解放出來,專致于運算工作。在編碼程序時,為了避免CPU等待EDMA搬完數據后才能工作,可采用乒乓結構的雙緩存區,當EDMA傳送數據到其中一塊存儲區域時,CPU對另一塊存儲區域進行處理。待二者都處理完畢后,乒乓區域交換。
需要通過EDMA搬移的數據有待編碼的宏塊,前后幀對應的參考宏塊,和編碼后的重構宏塊(B幀不需要),這些宏塊都包括亮度塊和色度塊。EDMA在搬大量數據時才能將它的性能發揮到極致,如果每編完一個宏塊就進行一次乒乓緩存交換,那么在頻繁的配置EDMA通道參數上就耗費了過多的CPU周期。有限的片內存儲空間,制約著不能一次搬太多的宏塊,一般一次搬7--9個宏塊為宜。由于EDMA的同步信息是由CPU發出的,我們自然想到QDMA,但QDMA適用于單個的,獨立的快速搬移數據,對于這種周期性的,重復性的搬移并沒有優勢。
為了提高EDMA的效率,可以采用EDMA鏈,最多開辟12個EDMA通道,讓其首尾相連,這樣只需觸發一次CPU,可將待編碼的亮度塊色度塊,參考幀的亮度塊和色度塊……一次搬完,如圖2所示。在配置EDMA通道時,我們注意到頻繁更換的只是EDMA的源地址和目的地址,而其它參量是不變的。由于EDMA控制器是基于RAM結構的,每個通道是通過參數表來配置的,每一個通道的參數都可以在0x01A0000h~0x01A07ffh的2KB的配置表中找到自己固定的位置,所以在更新某一通道的源地址和目的地址時,直接往配置表寫上新地址就行了,而不必調用CSL庫中的相應的cache函數來修改源地址和目的地址。
圖2 EDMA鏈示意圖
圖3 六邊形搜索算法
快速運動算法的優化
包括MPEG2,MPEG4和H.261、H.263、H264在內的標準都是采取基于塊的運動估計模型。當然不同的標準塊的大小也不一樣,在H.264標準中,支持七種塊大小(16x16、16x8、8x16、8x8、8x4、4x8、4x4)。眾所周知:運動估計對減少時間域的冗余起了很大的作用,從而能大大提高編碼效率,但同時它的計算量特別大,占用了大概整個編碼系統的70%~80%的資源。一個好的編碼算法就是要在計算量和編碼效率兩者之間取得一個很好的平衡。
全搜索(FS)能夠保證在全局范圍內搜到一個最佳的位置,但是其計算量是驚人的。對于在嵌入式系統中應用是不現實的。一般在實際應用中都是把幾種算法結合起來,在本系統中采取的是:六邊形搜索法,如圖3所示,先以預測點為中心進行大模式搜索,如果最優點不在六邊形中心,則將六邊形的中心移至改點,重復大模式搜索,直到最優點在六邊形中點,然后在這點切換到小模式搜索,此搜索法相對于經典的三步法,四步法搜索的點更少。
由于是在DSP平臺上,對監控系統實時性要求比較高,提出幾種基于DSP平臺的優化方法:為了提高L1D的cache的命中率,根據cache不命中流水的原理,一次將參考幀全部灌入L1D內,然后在做運動估計時將七個宏塊一齊做,然后再做七個宏塊的運動補償,DCT,量化,反DCT,反量化,編碼,寫碼流。而不是像一般的步驟,對每一個宏塊先做運動估計,然后運動補償,然后DCT,映射到L1D一次,如果每個宏塊單獨做,在做第一個宏塊運動估計時參考幀會由L2映射到L1D,做第二次運動估計時,因為之前程序做過DCT,量化等運算,映射到L1D里的參考幀數據已經被沖走,還得從L2中重新載入。同樣的對于程序段一級緩存L1P來說,DCT、量化、反DCT、反量化、編碼、寫碼流等函數都只需映射一次到L1P,而不必被反復地映射,沖掉,再次映射。
在JVT的提案中有很多運動矢量預測算法,如利用運動矢量在時間域有很強的相關性這一特性,我們能夠得到比較精確的起始搜索位置。但他不太適合DSP平臺,因為這樣我們就要保留整個一幀的運動矢量,以CIF圖像格式為例,需要12kB的空間,保存在資源緊張的片內顯然是不合適的。保存在片外存儲空間,調用的時候,先從片外先映射到L2cache,再從L2映射到L1D,其間流水不命中等待的cycle數,還不如從開始不太精確的初始位置多搜幾個點。
整數DCT的優化詳解
DCT,量化,反DCT,反量化在整個編碼程序中占用了大概20%~25%的時間,所以有必要對他們的優化花一番功夫,本文舉整數DCT為例說明如何對程序進行匯編級的優化。H.264采用的整數DCT,不僅滿足一般DCT的特性,將圖像的能量集中到左上角位置,直流系數和低頻系數中,還有它特有的幾個優點:
-它是整數變換,所有的運算都是整數算法,變換矩陣系數十分簡單,核心變換部分可以僅僅用加法和移位來實現。非常有利于在DSP實現。
-可以保證編碼端的變換和解碼端的反變換完全匹配,沒有誤差。
首先我們對變換矩陣做必要的調整,如表達式(1),(2)所示,這樣做的好處是行變換和列變換的操作完全一樣,簡化了運算。接下來就是用線性匯編或純匯編來實現兩個矩陣的相乘。
?
?
因為DM642CPU有兩個類似的可進行數據處理的通路A和B,每個通路有4個完全相同的運算單元(.L,.S,.M,.D)我們可將矩陣的一四兩行的運算放在A側進行,二三兩行在B側進行運算,這樣可以保證A,B兩側可同時并行計算。由于整數DCT變換是在16比特精度下完成的,矩陣相乘我們自然會想到匯編指令DOTP2,但是不能全部用DOTP2來完成運算,否則一個周期內就只有.M單元在工作,而其他運算單元都閑著。由于整數DCT矩陣系數的特殊性,我們完全可以用加法指令和移位指令來代替乘法指令。表1是一個16x16宏塊進行DCT變換,匯編優化前后的cycle數的對比。
表一 16x16宏塊DCT所需的周期數
在寫匯編指令時我們要盡量做到在同一個周期內,讓位于A,B兩側的8個運算單元能夠同時工作,在做DCT時我們發現M單元不夠用,而有時在其他情況下,M單元根本就沒用上,這時就要想辦法用M去代替其他運算單元。如求殘差時要把8位數擴展成16位數,一般用UNPKLU4和UNPKHU4指令來完成,也可以用DOTPU4乘以0x01010101,同樣也可以完成擴展要求。
表二 H.264編碼器性能測試
實驗結果與總結
由于此編碼器是針對監控系統的應用,在追求編碼速度的時候,對圖像質量做了一定的犧牲。下面是編碼器的一些參數配置:圖像皆為CIF大小,參考幀用了一幀,搜索范圍是[-16,16],相鄰兩個P幀間插入兩個B幀,即IBBPBBP……的編碼方式,P幀和B幀做運動估計時最小塊到8x8塊,即只在16x16、16x8、8x16、8x8幾種模式間做選擇,量化步長設為30.。采用CAVLC編碼方式。
本文針對實時視頻監控的應用要求,結合DM642嵌入式系統的硬件特性,從程序的總體架構,數據的存放位置,數據的搬移進行了分析,給出了切實有效的優化方法。對占用系統資源較多的運動搜索給出了適合在DSP平臺下的算法,對整數DCT進行了在匯編層面的優化,并總結了一下優化技巧。經測試基本達到視頻監控的實時要求,并且有較好的圖像質量和碼率。
評論
查看更多