文章來源： http://www.tichinese.com/Article/Video/200909/2150.html 編輯：小乙哥

1 代碼優(yōu)化的主要方法

通過代碼移植能夠獲得在DSP上初步運行的代碼，但是它由于沒有考慮到DSP自身的硬件特點，不適合DSP強大的并行處理能力，因此執(zhí)行效率低下，不能滿足我們的實時要求，需要對其進行進一步優(yōu)化。

對DSP代碼進行優(yōu)化的手段有以下三個層次，分別是：項目級(Project)優(yōu)化，算法級(algorithm)優(yōu)化，指令級(instruction)優(yōu)化。下面對這三種優(yōu)化手段分別進行介紹。

1)項目級優(yōu)化

項目級優(yōu)化，是對項目的整體優(yōu)化，主要手段有以下幾點：
首先是在對整個項目進行編譯鏈接生成DSP代碼時，合理選擇配置編譯器選項，并針對這些參數(shù)選擇，對程序進行調整和修正。其中進行的工作有：

• 項目編譯時，通過-o3選項來調用最高級別的軟件流水線優(yōu)化，通過-mw選項來調用軟件流水線循環(huán)反饋，從而增大軟件編譯成DSP代碼的并行性。
• 項目編譯時，用-pm，-o3和-mt選項來改善循環(huán)，多重循環(huán)，龐大循環(huán)體循環(huán)的性能。
• 只讀變量聲明成const型，循環(huán)計數(shù)器定義為int型，從而加大DSP代碼的并行性。

其次對程序結構進行調整，對不適合DSP執(zhí)行的語句進行改寫，以提高代碼的并行性。例如，DSP處理器并行性很高，能夠對代碼進行流水線處理，但是原始代碼存在大量條件判斷語句，會對流水線造成中斷，不利于代碼的并行處理，因此，可以采用判斷提前，去除不必要的判斷等方式減少判斷語句對流水線的中斷。

2)算法級優(yōu)化

算法級優(yōu)化，就是利用H.264的自身特點，采用一些快速算法，在不影響編碼質量的前提下，提高編碼器速度，從而在速度和質量上達到一個較好的平衡。

3)指令級優(yōu)化

上述方法無法達到要求時，就要進行指令級優(yōu)化。C64x系列DSP有豐富的具有高度并行性處理能力的指令。下面介紹一些C64x系列DSP媒體處理相關指令。

• ADD4：加法指令，一次執(zhí)行4對8位數(shù)的加法。一個寄存器有32位，可以存放4個8位數(shù)據(jù)。計算中，兩個源寄存器中的四組對應8位數(shù)據(jù) 分別相加，結果存放在目標寄存器中。
• AVGU4：一次執(zhí)行4對8位無符號數(shù)據(jù)求平均運算。計算中，兩個源寄存器中的4組8位無符號型緊縮字求平均，結果以4個8位緊縮字的 形式存放在目標寄存器中。
• DOTPU4：一次執(zhí)行4對8位無符號數(shù)據(jù)點乘運算。計算中，兩個源寄存器中的4組8位無符號型緊縮字對應相乘，乘積相加，所得結果存放 在32位寄存器中
• SUBABS4：一次執(zhí)行4對8位無符號數(shù)據(jù)求差絕對值運算。計算中，兩個源寄存器中的4組8位無符號型緊縮字對應相減，差值求絕對值，所得結果以4個8位緊縮字的形式存放在目標寄存器中。
• LDB/LDH/LDW/LDDW：將8位，16位，32位或64位數(shù)據(jù)讀入目標寄存器中，所讀取的數(shù)據(jù)在內存中是地址align(32位對齊)的數(shù)據(jù)。
• LDNW/LDNDW：將一個32位或64位的非對齊數(shù)據(jù)讀入目標寄存器中。
• STB/STH/STW/STDW：將8位，16位，32位或64位數(shù)據(jù)寫入內存中，所寫入的數(shù)據(jù)在內村中是地址align(32位對齊)的數(shù)據(jù)。
• STNW/STNDW：將一個32位或64位的非對齊數(shù)據(jù)寫入內存中。

除了這些高并行度的指令，TI還提供了豐富的算法庫[37]，如Image/Video Processing Library圖像/視頻處理庫(IMGLib)，Digital signal processor Library數(shù)字信號處理庫(DSPLib)等。這些算法庫中的函數(shù)都是已經充分優(yōu)化過的算法模塊，而且大都提供對應的C、線性匯編和匯編源代碼，并有文檔進行API介紹。所以要充分利用。

2 算法關鍵模塊的優(yōu)化

對模塊的優(yōu)化分三步進行。先認真分析代碼，并進行相應的調整，例如盡量減少有判斷跳轉的代碼，特別是在for循環(huán)中，因為判斷跳轉會打斷軟件流水。可以用查表或者用_cmpgtu4、_cmpeq4等intrinsic來代替比較判斷指令，從而巧妙地替代判斷跳轉語句。同時還可以采用TI的CCS中所提供的#pragma，為編譯器提供盡量多的信息。這些信息包括for循環(huán)的次數(shù)信息、數(shù)據(jù)對齊信息等。如果經過這部分優(yōu)化后還無法滿足系統(tǒng)要求，則對這部分模塊使用線性匯編來實現(xiàn)。

2.1 整數(shù)變換和量化

整數(shù)變換和反變換的運算步驟見下表：

圖1 DCT與IDCT的運算步驟

整數(shù)運算和反變換的次數(shù)極多，比如，在D1格式下，4?4DCT等要做21600次，如果算上其他大小宏塊的這些變換，時間消耗還是很多的，所以仍然有優(yōu)化的必要。下面以整數(shù)變換為例介紹如何用線性匯編對C語言代碼進行優(yōu)化：

1)預測殘差的輸入

DCT和IDCT優(yōu)化的關鍵是在數(shù)據(jù)的讀和寫上。讀寫指令是和存儲器操作相關的，所以要盡量減少其操作的次數(shù)。優(yōu)化時可以用LDNW（無邊界調整字（四字節(jié)）讀取）和STNW（無邊界調整字（四字節(jié)）存儲）來代替單字節(jié)讀取和存儲，然后在寄存器內部再對數(shù)據(jù)進行打包處理，這樣可以大大提高速度。讀入方法如下：

LDNDW *A4, a1:a0 ；第一行數(shù)據(jù)

LDNDW *+A4(8), a3:a2 ；第二行數(shù)據(jù)

LDNDW *+A4(16), b3:b2；第三行數(shù)據(jù)

LDNDW *+A4(24), b1:b0；第四行數(shù)據(jù)

寄存器A4是系統(tǒng)指定用來保存函數(shù)返回值的。8字節(jié)的數(shù)據(jù)的讀入要保存到寄存器對中。

2)行變換的實現(xiàn)

C64x里面有多種加法指令，寄存器內容可作為32位數(shù)據(jù)相加，也可作為兩個16位數(shù)據(jù)相加，也可以作為四個8位數(shù)據(jù)相加。對應于上面的數(shù)據(jù)輸入方法，我們采用16位相加，并使用.S功能單元。實現(xiàn)方法如下：

加法指令

ADD2 a0, b0: r_00 ；a + d

ADD2 a1, b1: r_01 ；

ADD2 a2, b2: r_10 ；b + c

ADD2 a3, b3: r_11 ；

減法指令

SUB2 a2, b2: r _20 ； b - c

SUB2 a3, b3: r_21 ；

SUB2 a0, b0: r_30 ； a - d

SUB2 a1, b1: r_31 ；

另外，因為在C64x指令中沒有對兩個16位數(shù)據(jù)同時左移的指令，同時DM642的乘法指令可 以在一個周期內完成，所以在表1中求B, D時要使用MPY2指令實現(xiàn)向左的移位運算。由于乘法運算后數(shù)據(jù)的位數(shù)要進行擴展，因此MPY2的結果需要放入一個寄存器對，但實際有效數(shù)據(jù)不會超過16 位，因此完成乘法后我們又把數(shù)據(jù)兩兩打包在一個寄存器里，以方便在下面的列變換中進行數(shù)據(jù)的并行處理。實現(xiàn)方法如下：

MPY2 r_30, r _t，r_tl:r_ t0 ；2*(a-d) r_ t=0x00020002

MPY2 r-31, r_t，r_t3:r_t2

PACK2 r_t 1, r_t0, r_t0

PACK2 r_t3, r_t2, r_t2

3)列變換的實現(xiàn)

行變換后數(shù)據(jù)以行優(yōu)先方式存放在4個寄存器對內。所以在進行列變換前要對寄存器內的數(shù)據(jù)進行轉置調整，以方便我們使用上述的數(shù)據(jù)并行處理指令。

第一列

PACK2 .S1 a2, a0, r_ m00

PACK2 .S2 b0, b2, r_ m01

第二列

PACKH2 .Ll a2, a0, r_ m10

PACKH2 .L2 b0, b2, r ml l

第三列

PACK2 .S1 a3，a1，r -m20

PACK2 .S2 b1，b3，r_ m21

第四列

PACKH2 .Ll a3，a1，r -m30

PACKH2 .L2 b1，b3，r_ m31

經過寄存器中數(shù)據(jù)的轉置處理后，我們就可以使用與行變換類似的程序進行列變換的實現(xiàn)。

4)輸出變換結果

列變換的結果即為整數(shù)變換的結果，但是輸出之前必須進行第二次轉置處理，使得輸出數(shù)據(jù)仍然為行優(yōu)先方式存儲。

STNDW r_mOut0l:r mOut00, *A4

STNDW r_mOut1l:r mOut10, *A4(8)

STNDW r_mOut2l:r mOut20, *A4(16)

STNDW r_mOut3l:r mOut30, *A4(24)

5)檢查生成的匯編代碼并對線性匯編代碼進行相應的調整，以提高效率。如，避免使用A16~A31和B16~B31寄存器，因為這兩組寄存器需要被保護，如果被使用，編譯器會花額外的時間對這些寄存器進行保護操作，這會打斷流水，降低效率。

線性匯編代碼中用“.cproc” 和“.endproc”命令限定了需要優(yōu)化器優(yōu)化的代碼段，“.reg”命令允許使用將要存入寄存器的數(shù)值描述名字，也就是為寄存器設定了一個標識符。寄存器A4是系統(tǒng)指定用來保存函數(shù)返回值的。

量化（DCT）和反量化（IDCT）與整數(shù)變換相比多了if判斷，如下所示：

for(i = 0 ; i < 16 ; i ++)

{

if (data[i] > 0)

{

data[i] = (data[i] * quant[mf_index][i] ) >> qbits;

}

else

{

data[i] = -(-(data[i] * quant[mf_index][i]) >> qbits);

}

}

而判斷指令會打斷軟件流水，所以應該避免使用。觀察代碼可知，進行移位操作的都是正數(shù)，所以優(yōu)化時可以對絕對值進行操作，而把符號放在另外的存儲器中，移位計算后再將符號加上去。

比較線性匯編優(yōu)化前后的性能，我們可以發(fā)現(xiàn)效果相當明顯。

圖2 優(yōu)化前后比較

DCT和量化實際上是兩個相關聯(lián)的部分，總是成對出現(xiàn)，我們可以把DCT和量化一起完成，這樣數(shù)據(jù)可以在寄存器中完成運算，節(jié)省了數(shù)據(jù)存儲和讀取時間。

2.2 熵編碼和解碼

2.2.1 查表方法的改進

CAVLC編碼按如下步驟進行：

1．編碼非零系數(shù)的個數(shù)（TotalCoeffs）和TrailingOnes的個數(shù)（Coeff_token）

通過查表進行，表有5個，定義在結構h264_coeff_token[5][17*4]中，選擇碼表的依據(jù)是當前塊上面和左面塊的非零系數(shù)個數(shù)（N0和N1）。由這兩個值計算一個參數(shù)N來查表。這就是所謂的基于上下文自適應（context adaptive）。

2．對每個TrailingOnes的符號進行編碼

對于每個TrailingOnes都要用一個比特來表示它的符號 (0代表正，1代表負)。符號的編碼是逆序進行的，即從最高頻的TrailingOnes開始編碼。

3．對除TrailingOnes之外的非零系數(shù)的level值進行編碼

當前塊中每個余下的非零系數(shù)的level值 (符號和絕對值) 都將按照逆序進行編碼，即從最高頻的系數(shù)開始到DC系數(shù)結束。編碼每個level所用的查找表是依據(jù)先前己編碼系數(shù)的level的絕對值來決定的(上下文自適應)。按原來的做法，此處將查7個表Level_VLC0到Level_VLC6。Level_VLC0適合編碼較小的絕對值；Level_VLC1 適合編碼稍大的絕對值，依此類推。現(xiàn)在采用一種新的查表方式，將非零系數(shù)的幅值（Levels）分成兩部分：前綴（level_prefix）和后綴（leve_suffix）。前綴和后綴的求法和一個變量suffixLength有關，如下公式：

變量suffixLength是基于上下文模式自適應更新的，它的更新與當前的 suffixLength的值以及已經解碼好的非零系數(shù)的值（Level）有關。這樣可通過更新suffixLength的值將各種非零系數(shù)的前綴都控制在一個較小的范圍內，這樣既有利于碼表的構建又有利于提高查表的速度，更新后的算法僅需要一個level_prefix的碼表，碼表如下。

圖3 level_prefix碼表

文章來源： http://www.tichinese.com/Article/Video/200909/2150.html 編輯：小乙哥
level_suffix的編碼只需先按照公式4.1計算出數(shù)值，然后根據(jù)suffixLength的值來確定后綴的長度即可，無需另外建立碼表。

總體來說，更新的查表方法有以下兩個特點：

1) 大的碼表分解成若干小碼表，縮小了搜索范圍。

2) 利用小碼表中碼字的規(guī)律快速確定參數(shù)在碼表中的位置。

4．對TotalZero進行編碼

TotalZero代表DC系數(shù)與最高頻的非零系數(shù)之間零系數(shù)的個數(shù)。之所以要單獨對TotalZero進行編碼是因為在系數(shù)序列的低頻部分往往會含有多個非零系數(shù)，而如果編碼TotalZero就可以避免去編碼系數(shù)序列低頻部分的一些零游程。

5．對每個run-before進行編碼

run-before表示當前非零系數(shù)與下一個非零系數(shù)之間零系數(shù)的個數(shù)。 run-before需要按照逆序編碼。從高頻系數(shù)開始，每個非零系數(shù)的run-before都要進行編碼，但有兩個例外：

(1)如果沒有余下的零系數(shù)需要編碼，則沒必要再編碼任何zero-run( 即之前編碼的run-before之和等于TotalZero)。

(2)沒有必要對最后一個 (最低頻) 非零系數(shù)的run-zero進行編碼。

至此，完成了CAVLC編碼。

在熵解碼時，TotalCoeff、TrailingOnes、TotalZeros和 Run_before的值都是直接查表求的，過程比較簡單，此處不進行介紹。在解碼除拖尾系數(shù)之外的非零系數(shù)幅值時先從當前解碼位置起逐個比特進行檢測，直到找到第一個比特“1”為止。此比特之前，經檢測為“0”的比特的個數(shù)就是前綴值。通過前綴值找到對應的碼表，并決定后綴的長度。最后讀入后綴值。利用上面公式反向計算就可得到非零系數(shù)的幅值。

2.2.2 函數(shù)的優(yōu)化

CAVLC編碼前要將4×4的殘差塊轉換成zig-zag排列，如圖4所示。

圖4 4×4亮度的zig-zag掃描

Zig-zag掃描后，按步驟是先對掃描后數(shù)據(jù)的進行逆序遍歷，求出非零系數(shù)和拖尾系數(shù)的數(shù)目之后再開始編碼寫碼流。

函數(shù)調用時，要將PC和一些寄存器壓棧保存，函數(shù)返回時，則要將這些寄存器出棧返回，增加了一些不必要的操作，因此要對這部分函數(shù)進行修改。

C代碼中，zig-zag掃描是由一組賦值語句完成的，將順序排列的16個數(shù)的數(shù)組轉換成 zig-zag順序排列的數(shù)組。編譯器將這段代碼轉化為匯編代碼是將16個數(shù)讀入寄存器后再進行排列后寫回的，這時要讀寫一次寄存器，之后遍歷數(shù)組求非零系數(shù)和拖尾系數(shù)時又要讀寫一次寄存器。我們可以將zig-zag掃描的函數(shù)改寫成線性匯編代碼，將數(shù)據(jù)讀入到寄存器后就進行遍歷，另外用寄存器作計數(shù)器，記下非零系數(shù)和拖尾系數(shù)的數(shù)目，然后將zig-zag排列的數(shù)據(jù)和求得的系數(shù)一次寫回，這樣就省掉了一次寄存器的讀寫，多次累計起來省掉的時間開銷還是相當可觀的。

CAVLC編碼和解碼中多次調用寫碼流函數(shù)和讀碼流函數(shù)，由于調用次數(shù)很多，可以將這些函數(shù)表示成內聯(lián)函數(shù)，優(yōu)化效果也相當明顯。比如，完成100次C代碼的寫碼流函數(shù)BitstreamPutBits花費4075個cycle，而表示成內聯(lián)函數(shù)后僅需要2600個cycle。

2.3 幀內預測

2.3.1 幀內4×4 預測模式判別方法的改進

計算4×4 預測模式的過程就是對4×4 塊的9 種預測模式進行計算的過程，分別求出各個模式的SAD值，選取SAD 值最小的預測模式為最優(yōu)預測模式，因此編碼器的計算復雜度很高。

參考相關文獻可以對判別方法進行如下改進：由于在H.264 中，殘差矩陣量化前后的變換系數(shù)都是整數(shù)，只要4×4 變換前的殘差矩陣滿足如下條件，其殘差系數(shù)量化后的值就是全零。

公式1

其中 為殘差矩陣對應位置的值，，QE是量化參數(shù)矩陣，對于給定的為中的最小值。根據(jù)相鄰塊的預測模式預測當前4×4 塊的最可能預測模式為predmode。根據(jù)此預測模式取其殘差矩陣，對其殘差做，并判斷是否。如果不等式成立，則當前最可能的預測模式predmode 就是最優(yōu)預測模式bestmode，結束此4×4 塊的預測模式判斷。否則，對此4×4 塊的其他預測模式進行判斷。對其中的一種預測模式計算它的預測殘差矩陣，判斷不等式是否成立，如果成立，則此預測模式為此前4×4 塊的最優(yōu)預測模式bestmode，結束此4×4 塊的預測模式判斷。否則對此4×4 塊的其他預測模式進行同樣處理，直至9 種預測模式都進行了判斷，獲得一個最優(yōu)的預測模式。

同時，在改進算法中，對于那些判斷殘差進行變換量化后結果為全零的4×4 塊進行了特別處理。由于這些4×4 塊的殘差經過變換量化后結果為全零，對它們的殘差再進行變換、量化、反量化和反變換就失去了意義，因此可以對這些處理過程進行簡化。具體操作為：對這些 4×4塊的殘差矩陣直接全賦值為零，并對Z 掃描的結果也同樣賦值為零，從而省去了變換、量化、反變換和反量化，并且對編碼結果和圖像的重構結果都不會有影響，能夠進一步減少計算復雜度。

2.3.2 亮度預測的并行實現(xiàn)和線性匯編優(yōu)化

4×4子塊亮度預測除在匯編指令級采用超長指令字VLIW并行執(zhí)行8條指令外，主要采用數(shù)據(jù)并行、線性匯編優(yōu)化和使用軟件流水進行優(yōu)化處理。

4×4子塊亮度預測時的數(shù)據(jù)都是0～255，即unsigned char，在DSP中占一個字節(jié)：采用寄存器組A、B并行處理4×4子塊前兩行與后兩行兩塊數(shù)據(jù)，采用寄存器高低位并行處理兩行數(shù)據(jù)，如圖5所示。這樣并行處理得到近似為4的加速比。

圖5 4×4亮度塊預測數(shù)據(jù)并行

觀察4×4子塊亮度預測的九種預測模式，我們會發(fā)現(xiàn)后6種預測模式16個像素點的預測有很強的相關性，使用軟件流水線可以得到較好的效果。以模式3 (左下對角線模式)為例，16個像素點分別由公式2得出。

公式2

線性匯編的編寫過程如下：

1．用四字節(jié)的讀寫指令代替單字節(jié)的讀寫指令

利用LDNW指令用兩次將ABCD和EFGH讀入到兩個寄存器中，利用STNW指令分四次將數(shù)據(jù)存儲。

2．重新組裝寄存器里的數(shù)據(jù)

ABCD和EFGH并不是分開的，總是四個一組進行計算。公式4.2中1、2式的操作數(shù)是 ABCD，3、4式是CDEF，5、6、7式是EFGH。因而我們不需要將ABCD與EFGH完全拆開存儲，只需要將ABCD中的高半字和EFGH中的低半字拆出來存到一個獨立的寄存器中。這條指令是PACKHL2。

3．分析運算式規(guī)律，選擇最簡單的運算指令

所有的運算中，都存在一個計算式X+2Y+Z，同時有三個unsigned char型數(shù)據(jù)參加運算，下面一條C6400系列的匯編指令正好可以用于此處。

DOTPU4 (.M) src1, src2, dst

這條指令求src1和src2中的兩個無符號數(shù)的4個字節(jié)對應的積，再相加，和數(shù)送入dst 中。在這里我們可以用src2 = 0x0121分別與ABCD、CDEF和EFGH做DOTPU4運算，可直接得出B+2C+D、D+2E+F和F+2G+H，用src2 = 0x1210分別與ABCD、CDEF和EFGH做DOTPU4運算，可直接得出A+2B+C、C+2D+E和E+2F+G。運算后的結果加2后右移2位即可。

對4×4子塊亮度預測的后6種預測模式進行優(yōu)化后，性能有明顯提高，如下表所示（-o3，no –mu允許軟件流水的條件下）。

font>

圖6 優(yōu)化性能比較

16×16宏塊亮度預測基本上與4×4塊亮度預測一致，但對早期終止策略進行了優(yōu)化處理。

16×16宏塊亮度預測按照模式0(垂直預測)→模式1(水平預測) →模式2 (直流預測) →模式3 (平面預測) 編碼順序進行，并在每種預測模式中采用早期終止策略后，流程為[34]：16×16宏塊第i列數(shù)據(jù)預測、第i列數(shù)據(jù)求殘差、計算第i列數(shù)據(jù)SAD值、判別是否進行下一模式預測 (當SAD值大于16個4×4子塊的最優(yōu)模式下的SAD之和min_cost時)。這樣最多會增加了15次判斷，有測試中表明83%的宏塊在計算了12列數(shù)據(jù)SAD值才滿足判決條件，15%的宏塊在計算了16列數(shù)據(jù)SAD值才滿足判決條件，2%的宏塊在計算了8列數(shù)據(jù)SAD值就滿足判決條件。故實際編程中僅在計算了12列數(shù)據(jù)SAD值后增加判決，僅增加一次判決，16×16宏塊編碼效率提高20.04%。流程見圖7所示。

圖7 16×16宏塊亮度預測流程

2.4 運動估計

在視頻編碼中，運動估計和補償起著最為關鍵的作用，通常占一個壓縮編碼方案總計算量的60%～ 80%。塊匹配法是目前最為廣泛應用的運動估計方法。在H. 264 中，運動補償部分與之前的標準有很大的不同。它支持更大范圍的運動補償塊，以達到高精度匹配，充分消除時域冗余度，最大程度減小預測誤差。而這是以極高的運算量和復雜度為代價的，僅以整像素搜索為例，H. 264 共允許多種大小的補償塊 (最小可到4×4)，對一個16×16 的宏塊采用某一種分塊方式進行全搜索，搜索范圍為16，則求匹配差值的計算次數(shù)為：

(2 × 16 + 1) × (2 × 16 + 1) × 16 × 16= 2. 79×105

這樣大的計算量顯然會給實時視頻處理帶來巨大困難，所以要尋找快速的搜索算法和判決策略。

H. 264 標準規(guī)定對16×16 的宏塊可以采用16×16、16×8、8×16、8×8 的分塊方式，而對8×8 的分塊又可進一步分成8×8、8×4、4×8、4×4 的小塊。每個獨立的分塊分別進行運動搜索，這樣的處理固然可以達到最好的匹配效果，但要求巨大的運算量。16×8 和8×16 分塊方式的運算量各自與16×16 分塊方式的運算量大致相當，而8×8 分塊方式由于其每一個小塊都要獨立作4 種方式的搜索，其總的運算量大致相當于16×16 的4倍。而通過對H.264標準測試序列測試的結果來看，對Foreman 這類運動劇烈的序列，8×8 分塊方式為最優(yōu)模式的宏塊數(shù)只占總宏塊數(shù)的不到10% ，對Akiyo這類平緩的序列，8×8 方式的宏塊百分比更是在2%，因此在優(yōu)化中可以放棄8×8這種分塊模式。

運動估計的實現(xiàn)采用分步計算加提前終止的方法。其步驟如下：

1．搜索的上下文信息都存放在一個結構體H264_search_context_t 中，context里存儲有推薦的運動矢量（通常有5個：標準預測值、上、右上三個塊運動向量和0向量），首先嘗試context->vec[0] 標準向量，計算RD_cost（這里算得sad），若RD_cost < th0＝256，則設置最優(yōu)vec_best為vec[0]，并返回sad值。

2．然后嘗試運動向量的其他預測值，找到最小的SAD，若該SAD小于剛才找到的sad，則設置context->vec_best = context->vec[best]，如果該SAD < th0，則返回SAD。

3．若上面都沒有找到小于閾值的SAD，則調用small_diamond_search，進行小菱形搜索，實際就是搜索上下左右四個點，直到當前點為5個點中SAD的最小點。如下圖所示。

圖8 小菱形搜索

H．264解碼器中CAVLC碼表查找算法的分析與優(yōu)化

0 引言
??? 近年來，隨著信息技術飛速發(fā)展和互聯(lián)網(wǎng)的日益普及，尤其是以視頻為信息主要來源的多媒體領域越來越受到人們的關注。H．264是ITU-T的視頻編碼專家組(VCEG)和ISO／IEC的活動圖像編碼專家組(MPEG)的聯(lián)合視頻組(Joint Video Tearn，JVT)開發(fā)的一個新的數(shù)字視頻編碼標準，它既是ITU-T的H．264，又是ISO／IEC的MPEG-4的一部分。H．264和以前的標準一樣，也是DPCM加變換編碼的混合編碼模式。H．264標準可分為三檔：基本檔次(其簡單版本，應用面廣)；主要檔次(采用了多項提高圖像質量和增加壓縮比的技術措施，可用于SDTV、HDTV和DVD等)；擴展檔次(可用于各種網(wǎng)絡的視頻流傳輸)。
??? H．264／AVC的編解碼框架的基本結構與早期的編碼標準(H．263、MPEG4等)相似，都是由運動估計、變換、量化、熵編碼、環(huán)路去塊效應濾波器等功能單元組成的。H．264視頻編碼框架的主要變化包括：引入了環(huán)內去塊效應濾波器，去塊效應處理后的宏塊被保存在內存中用于對后續(xù)宏塊的預側；采用了多參考幀運動估計，需要在內存中保留多個參考視頻幀；引入了幀內預測機制，可以通過同一幀內的宏塊進行預測；采用了新的整型變換方式，取代了以前的離散余弦變換(DCT)；H．264與以前視頻標準在運動估計的模式上也有了較大的變化，H．264支持7種模式的可變塊運動估計。此外，在熵編碼中還引入了上下文自適應的變長編碼(CAVLC)和二進制算術編碼(CABAC)。
??? 在熵編碼方面，H．264使用了CABAC和CAVLC兩種不同的編碼方式。CABAC熵編碼是一種基于區(qū)間劃分的算術編碼方式。這種編碼方式的效率很高，接近信息熵值，但算法相對復雜，編解碼速度較慢。CAVLC是一種可變長編碼，它根據(jù)已編碼語法元素的情況動態(tài)調整編碼中使用的碼表，在編碼過程中有些語法元素是組合編碼的，當對這些元素進行查找時就會耗費很長的時間。因此對CAVLC的優(yōu)化顯得格外重要。

1 原碼表查找算法
??? 原碼表的存儲結構為二維表結構。存儲的內容為碼字，二維坐標分別代表解碼后的兩個語法元素。對于二維表結構。若通過坐標查找內容是很容易的；而通過內容查找坐標，就需要對整個表進行遍歷。JM中的碼表查找算法就是通過遍歷整個碼表實現(xiàn)的，步驟如下：
??? (1)取碼表的中的一個碼字；
??? (2)根據(jù)碼字長度從碼流中取出相應長度的bit；
??? (3)比較此碼字和bit串，若相同則查找成功，否則若碼表中還有碼字，回步驟(1)，否則查找失敗。

2 算法的優(yōu)化分析
2．1 基于前綴零分組子表搜索算法
??? 基于上下文自適應的變長編碼的解碼算法需要不斷的讀取碼流，判斷，直到在碼表中找到該碼字，如此反復，直至解碼整個塊。由此可見該過程的時間空間復雜度都是相當高的。由于變長碼為霍夫曼前綴碼，所以可以根據(jù)碼表的特性，按照碼字長度將原來的一個碼表，按照碼字長度對原碼表進行分割，以Coeff_token碼表為例，原碼表如表1所示，表中NC=-1。

??? 在參考模型中，搜索碼表算法過程如下：
??? (1)從最短碼長開始，讀出該長度二進制數(shù)據(jù)流對應的碼字；
??? (2)遍歷碼表，如找到該碼字進行步驟(4)，否則進入(3)；
??? (3)碼字長度加1，重定位指針位置，重復步驟(2)；
??? (4)讀取該碼字對應值，更新指針位置。
??? 從上面過程中不難發(fā)現(xiàn)，碼字長度的不確定性使得在讀取字節(jié)流時只能一次次的試探，導致了效率的下降。如果可以將變長碼的讀取采取固定的策略，一次讀取固定的長度，之后再做判斷，再讀取一定長度，這樣將判斷的次數(shù)也固定，從理論上可以降低不斷搜索和重定位指針帶來的時間和空間復雜性。利用可以利用碼表中碼字前綴零數(shù)目的不同，將表1拆分為兩個子表，如表2，表3所示NC為-1。

??? 改進后的碼表搜索算法如下：
??? (1)讀取最大碼字長度的二進制流；
??? (2)根據(jù)不同的前綴零位數(shù)、右移位、判零以確定碼字所在子表；
??? (3)直接根據(jù)碼值讀取對應值，更新指針位置。
??? 新的搜索過程不但避免了不確定性，而且無需遍歷碼表，這樣可以在一定程度上提高變長解碼的效率。

??? 按照改進的算法步驟，解碼時，首先從字節(jié)流中讀取8位碼字，由于前綴零個數(shù)分為大于3和小于3的兩種情形，所以右移5位，若為零，則查找表2，否則查找表 1，根據(jù)碼值直接解碼出±1個數(shù)，非零系數(shù)數(shù)目。此外在設計代碼時，還可利用二叉搜索樹的特性，設計搜索過程，提高解碼效率.

2．2 二叉樹一子表混合法
??? 拆分成子表后建立的數(shù)組中存在冗余現(xiàn)象。如當0≤N<2且Pre-Zeros<6時，一共有13個碼字。為了保留原先的查表方式以TC和 Tls為矩陣下標的特點，必須要用4×7矩陣，多余位置零。由于實際搜索的對象是矩陣，怎么確定Pre-Zeros值，以保證在分塊數(shù)一定的情況下，使用的矩陣較小，成為提高搜索效率的關鍵。從表中可以看到，對不同的N值對應的列，子表之間的Pre-zeros的分界點選取了不同的閾值。按照表2中的分塊方法，矩陣的平均大小為4×6．5。相比JM中使用一個4×17矩陣，搜索效率理論上可以提高(17-6．5)／6．5=1．615倍(假設每張子表的使用概率相同)。以0≤N<2的一張VLC表為例，共分成4張子表。從查找一個碼字的比較次數(shù)來看。

??? 可知，子表法查找比較次數(shù)的理論最小值為此時要求n=s2。如果在第一個步驟(確定子表)中改為采用二分法，則這種情況下就可以對以上碼表中前綴連零再細化，將相同連零個數(shù)的碼字放在一起，增加子表數(shù)而減少子表中的碼字結點數(shù)，可以進一步提高查找效率。
??? 從以上分析可見，二叉樹的查找效率是最高的。因此可以將二叉樹應用到子表法中，對每一張子表分別建樹。對于二叉樹來說，查找時間與樹的深度有關。觀察子表中的碼字，發(fā)現(xiàn)它們都有不同長度的連零作為前綴，如果直接建樹將導致樹的不平衡并增加了樹的深度。為了解決這個問題，可以考慮在同一張子表中為每個碼字去除相同個數(shù)的連零前綴，然后建立二叉樹。在解碼時，先忽略這些連零個數(shù)，再進行樹的查找。在最理想情況下，這種查找方法的一次查找的平均比較次數(shù)為：

???
??? 對第一張VLC表采用二叉樹一子表法的最大比較次數(shù)：

???
??? 幾種算法的對比與復雜度分析如表4所示。

??? 空間復雜度也是需要考慮的問題。JM參考實現(xiàn)中為Tls和TC的聯(lián)合碼表建立了2個3×4×17的三維數(shù)組共需要408 B的存儲空間。二叉樹法經過統(tǒng)計，一棵樹共有124個結點，其中葉結點62個，其余62個結點為根結點或枝結點。建3棵二叉樹所需要的空間為 (62×4+62×2)×3=1 116 B。子表法將碼表分成12張子表，每張子表用2個二維數(shù)組表示，而數(shù)組的平均大小為4×6．5，則共要4×6．5×12×2=624 B。

3 結 語
??? H．264是現(xiàn)在視頻編解碼領域研究的熱點也是未來發(fā)展的方向，它將代替MPEG2成為主流的信源壓縮標準。H．264應用領域非常廣泛。將H．264的編解碼速度盡可能的提高，可以使其在更多的領域中應用，如數(shù)字電視，消費電子類產品，網(wǎng)絡通信，可視電話等現(xiàn)在熱門領域。在此專門對于CAVLC碼表查找給出了改進方案，通過這三種改進方案，避免了對整個碼表的查找，對碼表的查找在效率上有了很大提高。具有明顯的實用意義.

總結

以上是生活随笔為你收集整理的H.264算法的优化策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。