展鵬飛,魏曉君,張 剛
(太原理工大學信息工程學院,山西太原030024)
AVS(Audio and Video coding Standard)[1]音視頻編解碼標準具有我國自主知識產權,編碼性能與H.264相當,效率高、復雜度低,更易于嵌入式實現。用DSP實現的AVS視頻編解碼器具有良好的可移植性,開發周期短,能夠很好地滿足豐富AVS產業鏈、推廣AVS標準的要求。
OMAP(Open Multimedia Applications Platform)[2]是TI針對手持設備開發的高性能處理器,具有高性能、低功耗的特點。它擁有一個TMS320C64X+系列的定點DSP處理器,最高工作頻率為430 MHz,有A、B兩交叉數據通道,每個數據通道各有M、S、D和L四個功能單元,采用超長指令集(VLIW)[3],在一個時鐘周期內最多可以并行執行8條32位指令。熵解碼大約占了AVS視頻解碼的20% ~25%的運算量,本文從傳統的AVS熵解碼入手,提出了一種新型的碼表結構和一種分組查詢的查詢方法,最后用DSP指令對熵解碼進行了匯編實現和優化,在不影響解碼圖像質量的前提下,提升了解碼速度。
熵解碼是熵編碼的逆過程,處于整個解碼器的第一級模塊。AVS熵解碼采用變長碼解碼技術從壓縮后的碼流中解析信息,包括語法元素和殘差數據的解碼[4]。
AVS解碼器接收到碼流后,首先解析出相應的碼字值,然后根據碼字值和59的大小情況,分情況經過碼表映射找到其對應的量化系數游程數組和量化系數值數組(run,level),為解碼器的逆掃描、反量化等模塊提供輸入數據,大體流程如圖1所示。從圖中可以看出,整個熵解碼過程主要包含碼字的解析、碼表查詢、碼表切換3個部分[5]。本論文主要針對碼表查詢這部分內容進行研究和優化。
AVS標準定義了19個變長碼表:VLC0_Intra~VLC6_Intra這7個碼表用于解碼幀內亮度塊的游程和非零量化系數;VLC0_Inter~VLC6Inter這7個碼表用于解碼幀間亮度塊的游程和非零量化系數;VLC0_Chroma~VLC4_Chroma這5個碼表用于解碼色度塊的游程和非零量化系數[6]。當轉換系數trans_coef<59時,如果當前碼表中包含有此轉換系數,直接查表獲得run和level值,否則以(trans_coef-1)為索引在當前碼表中查表獲得run和level值。當轉換系數trans_coef≥59時,作為逃逸事件處理,逃逸系數escape_diff值由碼流信息計算得到,run值由(trans_coef-59)/2計算得出,level值獲得則分為兩種情況:

圖1 熵解碼流程
1)首先由當前碼表號查詢出Maxrun值,若Maxrun≤(trans_coef-59)/2則以(trans_coef-59)/2為索引在當前碼表中查表獲得level值,否則RefAbslevel賦值為1。
2)Maxrun>(trans_coef-59)/2:若trans_coef為偶數,level值由(escape_diff+RefAbslevel)直接計算得出;若為奇數,level值由(escape_diff+RefAbslevel)取反得到。
經過對熵解碼流程的分析研究后發現,在整個熵解碼的過程中,存在大量的判斷和跳轉指令,不利于軟件流水、代碼的并行處理,嚴重地影響代碼的運行速度,不能體現DSP處理器的優勢。另外僅存儲19個碼表所需要的數據就將近3 000 byte,在PC機上實現時,PC資源豐富,可以把這些數據預先存儲到棧中,沒有資源短缺的問題。但是OMAP3530開發平臺的硬件資源遠比不上PC機豐富,存儲數據的SRAM只有48 kbyte,除存儲參考幀信息和解碼輸出數據外,剩余空間很小,不能存放這么多的數據,若存放到DDR中又會大大降低解碼速度。因此要想在DSP上實現AVS視頻解碼器并且要達到實時解碼的要求,必須對碼表的結構和查詢方式進行改進。
由一維哥倫布碼數據索引二維數組run和level值時,轉換系數在小于59的情況下,奇數和偶數的run值、RefAbslevel值都是相同的,不同的只是level值。AVS標準中規定轉換系數為奇數時和為偶數時的level值互為相反數。為了減少內存空間數據的存儲,本論文對19個碼表存儲的數據進行了調整,根據具體碼表中數據的特點,只存儲偶數或奇數各階指數哥倫布碼字值和對應的run和level值。設定合適的閾值,由哥倫布碼字值、當前碼表和閾值的關系共同決定碼字值是加1、減1后查詢碼表還是直接查詢碼表,來獲得對應的run和level值。由于偶數碼字或奇數碼字加1或減1對應的run值和RefAbslevel值相同,所以本設計只改動每個碼表中碼字值及其對應的level值的存儲,run值和RefAbslevel值的存儲不變。
對程序調整和碼表改造后,雖然達到了碼表數據壓縮的目的,但是依然無法解決這部分代碼的復雜度難題。這部分代碼存在大量循環,最麻煩的是循環體內嵌套循環體;還存在大量的判斷條件和跳轉操作,這對于編譯器實現高效率的軟件流水十分困難[7]。經過改進后的碼表雖然已經節省了大量內存分配空間,但是碼表中數據量還是很大。并且長期占用了內存空間,每次都需要在當前碼表中遍歷查詢,對于整個解碼器系統來說,遠遠達不到實時的要求。針對碼表查詢遍歷耗時和碼表數據長期占用內存空間這一問題,提出對當前要解碼的碼字進行擴展打包處理的解決方案。利用大量的判斷、跳轉等待間隙,將當前碼表數據臨時送入寄存器,查詢過后立即釋放的方式實現匯編優化,盡量減少內存的訪問和修改。理想的情況下一次可查詢4個位置,最壞情況下一次查詢1個位置,利用不同的數據通道和不同的功能單元盡量同時獲得run和level值。
以VLC3_Intra為例,對改進后的碼表進行分組,具體分組優化情況如圖2。

圖2 改進后VLC3_Intra碼表查詢分組(截圖)
1)通過分析,知此碼表先獲得level值,再根據level值獲得run值可大幅度地使查表次數降低,提高查表效率。利用下圖中的分組方式,將VLC3_Intra碼字值和level值分別分為10組和5組。圖2中對碼字值標示了8組,level值標示了3 組,另2 組碼字值為5,3,1,9 和7,13,19,29。其對應的2組level值分別為-3,-2,-1,4和-1,2,3,4。
2)改進后的碼表僅存儲奇數的碼字值,由奇數查詢出對應的run和level值,閾值設定為8。
3)從碼流中解析出碼字后,先判斷當前的碼字值是否為奇數,如果為奇數,則直接查表可得相應的(run,level)值;若當前碼字值為偶數,則跟閾值做比較,若小于閾值,則偶數加1得到奇數;若大于閾值,則偶數減1得到奇數,然后通過奇數來查詢碼字值對應的run和level值。圖3和圖4分別是碼字值在小于59的情況下,VLC3_Intra改造前和改造后碼表查詢的流程。

圖3 改造前碼表VLC3_Intra查詢流程

圖4 改造后碼表VLC3_Intra查詢流程
4)當所讀入轉換系數小于59時,首先用PACK2和PACKL4將碼字值打包為32位,然后通過CMPEQ4指令在碼表中一次查詢4個碼字,當取得某一個比較值為非零值后,將此非零值用XPND4指令進行擴展,最后通過DOTPSU4指令快速定位當前轉換系數值對應level,通過條件判斷得出run。最惡劣情況下需要查詢碼表10次,相比原遍歷查詢方式,與最壞情況下查詢58次相比減少了近6倍。由此可見對19個碼表均采取擇優分組的方式進行查表,可節省大量的查表次數和查表時間,并減少大量的條件判斷。
結合使用OMAP3530仿真測試和使用集成開發仿真環境CCS3.3對所寫代碼進行驗證,本實驗對4個碼流進行了測試,其中football.avs是網上下載的測試序列football.yuv 編碼編出的碼流,Ceslab1.avs~ Ceslab3.avs是從實驗室的環境下采集圖像,再由編碼器編出的碼流。從表1可以看出,用匯編語言實現的熵解碼模塊算法,消耗的解碼時間明顯減少。匯編優化后熵解碼所消耗的解碼時間是未優化的36%左右,幀率提高了1.63倍,達到了25幀以上,滿足了實時解碼的要求,優化效果明顯。

表1 改造碼表結構和優化查詢前后效果對比
本文通過分析AVS熵解碼算法,對熵解碼的碼表結構進行了重新改造,提出了一種新的適合DSP處理器的碼表存儲方式;對碼表查詢提出了一種新的分組查詢方式,有效減少了判斷和跳轉情況,并且用DSP匯編實現。在不影響解碼質量的前提下,節省了碼表存儲空間,并且提高了解碼速率,滿足了AVS視頻解碼器在OMAP3530上實時解碼的要求。
[1]GB/T 20090.2—2006,信息技術 先進音視頻編碼 第2部分:視頻[S].2006.
[2]展鵬飛,張杰飛,張剛.在OMAP3530平臺實現AVS解碼器[J].電視技術,2014,38(1):58-60.
[3]魏曉君,張剛.AVS解碼器環路濾波的優化及實現[J].電視技術,2013,37(5):23-25.
[4]江靜.AVS熵編碼技術研究及其在DSP上的實現[D].武漢:華中科技大學,2008.
[5]陳光法,姚立敏,虞露.AVS熵解碼與DSP實現[J].電視技術,2004,28(10):45-46.
[6] KIM W J,CHO K,CHUNG K S.Multi-threaded syntax element partitioning for parallel entropy decoding[J].IEEE Trans.Consumer Electronics,2011,57(2):897-905.
[7] LO CC,TSAIST,SHIEH M D.Reconfigurable architecture for entropy decoding and inverse transform in H.264[J].IEEE Trans.Consum.E-lectron.,2010,56(3):1670-1676.