H.264解碼糾錯在軟硬件協同系統中的實現
加入技術交流群
并非所有的碼流錯誤都能直接通過句法元素的值判斷出來。一些句法元素的值會影響解碼方法并且被重復使用，所以有些錯誤是可以在解碼過程中發現的，例如：
（4）引用的參考不存在。H.264 實現壓縮的途徑之一就是采用幀內和幀間預測，如采用了4 種16×16幀內預測模式和9 種4×4 幀內預測模式。各種模式對周邊宏塊的要求都有所不同，16×16 塊的水平幀內預測模式所需要的相鄰宏塊信息如圖2 所示。若當前宏塊X 采用水平幀內預測，那么宏塊A 必須可用。如果當前宏塊位于一行的第一個，則說明這種預測方式是錯誤的。而在幀間預測時，要指定參考塊所在參考圖像的編號和位置，如果不存在當前編號所指向的參考幀或參考塊的位置超出了圖像范圍，就說明當前的引用有誤。由于宏塊信息采用變長編碼且沒有特定符號分割，一旦發現錯誤，其后的數據直到下一個NAL 開始都應被丟棄。
圖2 亮度分量Intra 16×16 水平預測模式
?。?）查表無對應值。CAVLC 和CABAC 編碼的數據由于其碼長不定很難分隔出有錯的數據，但是解碼這些數據中包含大量的查表操作，非常有利于及早檢出錯誤。
（6）其它異常情況。如參考隊列中出現空缺，這時候只能判斷前面某一幀或幾幀出現了內存管理錯誤，管理使能句法元素daptive＿ref＿pic＿marking＿mode＿flag被錯誤地置1，或是具體的操作類型錯誤等。這種情況無法在解碼句法元素的時候立即判斷出錯誤（值在正常范圍內且隊列沒有出現異常）， 雖然在人工調試的時候可以根據后面往隊列中插入參考幀的情況檢查出來， 但是對于實時解碼器來說這樣是沒有意義的。這時候不需要放棄當前NAL 中的數據，只要將臨近參考幀的信息復制到參考隊列里即可。
以上是檢錯方法的大致概括。由于噪聲是隨機的，錯誤可能出現在解碼過程的任何一個地方，所以只有通過調試大量碼流才能達到一定的錯誤覆蓋率，使解碼器具有更好的適應能力。
盡管在H.264 的官方參考軟件JM 中給出了較為完善的錯誤修補辦法，但是考慮到盡量減少糾錯部分對原有硬件的影響，我們采用基于幀內16×16 預測的修補辦法， 其原理與解碼幀內16×16 預測的方法相似。如果發現從某一宏塊開始出現錯誤，解碼器將判斷周邊宏塊的存在和預測情況，為當前的宏塊選擇一個最佳的預測模式，通過周邊宏塊邊界上的像素值修補當前宏塊及其后的宏塊直到當前Slice 結束。
本解碼器采用軟硬件協同的SoC 實現方案。在功能劃分上，SPS ／ PPS ／ Slice 頭的解析等分支較多的工作由靈活度較高的軟件部分實現，熵解碼和宏塊預測等需要大量復雜運算的工作由硬件模塊實現。硬件部分被分成前端和后端兩個部分，前端部分包括熵解碼單元，IQ ／ IDCT，后端包括運動補償（MC）和濾波模塊。
CPU 與各個模塊、模塊之間采用wishbONe 總線通信，前后端處理單元之間還有另外一條數據通道，以分擔wishbone 總線的開銷，其結構如圖3 所示。CPU 對輸入的碼流做初步處理，提取出諸如圖像大小、幀類型等信息，然后將處理后的數據送入硬件的前端處理部分，前端處理的輸出被送入運動補償模塊恢復出像素信息并去除塊效應。
錯誤檢測是由軟硬件共同完成的。軟件[5]在解析SPS、PPS、Slice head 的同時判斷解出的各個句法元素值是否合理，如果存在錯誤則通過總線向硬件發送信號HasErr＿soft。例如，在解析PPS 的函數中，解碼無符號指數哥倫布（ue） 得到用來表示當前PPS 所調用SPS ID 的句法元素seq＿parameter＿set＿id， 然后判斷解碼器是否收到過此ID 標號的SPS， 如果無此SPS，則中斷當前PPS 的解碼，返回上一級函數。當前PPS的參數內容由其它PPS 復制得到。即在軟件部分做以下修改：
read＿new＿slice（） ／ ／ 讀入一個NAL 單元
{
…
switch （nalu－＞nal＿unit＿type） ／ ／ 判斷NAL 類型
{
…
case NALU＿TYPE＿PPS:
ProcessPPS（nalu）； ／ ／ PPS 解析
break;
…
}
}
ProcessPPS（NALU＿t }nalu）
{
…
pps－＞seq＿parameter＿set＿id ＝ue＿v（…）；
／ ／ 讀入當前PPS 所對應的SPS＿id
if （pps－＞seq＿parameter＿set＿id invalid）
／ ／ 若讀入的SPS＿id 不可用
… ／ ／ 復制前一個PPS 的內容
HasErr＝1; ／ ／ 錯誤標志位置1
?。?／ （將通過總線發送信號給硬件）
return;
}
評論