1 引言

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

　　在硬件方面，解碼過程中各部分的實(shí)現(xiàn)都有其固定的結(jié)構(gòu)，如果不及時(shí)檢出錯(cuò)誤，會(huì)導(dǎo)致如內(nèi)存溢出、查表錯(cuò)誤、狀態(tài)機(jī)進(jìn)入死循環(huán)等。解碼出的圖像會(huì)錯(cuò)位或者變形， 更嚴(yán)重的時(shí)候整個(gè)解碼器會(huì)停止運(yùn)行。

　　所以在解碼器中加入糾錯(cuò)功能，及早地發(fā)現(xiàn)碼流噪聲并將解碼器恢復(fù)到正常的狀態(tài)是非常有意義而且非常必要的。

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

　　2 碼流結(jié)構(gòu)和錯(cuò)誤檢出

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

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

　　宏塊是編解碼處理的基本單位，也是進(jìn)行錯(cuò)誤修補(bǔ)的基本單位。H.264 視頻碼流結(jié)構(gòu)如圖1 所示。

　　圖1 H.264 碼流結(jié)構(gòu)

　　在上面的幾個(gè)層次中，每一層都具有其特定的句法元素結(jié)構(gòu)，以及相應(yīng)句法的處理辦法，整個(gè)錯(cuò)誤檢測(cè)功能就是基于此實(shí)現(xiàn)的。目前可以檢測(cè)到的錯(cuò)誤基于以下幾類：

　?。?）保留位錯(cuò)誤。這是最容易檢測(cè)出的錯(cuò)誤。在H.264 協(xié)議中規(guī)定了一些保留位， 如NAL 起始的forbidden＿zero＿bit，SPS 中的reserved＿zero＿4bits 等。解碼器順序讀入碼流時(shí)要確定這些保留位的值是正確的，如果有誤，就應(yīng)該丟棄當(dāng)前的包或者標(biāo)記錯(cuò)誤，做進(jìn)一步的處理。

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

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

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

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

　　（4）引用的參考不存在。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è)，則說明這種預(yù)測(cè)方式是錯(cuò)誤的。而在幀間預(yù)測(cè)時(shí)，要指定參考?jí)K所在參考圖像的編號(hào)和位置，如果不存在當(dāng)前編號(hào)所指向的參考幀或參考?jí)K的位置超出了圖像范圍，就說明當(dāng)前的引用有誤。由于宏塊信息采用變長(zhǎng)編碼且沒有特定符號(hào)分割，一旦發(fā)現(xiàn)錯(cuò)誤，其后的數(shù)據(jù)直到下一個(gè)NAL 開始都應(yīng)被丟棄。

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

　?。?）查表無對(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ò)誤等。這種情況無法在解碼句法元素的時(shí)候立即判斷出錯(cuò)誤（值在正常范圍內(nèi)且隊(duì)列沒有出現(xiàn)異常）， 雖然在人工調(diào)試的時(shí)候可以根據(jù)后面往隊(duì)列中插入?yún)⒖紟那闆r檢查出來， 但是對(duì)于實(shí)時(shí)解碼器來說這樣是沒有意義的。這時(shí)候不需要放棄當(dāng)前NAL 中的數(shù)據(jù)，只要將臨近參考幀的信息復(fù)制到參考隊(duì)列里即可。

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

　　1 引言

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

　　在硬件方面，解碼過程中各部分的實(shí)現(xiàn)都有其固定的結(jié)構(gòu)，如果不及時(shí)檢出錯(cuò)誤，會(huì)導(dǎo)致如內(nèi)存溢出、查表錯(cuò)誤、狀態(tài)機(jī)進(jìn)入死循環(huán)等。解碼出的圖像會(huì)錯(cuò)位或者變形， 更嚴(yán)重的時(shí)候整個(gè)解碼器會(huì)停止運(yùn)行。

　　所以在解碼器中加入糾錯(cuò)功能，及早地發(fā)現(xiàn)碼流噪聲并將解碼器恢復(fù)到正常的狀態(tài)是非常有意義而且非常必要的。

　　本項(xiàng)目的解碼器是基于SoC 的ASIC 解決方案，它具有高速、低功耗、低成本的特點(diǎn)。添加糾錯(cuò)功能可以提高解碼器的適用性和穩(wěn)定性，另一方面，應(yīng)該盡量減少糾錯(cuò)模塊對(duì)原有芯片的面積和速度的影響。

　　2 碼流結(jié)構(gòu)和錯(cuò)誤檢出

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

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

　　宏塊是編解碼處理的基本單位，也是進(jìn)行錯(cuò)誤修補(bǔ)的基本單位。H.264 視頻碼流結(jié)構(gòu)如圖1 所示。

　　圖1 H.264 碼流結(jié)構(gòu)

　　在上面的幾個(gè)層次中，每一層都具有其特定的句法元素結(jié)構(gòu)，以及相應(yīng)句法的處理辦法，整個(gè)錯(cuò)誤檢測(cè)功能就是基于此實(shí)現(xiàn)的。目前可以檢測(cè)到的錯(cuò)誤基于以下幾類：

　?。?）保留位錯(cuò)誤。這是最容易檢測(cè)出的錯(cuò)誤。在H.264 協(xié)議中規(guī)定了一些保留位， 如NAL 起始的forbidden＿zero＿bit，SPS 中的reserved＿zero＿4bits 等。解碼器順序讀入碼流時(shí)要確定這些保留位的值是正確的，如果有誤，就應(yīng)該丟棄當(dāng)前的包或者標(biāo)記錯(cuò)誤，做進(jìn)一步的處理。

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

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

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

　　并非所有的碼流錯(cuò)誤都能直接通過句法元素的值判斷出來。一些句法元素的值會(huì)影響解碼方法并且被重復(fù)使用，所以有些錯(cuò)誤是可以在解碼過程中發(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è)，則說明這種預(yù)測(cè)方式是錯(cuò)誤的。而在幀間預(yù)測(cè)時(shí)，要指定參考?jí)K所在參考圖像的編號(hào)和位置，如果不存在當(dāng)前編號(hào)所指向的參考幀或參考?jí)K的位置超出了圖像范圍，就說明當(dāng)前的引用有誤。由于宏塊信息采用變長(zhǎng)編碼且沒有特定符號(hào)分割，一旦發(fā)現(xiàn)錯(cuò)誤，其后的數(shù)據(jù)直到下一個(gè)NAL 開始都應(yīng)被丟棄。

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

　　（5）查表無對(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ò)誤等。這種情況無法在解碼句法元素的時(shí)候立即判斷出錯(cuò)誤（值在正常范圍內(nèi)且隊(duì)列沒有出現(xiàn)異常）， 雖然在人工調(diào)試的時(shí)候可以根據(jù)后面往隊(duì)列中插入?yún)⒖紟那闆r檢查出來， 但是對(duì)于實(shí)時(shí)解碼器來說這樣是沒有意義的。這時(shí)候不需要放棄當(dāng)前NAL 中的數(shù)據(jù)，只要將臨近參考幀的信息復(fù)制到參考隊(duì)列里即可。

　　以上是檢錯(cuò)方法的大致概括。由于噪聲是隨機(jī)的，錯(cuò)誤可能出現(xiàn)在解碼過程的任何一個(gè)地方，所以只有通過調(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è)模式，通過周邊宏塊邊界上的像素值修補(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ò)誤則通過總線向硬件發(fā)送信號(hào)HasErr＿soft。例如，在解析PPS 的函數(shù)中，解碼無符號(hào)指數(shù)哥倫布（ue） 得到用來表示當(dāng)前PPS 所調(diào)用SPS ID 的句法元素seq＿parameter＿set＿id， 然后判斷解碼器是否收到過此ID 標(biāo)號(hào)的SPS， 如果無此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

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

　　return;

　　}

　　硬件主要負(fù)責(zé)宏塊層和子宏塊層的解碼，能夠發(fā)現(xiàn)預(yù)測(cè)模式、熵解碼的錯(cuò)誤。如果硬件解碼過程中檢測(cè)出錯(cuò)誤，硬件會(huì)向軟件發(fā)送HasErr＿h(yuǎn)w 信號(hào)。例如在幀內(nèi)預(yù)測(cè)時(shí)，需要判斷相鄰宏塊的可用情況。在讀幀內(nèi)預(yù)測(cè)模式的語句后加入以下判斷：

　　整個(gè)糾錯(cuò)過程由軟件控制，修補(bǔ)過程由軟件直接發(fā)送數(shù)據(jù)給硬件后端。硬件檢測(cè)出錯(cuò)誤并向軟件傳遞HasErr 信號(hào)，軟件會(huì)做相應(yīng)的數(shù)據(jù)處理，向硬件發(fā)送Err＿Processing 信號(hào)， 并根據(jù)錯(cuò)誤修補(bǔ)方案代替前端數(shù)據(jù)處理部分為解碼器后端提供數(shù)據(jù)，如圖3 中虛線所示。

　　圖3 H.264 解碼器結(jié)構(gòu)圖

　　在修補(bǔ)過程中， 由于采用基于空間連續(xù)性的預(yù)測(cè)，所以可以使用原有硬件中的幀內(nèi)預(yù)測(cè)部分。但是，出錯(cuò)后原有的一些信號(hào)需要做相應(yīng)的處理，否則控制部分的一些狀態(tài)機(jī)會(huì)進(jìn)入異常狀態(tài)導(dǎo)致硬件無法繼續(xù)正常運(yùn)行。

　　4 實(shí)驗(yàn)結(jié)果

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

　　5 結(jié)論

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