1 引言

　　H.264" title="H.264">H.264 視頻壓縮標準具有很高的壓縮效率和很好的網絡支持， 非常適應于無線多媒體和基于Internet 的應用。在信息傳輸的過程中，不可避免的就是噪聲。H.264 本身具有很好的抗噪聲技術，如SPS，PPS 和圖像數據的分開打包， 一幀中可有多個Slice，靈活宏塊順序（FMO）等。但是也有很多情況錯誤無法被完全修復。H.264 具有很高的壓縮率（7～50 倍），這就意味著圖像中的冗余已經被大大消除，要從其余的碼流中恢復圖像有很大困難。此外，H.264 壓縮標準采用變長編碼的CAVLC 和CABAC，一旦在這些地方出錯， 解碼器" title="解碼器">解碼器將無法判斷下一個變長碼開始的位置，導致錯誤的擴散。

　　在硬件方面，解碼過程中各部分的實現都有其固定的結構，如果不及時檢出錯誤，會導致如內存溢出、查表錯誤、狀態機進入死循環等。解碼出的圖像會錯位或者變形， 更嚴重的時候整個解碼器會停止運行。

　　所以在解碼器中加入糾錯功能，及早地發現碼流噪聲并將解碼器恢復到正常的狀態是非常有意義而且非常必要的。

　　本項目的解碼器是基于SoC" title="SoC">SoC 的ASIC 解決方案，它具有高速、低功耗、低成本的特點。添加糾錯功能可以提高解碼器的適用性和穩定性，另一方面，應該盡量減少糾錯模塊對原有芯片的面積和速度的影響。

　　2 碼流結構和錯誤檢出

　　H.264 標準壓縮的碼流具有嚴格的格式。公共信息被提取出來作為SPS（序列參數集）， PPS（圖像參數集）單獨打包，與像素信息分離。SPS 和PPS 是碼流中極為重要的信息，將它們單獨打包可以在傳輸環境較差的情況下多次傳送，這在一定程度上增強了碼流傳輸的抗干擾能力。每個包被稱作一個NAL 單元，根據NAL 類型，各個數據包中的數據按照協議中規定的句法元素順序緊密排列。這為糾錯提供了兩點便利：（1）各個NAL 中的錯誤不會蔓延，即如果當前NAL 中檢測出了錯誤而且又無法確定錯誤終止的地方，那么可以將當前包丟棄，直到下一個NAL 開始；（2）很多句法元素都有其固定的范圍。檢測解碼出的元素值是否超出范圍限制是一個非常有用的辦法，也能盡早發現錯誤，避免解碼器進入異常狀態。

　　H.264 視頻碼流包括五個層次的信息： 序列層，圖像層，片層，宏塊層，子宏塊層，分別與NAL 類型的SPS，PPS，Slice（包括片頭，宏塊，子宏塊信息）相對應。

　　宏塊是編解碼處理的基本單位，也是進行錯誤修補的基本單位。H.264 視頻碼流結構如圖1 所示。

　　圖1 H.264 碼流結構

　　在上面的幾個層次中，每一層都具有其特定的句法元素結構，以及相應句法的處理辦法，整個錯誤檢測功能就是基于此實現的。目前可以檢測到的錯誤基于以下幾類：

　?。?）保留位錯誤。這是最容易檢測出的錯誤。在H.264 協議中規定了一些保留位， 如NAL 起始的forbidden＿zero＿bit，SPS 中的reserved＿zero＿4bits 等。解碼器順序讀入碼流時要確定這些保留位的值是正確的，如果有誤，就應該丟棄當前的包或者標記錯誤，做進一步的處理。

　?。?）句法元素值不在指定范圍。大多數的句法元素，尤其是在SPS 和PPS，都有一個指定的范圍。如用于計算最大幀數的log2＿max＿frame＿num＿minus4 必須在0～12 之間，如果讀入的值超出這個范圍，即可以判斷當前讀入的碼流有錯誤。

　　（3）相關句法元素矛盾。有一些句法元素讀入了一個錯誤的值，但仍然在正確的范圍內，單單通過當前語句是無法檢測出的。這時候就要利用句法元素之間的相關性，判斷讀出的值是否合理。例如PPS 中要指定當前圖像所引用的序列參數信息， 即PPS－＞seq＿parAMEter＿set＿id。如果當前引用的SPS 的ID 在所有收到的SPS 中不存在， 即可判斷SPS 或者當前PPS 有一方出了問題； 對于slice＿type 的I，B，P 各種類型，mb＿type 的查表方法也不同， 如果在I slice 中出現了幀間預測的宏塊類型，也可以判斷出錯。

　　以上方法都是可以通過句法元素本身的值判斷出來的，可以在讀入碼流的同時處理，即在處理PPS、SPS 的相應語句后加入判斷，不會對原有解碼器造成太大的影響。

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

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

　　圖2 亮度分量Intra 16×16 水平預測模式

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

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

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

　　1 引言

　　H.264 視頻壓縮標準具有很高的壓縮效率和很好的網絡支持， 非常適應于無線多媒體和基于Internet 的應用。在信息傳輸的過程中，不可避免的就是噪聲。H.264 本身具有很好的抗噪聲技術，如SPS，PPS 和圖像數據的分開打包， 一幀中可有多個Slice，靈活宏塊順序（FMO）等。但是也有很多情況錯誤無法被完全修復。H.264 具有很高的壓縮率（7～50 倍），這就意味著圖像中的冗余已經被大大消除，要從其余的碼流中恢復圖像有很大困難。此外，H.264 壓縮標準采用變長編碼的CAVLC 和CABAC，一旦在這些地方出錯， 解碼器將無法判斷下一個變長碼開始的位置，導致錯誤的擴散。

　　在硬件方面，解碼過程中各部分的實現都有其固定的結構，如果不及時檢出錯誤，會導致如內存溢出、查表錯誤、狀態機進入死循環等。解碼出的圖像會錯位或者變形， 更嚴重的時候整個解碼器會停止運行。

　　所以在解碼器中加入糾錯功能，及早地發現碼流噪聲并將解碼器恢復到正常的狀態是非常有意義而且非常必要的。

　　本項目的解碼器是基于SoC 的ASIC 解決方案，它具有高速、低功耗、低成本的特點。添加糾錯功能可以提高解碼器的適用性和穩定性，另一方面，應該盡量減少糾錯模塊對原有芯片的面積和速度的影響。

　　2 碼流結構和錯誤檢出

　　H.264 標準壓縮的碼流具有嚴格的格式。公共信息被提取出來作為SPS（序列參數集）， PPS（圖像參數集）單獨打包，與像素信息分離。SPS 和PPS 是碼流中極為重要的信息，將它們單獨打包可以在傳輸環境較差的情況下多次傳送，這在一定程度上增強了碼流傳輸的抗干擾能力。每個包被稱作一個NAL 單元，根據NAL 類型，各個數據包中的數據按照協議中規定的句法元素順序緊密排列。這為糾錯提供了兩點便利：（1）各個NAL 中的錯誤不會蔓延，即如果當前NAL 中檢測出了錯誤而且又無法確定錯誤終止的地方，那么可以將當前包丟棄，直到下一個NAL 開始；（2）很多句法元素都有其固定的范圍。檢測解碼出的元素值是否超出范圍限制是一個非常有用的辦法，也能盡早發現錯誤，避免解碼器進入異常狀態。

　　H.264 視頻碼流包括五個層次的信息： 序列層，圖像層，片層，宏塊層，子宏塊層，分別與NAL 類型的SPS，PPS，Slice（包括片頭，宏塊，子宏塊信息）相對應。

　　宏塊是編解碼處理的基本單位，也是進行錯誤修補的基本單位。H.264 視頻碼流結構如圖1 所示。

　　圖1 H.264 碼流結構

　　在上面的幾個層次中，每一層都具有其特定的句法元素結構，以及相應句法的處理辦法，整個錯誤檢測功能就是基于此實現的。目前可以檢測到的錯誤基于以下幾類：

　?。?）保留位錯誤。這是最容易檢測出的錯誤。在H.264 協議中規定了一些保留位， 如NAL 起始的forbidden＿zero＿bit，SPS 中的reserved＿zero＿4bits 等。解碼器順序讀入碼流時要確定這些保留位的值是正確的，如果有誤，就應該丟棄當前的包或者標記錯誤，做進一步的處理。

　?。?）句法元素值不在指定范圍。大多數的句法元素，尤其是在SPS 和PPS，都有一個指定的范圍。如用于計算最大幀數的log2＿max＿frame＿num＿minus4 必須在0～12 之間，如果讀入的值超出這個范圍，即可以判斷當前讀入的碼流有錯誤。

　?。?）相關句法元素矛盾。有一些句法元素讀入了一個錯誤的值，但仍然在正確的范圍內，單單通過當前語句是無法檢測出的。這時候就要利用句法元素之間的相關性，判斷讀出的值是否合理。例如PPS 中要指定當前圖像所引用的序列參數信息， 即PPS－＞seq＿parAMEter＿set＿id。如果當前引用的SPS 的ID 在所有收到的SPS 中不存在， 即可判斷SPS 或者當前PPS 有一方出了問題； 對于slice＿type 的I，B，P 各種類型，mb＿type 的查表方法也不同， 如果在I slice 中出現了幀間預測的宏塊類型，也可以判斷出錯。

　　以上方法都是可以通過句法元素本身的值判斷出來的，可以在讀入碼流的同時處理，即在處理PPS、SPS 的相應語句后加入判斷，不會對原有解碼器造成太大的影響。

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

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

　　圖2 亮度分量Intra 16×16 水平預測模式

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

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

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

　　3 軟硬件協同系統中的糾錯實現

　　盡管在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;

　　}

　　硬件主要負責宏塊層和子宏塊層的解碼，能夠發現預測模式、熵解碼的錯誤。如果硬件解碼過程中檢測出錯誤，硬件會向軟件發送HasErr＿hw 信號。例如在幀內預測時，需要判斷相鄰宏塊的可用情況。在讀幀內預測模式的語句后加入以下判斷：

　　整個糾錯過程由軟件控制，修補過程由軟件直接發送數據給硬件后端。硬件檢測出錯誤并向軟件傳遞HasErr 信號，軟件會做相應的數據處理，向硬件發送Err＿Processing 信號， 并根據錯誤修補方案代替前端數據處理部分為解碼器后端提供數據，如圖3 中虛線所示。

　　圖3 H.264 解碼器結構圖

　　在修補過程中， 由于采用基于空間連續性的預測，所以可以使用原有硬件中的幀內預測部分。但是，出錯后原有的一些信號需要做相應的處理，否則控制部分的一些狀態機會進入異常狀態導致硬件無法繼續正常運行。

　　4 實驗結果

　　本實驗先在PC 機上對C 模型修改和完善，硬件測試平臺則采用Xilinx Virtex4 系列的開發板。解碼器軟件部分使用C 語言編寫，Linux 下gcc 編譯，生成的二進制文件運行于基于開放核OPENRISC1200 的CPU；硬件部分使用Verilog HDL 描述。測試所用輸入碼流為ITU－T 提供的參考序列［2］，加入11 個固定噪聲樣本。實驗證明解碼器能順利解碼的噪聲碼流比例有了很大提高，圖像播放流暢，很多受損的地方得到了較好的修補，但是也有一些能看出明顯的修補痕跡。

　　5 結論

　　在解碼器中加入錯誤檢查和修補功能，提高了解碼器處理受損碼流的能力，解碼器因此可以在更復雜的環境中使用，穩定性也有所提高。H.264 視頻壓縮標準本身具有一些支持錯誤修補的技術，比如可以多次重復傳輸SPS 和PPS，多個Slice，FMO 等。多次傳輸SPS 和PPS 以降低傳輸效率為代價獲得接收端更高的準確率， 這在某些環境中是非常必要的。多個Slice 和FMO 在一定程度上增加了編碼和解碼的復雜度，但是它使得更多的周邊宏塊信息可以用于受損宏塊的預測和修補。此外，就修補方式而言，也有基于幀間相關性和其它幀內預測插值方法的研究。本實驗的主要目標是使解碼器能順利解碼并且盡量重復利用已有的硬件單元，減少由于添加糾錯功能帶來的硬件面積增加。采用16×16 幀內預測的方法修補，圖像質量相對于未修補時有了很大提高，但是有些地方還是有比較明顯的修補痕跡。尋找更好的圖像修補辦法，使修補后的圖像盡量接近原始圖像，減少可以明顯分辨的修補痕跡，這些是需要繼續研究的內容。