并非所有的碼流錯誤都能直接通過句法元素的值判斷出來。一些句法元素的值會影響解碼方法并且被重復(fù)使用，所以有些錯誤是可以在解碼過程中發(fā)現(xiàn)的，例如：

　?。?）引用的參考不存在。H.264 實現(xiàn)壓縮的途徑之一就是采用幀內(nèi)和幀間預(yù)測，如采用了4 種16×16幀內(nèi)預(yù)測模式和9 種4×4 幀內(nèi)預(yù)測模式。各種模式對周邊宏塊的要求都有所不同，16×16 塊的水平幀內(nèi)預(yù)測模式所需要的相鄰宏塊信息如圖2 所示。若當(dāng)前宏塊X 采用水平幀內(nèi)預(yù)測，那么宏塊A 必須可用。如果當(dāng)前宏塊位于一行的第一個，則說明這種預(yù)測方式是錯誤的。而在幀間預(yù)測時，要指定參考塊所在參考圖像的編號和位置，如果不存在當(dāng)前編號所指向的參考幀或參考塊的位置超出了圖像范圍，就說明當(dāng)前的引用有誤。由于宏塊信息采用變長編碼且沒有特定符號分割，一旦發(fā)現(xiàn)錯誤，其后的數(shù)據(jù)直到下一個NAL 開始都應(yīng)被丟棄。

圖2 亮度分量Intra 16×16 水平預(yù)測模式

　　（5）查表無對應(yīng)值。CAVLC 和CABAC 編碼的數(shù)據(jù)由于其碼長不定很難分隔出有錯的數(shù)據(jù)，但是解碼這些數(shù)據(jù)中包含大量的查表操作，非常有利于及早檢出錯誤。

　?。?）其它異常情況。如參考隊列中出現(xiàn)空缺，這時候只能判斷前面某一幀或幾幀出現(xiàn)了內(nèi)存管理錯誤，管理使能句法元素daptive＿ref＿pic＿marking＿mode＿flag被錯誤地置1，或是具體的操作類型錯誤等。這種情況無法在解碼句法元素的時候立即判斷出錯誤（值在正常范圍內(nèi)且隊列沒有出現(xiàn)異常）， 雖然在人工調(diào)試的時候可以根據(jù)后面往隊列中插入?yún)⒖紟那闆r檢查出來， 但是對于實時解碼器來說這樣是沒有意義的。這時候不需要放棄當(dāng)前NAL 中的數(shù)據(jù)，只要將臨近參考幀的信息復(fù)制到參考隊列里即可。

　　以上是檢錯方法的大致概括。由于噪聲是隨機(jī)的，錯誤可能出現(xiàn)在解碼過程的任何一個地方，所以只有通過調(diào)試大量碼流才能達(dá)到一定的錯誤覆蓋率，使解碼器具有更好的適應(yīng)能力。

　　3 軟硬件協(xié)同系統(tǒng)中的糾錯實現(xiàn)

　　盡管在H.264 的官方參考軟件JM 中給出了較為完善的錯誤修補辦法，但是考慮到盡量減少糾錯部分對原有硬件的影響，我們采用基于幀內(nèi)16×16 預(yù)測的修補辦法， 其原理與解碼幀內(nèi)16×16 預(yù)測的方法相似。如果發(fā)現(xiàn)從某一宏塊開始出現(xiàn)錯誤，解碼器將判斷周邊宏塊的存在和預(yù)測情況，為當(dāng)前的宏塊選擇一個最佳的預(yù)測模式，通過周邊宏塊邊界上的像素值修補當(dāng)前宏塊及其后的宏塊直到當(dāng)前Slice 結(jié)束。

　　本解碼器采用軟硬件協(xié)同的SoC 實現(xiàn)方案。在功能劃分上，SPS ／ PPS ／ Slice 頭的解析等分支較多的工作由靈活度較高的軟件部分實現(xiàn)，熵解碼和宏塊預(yù)測等需要大量復(fù)雜運算的工作由硬件模塊實現(xiàn)。硬件部分被分成前端和后端兩個部分，前端部分包括熵解碼單元，IQ ／ IDCT，后端包括運動補償（MC）和濾波模塊。

　　CPU 與各個模塊、模塊之間采用wishbONe 總線通信，前后端處理單元之間還有另外一條數(shù)據(jù)通道，以分擔(dān)wishbone 總線的開銷，其結(jié)構(gòu)如圖3 所示。CPU 對輸入的碼流做初步處理，提取出諸如圖像大小、幀類型等信息，然后將處理后的數(shù)據(jù)送入硬件的前端處理部分，前端處理的輸出被送入運動補償模塊恢復(fù)出像素信息并去除塊效應(yīng)。

　　錯誤檢測是由軟硬件共同完成的。軟件[5]在解析SPS、PPS、Slice head 的同時判斷解出的各個句法元素值是否合理，如果存在錯誤則通過總線向硬件發(fā)送信號HasErr＿soft。例如，在解析PPS 的函數(shù)中，解碼無符號指數(shù)哥倫布（ue） 得到用來表示當(dāng)前PPS 所調(diào)用SPS ID 的句法元素seq＿parameter＿set＿id， 然后判斷解碼器是否收到過此ID 標(biāo)號的SPS， 如果無此SPS，則中斷當(dāng)前PPS 的解碼，返回上一級函數(shù)。當(dāng)前PPS的參數(shù)內(nèi)容由其它PPS 復(fù)制得到。即在軟件部分做以下修改：

　　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（…）；

　　／ ／ 讀入當(dāng)前PPS 所對應(yīng)的SPS＿id

　　if （pps－＞seq＿parameter＿set＿id invalid）

　?。?／ 若讀入的SPS＿id 不可用

　　… ／ ／ 復(fù)制前一個PPS 的內(nèi)容

　　HasErr＝1; ／ ／ 錯誤標(biāo)志位置1

　?。?／ （將通過總線發(fā)送信號給硬件）

　　return;

　　}