1 引言
H.264" title="H.264">H.264 視頻壓縮標(biāo)準(zhǔn)具有很高的壓縮效率和很好的網(wǎng)絡(luò)支持, 非常適應(yīng)于無(wú)線多媒體和基于Internet 的應(yīng)用。在信息傳輸?shù)倪^(guò)程中,不可避免的就是噪聲。H.264 本身具有很好的抗噪聲技術(shù),如SPS,PPS 和圖像數(shù)據(jù)的分開打包, 一幀中可有多個(gè)Slice,靈活宏塊順序(FMO)等。但是也有很多情況錯(cuò)誤無(wú)法被完全修復(fù)。H.264 具有很高的壓縮率(7~50 倍),這就意味著圖像中的冗余已經(jīng)被大大消除,要從其余的碼流中恢復(fù)圖像有很大困難。此外,H.264 壓縮標(biāo)準(zhǔn)采用變長(zhǎng)編碼的CAVLC 和CABAC,一旦在這些地方出錯(cuò), 解碼器" title="解碼器">解碼器將無(wú)法判斷下一個(gè)變長(zhǎng)碼開始的位置,導(dǎo)致錯(cuò)誤的擴(kuò)散。
在硬件方面,解碼過(guò)程中各部分的實(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)格的格式。公共信息被提取出來(lái)作為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ò)誤而且又無(wú)法確定錯(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),單單通過(guò)當(dāng)前語(yǔ)句是無(wú)法檢測(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ò)。
以上方法都是可以通過(guò)句法元素本身的值判斷出來(lái)的,可以在讀入碼流的同時(shí)處理,即在處理PPS、SPS 的相應(yīng)語(yǔ)句后加入判斷,不會(huì)對(duì)原有解碼器造成太大的影響。
并非所有的碼流錯(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)能力。
1 引言
H.264 視頻壓縮標(biāo)準(zhǔn)具有很高的壓縮效率和很好的網(wǎng)絡(luò)支持, 非常適應(yīng)于無(wú)線多媒體和基于Internet 的應(yīng)用。在信息傳輸?shù)倪^(guò)程中,不可避免的就是噪聲。H.264 本身具有很好的抗噪聲技術(shù),如SPS,PPS 和圖像數(shù)據(jù)的分開打包, 一幀中可有多個(gè)Slice,靈活宏塊順序(FMO)等。但是也有很多情況錯(cuò)誤無(wú)法被完全修復(fù)。H.264 具有很高的壓縮率(7~50 倍),這就意味著圖像中的冗余已經(jīng)被大大消除,要從其余的碼流中恢復(fù)圖像有很大困難。此外,H.264 壓縮標(biāo)準(zhǔn)采用變長(zhǎng)編碼的CAVLC 和CABAC,一旦在這些地方出錯(cuò), 解碼器將無(wú)法判斷下一個(gè)變長(zhǎng)碼開始的位置,導(dǎo)致錯(cuò)誤的擴(kuò)散。
在硬件方面,解碼過(guò)程中各部分的實(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)格的格式。公共信息被提取出來(lái)作為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ò)誤而且又無(wú)法確定錯(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),單單通過(guò)當(dāng)前語(yǔ)句是無(wú)法檢測(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ò)。
以上方法都是可以通過(guò)句法元素本身的值判斷出來(lái)的,可以在讀入碼流的同時(shí)處理,即在處理PPS、SPS 的相應(yīng)語(yǔ)句后加入判斷,不會(huì)對(duì)原有解碼器造成太大的影響。
并非所有的碼流錯(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ò)誤。
(6)其它異常情況。如參考隊(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;
}
硬件主要負(fù)責(zé)宏塊層和子宏塊層的解碼,能夠發(fā)現(xiàn)預(yù)測(cè)模式、熵解碼的錯(cuò)誤。如果硬件解碼過(guò)程中檢測(cè)出錯(cuò)誤,硬件會(huì)向軟件發(fā)送HasErr_h(yuǎn)w 信號(hào)。例如在幀內(nèi)預(yù)測(cè)時(shí),需要判斷相鄰宏塊的可用情況。在讀幀內(nèi)預(yù)測(cè)模式的語(yǔ)句后加入以下判斷:
整個(gè)糾錯(cuò)過(guò)程由軟件控制,修補(bǔ)過(guò)程由軟件直接發(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ǔ)過(guò)程中, 由于采用基于空間連續(xù)性的預(yù)測(cè),所以可以使用原有硬件中的幀內(nèi)預(yù)測(cè)部分。但是,出錯(cuò)后原有的一些信號(hào)需要做相應(yīng)的處理,否則控制部分的一些狀態(tài)機(jī)會(huì)進(jìn)入異常狀態(tài)導(dǎo)致硬件無(wú)法繼續(xù)正常運(yùn)行。
4 實(shí)驗(yàn)結(jié)果
本實(shí)驗(yàn)先在PC 機(jī)上對(duì)C 模型修改和完善,硬件測(cè)試平臺(tái)則采用Xilinx Virtex4 系列的開發(fā)板。解碼器軟件部分使用C 語(yǔ)言編寫,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ò)功能帶來(lái)的硬件面積增加。采用16×16 幀內(nèi)預(yù)測(cè)的方法修補(bǔ),圖像質(zhì)量相對(duì)于未修補(bǔ)時(shí)有了很大提高,但是有些地方還是有比較明顯的修補(bǔ)痕跡。尋找更好的圖像修補(bǔ)辦法,使修補(bǔ)后的圖像盡量接近原始圖像,減少可以明顯分辨的修補(bǔ)痕跡,這些是需要繼續(xù)研究的內(nèi)容。