H.264解碼糾錯(cuò)在軟硬件協(xié)同系統(tǒng)中的實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

　　read＿new＿slice（） ／ ／ 讀入一個(gè)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 所對(duì)應(yīng)的SPS＿id

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

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

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

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

　　／ ／ （將通過(guò)總線發(fā)送信號(hào)給硬件）

　　return;

　　}