<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 設(shè)計應(yīng)用 > 針對硬件實現(xiàn)的H.264視頻編碼算法改進(jìn)

          針對硬件實現(xiàn)的H.264視頻編碼算法改進(jìn)

          作者: 時間:2007-03-09 來源:網(wǎng)絡(luò) 收藏
          摘要:從硬件實現(xiàn)的角度分析了H.264算法,重點研究了占用最多運算時間的預(yù)測部分的優(yōu)化,給出了對幀內(nèi)預(yù)測、哈達(dá)馬變換以及運動估計算法的改進(jìn),通過簡化運算復(fù)雜、效率不高的模塊以及減少模塊間數(shù)據(jù)相關(guān)性等,對硬件進(jìn)行優(yōu)化。通過對各種測試序列的仿真,證明改進(jìn)是有效的。 關(guān)鍵詞:H.264 幀內(nèi)預(yù)測 運動估計 運動預(yù)測因子 H.264[1]最初是由ITU-T起草的,在未來將成為ITU-T和MPEG的聯(lián)合標(biāo)準(zhǔn)。H.264因為提供了很高的編碼壓縮效率、友好的面向網(wǎng)絡(luò)的接口,將成為下一代新的視頻編碼標(biāo)準(zhǔn)。但是編碼效率很高的同時,其算法的復(fù)雜度也提高了四倍,這在很大程序上限制了它的實現(xiàn)。因此,必須針對硬件的實現(xiàn)做改進(jìn)和優(yōu)化。 H.264的最初測試模型(JM)[2]是為了取得高的編碼效果而設(shè)計的。在這個測試模型中,有很多的算法需要很大的運算量,但是編碼效率的提高卻不多,并且很多模擬之間是數(shù)據(jù)相關(guān)的,這一點限制了用并行處理加速硬件的實現(xiàn)。 以前有文章分析過這種新的視頻編碼的復(fù)雜度[3~5]。但是這些研究都是通過軟件的分析得到H.264算法的復(fù)雜度的。這些結(jié)果對在軟件中的應(yīng)用是精確的,但是當(dāng)涉及硬件設(shè)計的并行處理時,就不再適用了。經(jīng)過試驗比較可以得出,在H.264硬件實現(xiàn)上的關(guān)鍵點是預(yù)測部分,因為此模塊所占的計算時間幾乎是總時間的90%。所以改進(jìn)的重點在預(yù)測部分。 1 H.264算法 圖1是關(guān)于一幀圖像的幀內(nèi)預(yù)測間預(yù)測的算法框圖。如果采用幀內(nèi)預(yù)測,幀間預(yù)測部分將不進(jìn)行判斷。在進(jìn)行幀間預(yù)測時,會使用多幀預(yù)測和可變塊大小的運動估計。編碼模式選擇部分在所有的預(yù)測模式中選擇一個最佳的預(yù)測模式。預(yù)測之后用原始的輸入幀和預(yù)測幀相減,得到殘差數(shù)據(jù)塊。對于亮度殘差塊做4%26;#215;4整數(shù)DCT變換,對于色度殘差塊的DC系數(shù)則進(jìn)行2%26;#215;2的整數(shù)DCT變換。對變換后的系數(shù)做掃描和量化處理后,再對量化后的系數(shù)進(jìn)行熵編碼,最終成為輸出的碼流。編碼模式通過模式表,也會輸入到熵編碼器中。重建的循環(huán)過程包括反量化、反DCT變換和反塊濾波。最后,將重建幀寫入到幀緩沖器中,準(zhǔn)備在以后運動估計中使用。 因為在空間預(yù)測和時間預(yù)測上幾乎花費了所有的計算能力,所以在JM 4.0上的算法改進(jìn)主要是在這兩部分上。在實現(xiàn)過程中,這兩部分通過硬件實現(xiàn),所以要針對硬件進(jìn)行優(yōu)化。 實現(xiàn)編碼器所用的硬件系統(tǒng)是基于宏塊,也就是說編碼器是對一個個連續(xù)的宏塊進(jìn)行操作。整個編碼系統(tǒng)可以看作一個宏塊的流水線,所以有可能在開始編碼下一個宏塊時,上一個宏塊重建過程不定期沒有完成,這就影響了流水線的進(jìn)行。很多基于宏塊的商業(yè)編碼器正是采用這種硬件實現(xiàn)模式,所以處理好這個問題至關(guān)重要。 2 幀內(nèi)預(yù)測 圖1中的編碼方框圖與H.261、H.263和MPEG-4中的相似。H.264中包含了4%26;#215;4和16%26;#215;16兩種幀內(nèi)預(yù)測部分。幀內(nèi)預(yù)測需要圖像重建的像素值才能實現(xiàn)。在一個典型的基于宏塊的系統(tǒng)中,只有在完成整個編碼程序后,重建的像素值才能得到。這種數(shù)據(jù)之間的相關(guān)性,會給硬件的實現(xiàn)帶來很大的困難。 2.1 4%26;#215;4幀內(nèi)預(yù)測 圖2描述了4%26;#215;4塊幀內(nèi)預(yù)測中數(shù)據(jù)的相關(guān)性。從a到p的像素值是從A到N及Q的像素值預(yù)測出來的。用大寫字母表示重建的像素值。因為一個宏塊由16個4%26;#215;4的塊組成,所以當(dāng)前塊沒有完成編碼之前是不能得到重建的像素值的。在JM中用了雙通道算法實現(xiàn)這些塊的編碼。為了做一個4%26;#215;4塊的預(yù)測,在JM中需要進(jìn)行變換、量化、反變換到反量化的過程。這對于一個硬件來說太復(fù)雜了。在現(xiàn)有的硬件水平上是不可能實現(xiàn)的。對這一點,需要對算法做如下改進(jìn):所有預(yù)測中所有的重建幀像素值用輸入幀的原始值代替。通過這樣的改進(jìn),4%26;#215;4的幀內(nèi)預(yù)測和變換可以在宏塊的流水線上順利地實現(xiàn)。 2.2 16%26;#215;16幀內(nèi)預(yù)測 圖3給出了16%26;#215;16幀內(nèi)預(yù)測的數(shù)據(jù)相關(guān)性。當(dāng)前宏塊的預(yù)測是基于重建幀中位于當(dāng)前宏塊位置上方的17個像素和左側(cè)的16個像素的。因為對當(dāng)前宏塊進(jìn)行預(yù)測時左邊宏塊的重建可能并未完全完成,當(dāng)用到當(dāng)前宏塊位置左側(cè)的那些像素時就用原始像素代替。 2.3 編碼模式選擇 按照前面所給出的改進(jìn)算法,如果只是簡單地用原始像素代替重建像素的話會造成編碼模式選擇的誤差。圖4給出了幀內(nèi)編碼的率失真改進(jìn)的曲線,仿真的序列是“Claire”、10fps。從圖4中可以看出,由編碼模式選擇的誤差引起的PSNR下降是很明顯的。原始像素是屬于同一幀的,而重建像素經(jīng)過幀間或幀內(nèi)編碼去除了冗余度,所以與重建像素相比原始像素有更高的相關(guān)性。因而用改進(jìn)后的幀內(nèi)預(yù)測算法產(chǎn)生的誤差要比用原算法大得多。為了減少編碼模式選擇的誤差,還需要對誤差代價函數(shù)(error cost function)進(jìn)行修改?,F(xiàn)在的做法是增加一個誤差項。這個誤差項體現(xiàn)原始像素和重建像素之間的差值。因為量化參數(shù)(QP)能夠影響原始像素和重建像素之間的不匹配,所以誤差項的確定與量化參數(shù)值有關(guān)。在H.264中,隨著量化參數(shù)的線性增加,量化對編碼的影響是呈指數(shù)增加的。為了符合這種影響的增長趨勢,誤差項的基本形式確定了a/b(51-Qp),其中a和b是待定系數(shù)。如何確定a和b是影響誤差消除的關(guān)鍵。 在H.264中,每級Qp的增量是12%,所以理論上與之相匹配的參數(shù)b應(yīng)該設(shè)置為1.12。但是誤差代價函數(shù)的計算是在哈達(dá)碼變換域中進(jìn)行的,對每個系數(shù)的加權(quán)系數(shù)是不同的。而且變換后的系數(shù)的概率分布是不定的。所以參數(shù)b的設(shè)定不能用理論值,應(yīng)該考慮用經(jīng)驗值來確定。 通過實驗仿真結(jié)果可以得出:對于4%26;#215;4幀內(nèi)預(yù)測,a設(shè)為80、b設(shè)為1.07。在對不同的序列測試中,這組參數(shù)值的效果最好。從圖4中看,改進(jìn)后的幀內(nèi)預(yù)測基本消除了模式選擇誤差,其PSNR的表現(xiàn)與原幀內(nèi)預(yù)測算法接近。 3 運動估計 在H.264中采用了可變的塊大小、1/4像紗和多參考幀的運動估計。在進(jìn)行運動估計過程中,全局搜索的起始搜索點根據(jù)運動預(yù)測因子確定。對于整像素搜索,失真用SAD度量。如果需更好的效果,可以將SAD加上補(bǔ)償項。雖然全局搜索運動估計有各種硬件結(jié)構(gòu)支持,但是從硬件實現(xiàn)角度來看,在H.264中原始的搜索范圍和運動預(yù)測因子的選擇是不實用的。以下介紹相應(yīng)的改進(jìn)。3.1 搜索范圍 硬件實現(xiàn)運動估計過程中,一般會通過使用片內(nèi)存儲彌補(bǔ)片外存儲帶寬的不足。在圖5中給出了一種典型的搜索區(qū)域數(shù)據(jù)重復(fù)使用方法,其中搜索范圍是-16~+15。圖5中左邊的3%26;#215;3塊表示當(dāng)前宏塊運動估計進(jìn)行區(qū)域,右邊的3%26;#215;3表示下一個宏塊運動估計進(jìn)行區(qū)域,它們的重疊區(qū)域的數(shù)據(jù)可以在兩次宏塊運動估計中重復(fù)使用,新增加的數(shù)據(jù)是最右側(cè)的1%26;#215;3區(qū)域。 為了配合H.264這種重復(fù)使用數(shù)據(jù)的模式,搜索區(qū)域的起始點應(yīng)該設(shè)置在(0,0)。只有當(dāng)真正的運動矢量超出搜索范圍時,這種改變才會造成視頻質(zhì)量的下降。 3.2 運動預(yù)測因子 在H.264中, 運動預(yù)測因子被用來確定運動矢量數(shù)據(jù)的比特數(shù)和計算運動矢量數(shù)據(jù)編碼誤差的補(bǔ)償因子。補(bǔ)償因子在整個運動估計過程中都會被參考以進(jìn)行率失真優(yōu)化。圖6表示運動預(yù)測因子的相關(guān)情況。其中P1到P4是在當(dāng)前宏塊之前的宏塊。當(dāng)前宏塊的運動預(yù)測因子通過對P1到P4宏塊的運動矢量計算得到。但是因為在硬件中,以上基于宏塊的處理過程是使用宏塊流水時,P1的運動矢量可能是無效的。解決這個問題需要消除運動預(yù)測因子計算過程中相關(guān)性。具體就是計算過程中只使用P2到P4宏塊的運動矢量。而改變的只是針對運動估計補(bǔ)償因子的計算,因此改進(jìn)算法仍然符合H.264標(biāo)準(zhǔn)。 3.3 1/4像素精度的運動估計 在H.264中,半像素運動估計是通過二維6抽頭內(nèi)插濾波實現(xiàn)的。二維濾波需要使用線路緩存實現(xiàn)轉(zhuǎn)置運算,而線路緩存的硬件實現(xiàn)相當(dāng)復(fù)雜。不過對編碼環(huán)路中的另一個部分運動補(bǔ)償時,該宏塊的運動矢量已經(jīng)確定。為了減少硬件代價,可以使用更簡單的方法來產(chǎn)生1/4像素精度的數(shù)據(jù)。雖然用于運動估計與用于運動補(bǔ)償?shù)?/4像紗數(shù)據(jù)沒必要相同,但是它們之間的誤差還是會對編碼效果產(chǎn)生影響。所以不能一味地簡化內(nèi)插過程。使用雙線性內(nèi)插代替二維6抽頭內(nèi)插濾波能夠較好地解決這個問題。 3.4 哈達(dá)碼變換 哈達(dá)碼變換是用簡單的變換估算變換后產(chǎn)生的比特數(shù)。在H.264的運動估計中用哈達(dá)碼變換替代SAD,如果要求設(shè)計低代價硬件可以將這部分省略。 4 仿真結(jié)果 軟件仿真是在“Foreman”、“grandma”、“salesman”和“carphone”序列上進(jìn)行的,幀率是每秒10幀。出于硬件的考慮,不采用率失真優(yōu)化模式,因為在JM4.0上沒有采用碼率控制,所以率失真曲線是對應(yīng)Qp的變化產(chǎn)生的。率失真曲線如圖7、圖8。從仿真結(jié)果中可以看出,在改進(jìn)的幀內(nèi)預(yù)測算法中,PSNR的下降程序是很低的。在慢速運動序列的整像素運動估計中,PSNR幾乎沒有下降。對QME算法的改進(jìn)會造成大約0.4~0.6dB的PSNR值下降。這種改進(jìn)在低代價系統(tǒng)中是可以接受的。在64kbps的環(huán)境下,每一個序列的PSNR的下降不超過0.58dB。 在基于宏塊處理的系統(tǒng)中,采用上述的改進(jìn)算法,就能實現(xiàn)并行處理。通過軟件仿真的結(jié)果表明,改進(jìn)幀內(nèi)預(yù)測和整像素運動估計上的算法后,其PSNR值的下降幾乎可以忽略。對低人代價系統(tǒng)來說,QME和哈達(dá)馬變換的改進(jìn)也量種可以考慮的方法。

          評論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();