蘇俊峰，朱秀昌

（南京郵電大學(xué) 江蘇省圖像處理和通信重點(diǎn)實(shí)驗(yàn)室，江蘇 南京 210003）

0 引言

H.264是目前視頻壓縮領(lǐng)域編碼效率較高的視頻編碼標(biāo)準(zhǔn)，但是其運(yùn)算復(fù)雜度較高，特別是隨著高清數(shù)字電視（HDTV）技術(shù)廣泛應(yīng)用和互聯(lián)網(wǎng)的快速發(fā)展，使編解碼器對處理器的要求越來越高[1]。HD視頻中較低的解析度即為720p分辨力，采樣點(diǎn)高達(dá)1 280×720，而頂級格式的1 080p更是達(dá)到了1 920×1 080。在高分辨力的情況下，其碼率是很高的。例如，720p格式中幀率為60 bit，10 bit量化、4∶2∶0采樣方式，其碼率為791 Mbit/s，如果采用視頻壓縮技術(shù)，壓縮后碼率也超過12 Mbit/s，這也就意味著視頻解碼和后期處理對處理器具有很大的挑戰(zhàn)。

如何在現(xiàn)有計算機(jī)的基礎(chǔ)上降低視頻解碼對硬件的要求，進(jìn)而降低CPU的使用率已成為視頻解碼技術(shù)的研究熱點(diǎn)。當(dāng)前主流的方法是通過利用GPU（Graphic Pro?cessing Unit）來分擔(dān)視頻解碼的部分工作[2]。而利用GPU來進(jìn)行視頻解碼的技術(shù)主要有兩種方式：第一種是利用GPU內(nèi)部能夠并行工作的流處理單元，編寫在GPU上運(yùn)行的代碼，典型的代表有NVIDIA的CUDA和ATI的Stream技術(shù)；第二種是間接通過GPU來加速，通過制定統(tǒng)一的解碼接口來實(shí)現(xiàn)，主要是微軟的DXVA（DirectX Video Acceleration）。第一種方式在解碼速度上有優(yōu)勢，但是實(shí)現(xiàn)起來比較復(fù)雜，而且必須熟悉GPU的架構(gòu)和數(shù)據(jù)處理流程，針對不同的GPU設(shè)備，實(shí)現(xiàn)的代碼不相同，跨平臺性能差。而第二種在速度上可能有一點(diǎn)遜色，但是實(shí)現(xiàn)起來簡單，可擴(kuò)展性能好，針對不同的GPU設(shè)備，只要支持DXVA都可以使用。通過以上分析，本文采用基于DXVA的H.264視頻解碼設(shè)計。

1 H.264標(biāo)準(zhǔn)和DXVA技術(shù)

H.264是目前視頻壓縮領(lǐng)域編碼效率較高的編解碼標(biāo)準(zhǔn)。其軟件解碼框圖如圖1所示。主要完成以下功能：解碼器首先提取H.264碼流中的NAL單元，然后對NAL單元進(jìn)行熵解碼、反量化和反變換，根據(jù)參考幀和運(yùn)動矢量進(jìn)行預(yù)測和運(yùn)動補(bǔ)償，然后把解碼出的圖像進(jìn)行環(huán)路濾波，最后對濾波的圖像進(jìn)行顯示和參考幀緩存[3-6]。

DXVA是微軟為加強(qiáng)視頻播放效果所設(shè)立的一套API（Application Programming Interface）和 DDI（Device Driver Interface）。通過DXVA可以把解碼的部分工作和視頻的后期處理操作從CPU轉(zhuǎn)移到GPU，這樣利用了GPU硬件單元的并行處理來加速視頻播放的效果，從而降低了CPU的利用率[7]。

在H.264視頻解碼的過程中，運(yùn)動補(bǔ)償、反離散余弦變換和可變長編碼這些操作占了解碼總操作時間的80%以上[8]，因此，如果能夠減少這些操作的時間，那么解碼的整個時間一定會減少很多，而且也會大大降低CPU的工作量。目前DXVA規(guī)范規(guī)定的硬件加速的操作也正是這些解碼過程，不過DXVA是按等級來劃分的。例如，對于H.264標(biāo)準(zhǔn)來說共分為6個等級，分別為DXVA2_Mo?deH264_A～DXVA2_ModeH264_F。因此，GPU廠商在實(shí)現(xiàn)這些接口的時候也只是實(shí)現(xiàn)了其中的一些子集，本文采用GF9500GT實(shí)現(xiàn)的等級是DXVA2_ModeH264_E，也就是MC，IDCT和VLC的解碼操作都是在GPU上實(shí)現(xiàn)的。

2 高清解碼器的設(shè)計和實(shí)現(xiàn)

要實(shí)現(xiàn)解碼器的硬件加速功能，就是把軟件解碼器的部分工作轉(zhuǎn)移到顯卡的GPU上來完成，但是由于顯存和內(nèi)存之間數(shù)據(jù)總線的傳輸速率相對于處理器的處理速度比較慢，所以在設(shè)計解碼器的過程中要盡量減少數(shù)據(jù)在內(nèi)存和顯存之間的傳輸次數(shù)，并且解碼之后的數(shù)據(jù)盡量不要再傳回內(nèi)存，否則可能會降低解碼器的性能，也就是說把視頻數(shù)據(jù)的后期處理（如顏色空間轉(zhuǎn)換、縮放等一些特效）也利用顯卡進(jìn)行。

如圖2所示，DXVA硬件解碼主要有3種處理架構(gòu)：將解碼的MC部分轉(zhuǎn)移到GPU中；MC和IDCT轉(zhuǎn)移到GPU中；將MC，IDCT和VLD轉(zhuǎn)移到GPU中執(zhí)行。圖中虛線以上為CPU執(zhí)行部分，虛線以下為GPU執(zhí)行部分。本文按第3種架構(gòu)來實(shí)現(xiàn)H.264視頻解碼器。

2.1 DXVA解碼器使用的緩沖區(qū)

解碼器如果要使用硬件解碼單元，必須要給硬件單元傳送一定的配置參數(shù)，DXVA同樣也不例外，每個參數(shù)都是以對應(yīng)的緩沖區(qū)來傳送的，所以，如果要傳送參數(shù)必須首先向DXVA申請緩沖區(qū)，然后填充對應(yīng)類型的緩沖區(qū)。本文解碼器需要傳送4個解碼參數(shù)，即4個緩沖區(qū)：圖片參數(shù)緩沖區(qū)、條帶控制命令緩沖區(qū)、碼流緩沖區(qū)和量化值緩沖區(qū)。

1）圖片參數(shù)。在DXVA解碼器解碼當(dāng)前幀時需要一個對當(dāng)前幀描述的參數(shù)，對于H.264標(biāo)準(zhǔn)用DX?VA_PicParams_H264結(jié)構(gòu)體描述。圖片級別中每個圖片的信息會不一樣，所以每解碼一幀圖片之前，此結(jié)構(gòu)體都要被傳送。以下是DXVA_PicParams_H264結(jié)構(gòu)體的定義：

例如參數(shù)中的wFrameWidthInMbsMinus1對應(yīng)于H.264標(biāo)準(zhǔn)中的同名參數(shù)。本文在傳送該參數(shù)前需要先調(diào)用IdirectXVideoDecoder：：GetBuffer（）來獲得圖像參數(shù)的緩沖區(qū)，該函數(shù)共有3個參數(shù)，分別為緩沖區(qū)類型，指向緩沖區(qū)的指針地址和緩沖區(qū)的大小，對于圖片參數(shù)來說，緩沖區(qū)類型為DXVA2_PictureParametersBufferType，而這個緩沖區(qū)類型是枚舉類型。得到此緩沖區(qū)之后即可以進(jìn)行配置圖片參數(shù)。

2）條帶控制參數(shù)。條帶控制參數(shù)是對當(dāng)前碼流的描述，用DXVA_Slice_H264_Short結(jié)構(gòu)體來描述，其定義為：

其中，BSNALunitDataLocation表示傳送碼流的NA?LU單元中編碼數(shù)據(jù)的起始字節(jié)數(shù)，wBadSliceChopping表示傳送的碼流是否包含起始碼，SliceBytesInBuffer表示傳送碼流總的字節(jié)數(shù)，此數(shù)值不是用戶實(shí)際傳送的碼流字節(jié)數(shù)，而是用戶傳送的碼流按照128 byte對齊的數(shù)值，不足的部分用零填充，對齊的主要作用是在內(nèi)存和顯存之間能夠高效快速地傳送數(shù)據(jù)。

3）量化矩陣緩沖區(qū)和碼流緩沖區(qū)。量化矩陣緩沖區(qū)是解碼器進(jìn)行反量化時所用矩陣的緩沖區(qū)，其定義為：

該緩沖區(qū)數(shù)據(jù)結(jié)構(gòu)包括兩種反量化矩陣，即4×4和8×8反量化矩陣。碼流緩沖區(qū)是一塊分配的顯存地址，把解碼的碼流通過該緩沖區(qū)傳送給GPU。

4）存放視頻數(shù)據(jù)的緩沖區(qū)。碼流在GPU中解碼后的數(shù)據(jù)一般是YUV格式的，解碼后的數(shù)據(jù)存放在叫“表面”（Surface）的硬件緩沖區(qū)，即存放視頻數(shù)據(jù)的顯存。存放數(shù)據(jù)的方式取決于表面的類型（視頻數(shù)據(jù)的存放格式）以及顯卡所支持的類型，對于DXVA解碼來說，微軟推薦的視頻數(shù)據(jù)類型是NV12，所以大多數(shù)顯卡都支持這種視頻數(shù)據(jù)的存放格式。

NV12格式中每個視頻數(shù)據(jù)采樣點(diǎn)的每個分量用1 byte表示，存放的方式是一幀數(shù)據(jù)中所有的Y分量存儲在第一個區(qū)域內(nèi)，后面是UV數(shù)據(jù)的打包形式，即每個像素的UV分量交替存儲。而數(shù)據(jù)在表面中存儲也是按行存儲的，即表面每行視頻數(shù)據(jù)的字節(jié)數(shù)是和分辨力有關(guān)的，但每行的實(shí)際長度和分辨力不一定一樣，這主要取決于顯卡驅(qū)動程序?？梢酝ㄟ^調(diào)用顯卡驅(qū)動的API函數(shù)來獲取表面中每行的實(shí)際長度。圖3是NV12類型的表面示意圖，其中視頻的分辨力是1 280×720，驅(qū)動程序是NVIDIA 266.58版本。由圖3可知，表面的實(shí)際長度是2 048，而不是1 280。

2.2 視頻數(shù)據(jù)的后期處理

如前所述，視頻解碼后的數(shù)據(jù)是存儲在顯存中的，而且數(shù)據(jù)的格式和顯示器能夠顯示的格式是不相同的，要顯示解碼后的視頻圖像必須對數(shù)據(jù)進(jìn)行后期處理，例如反交織、圖像縮放和顏色空間轉(zhuǎn)換等操作。如果這些操作用軟件的方式通過CPU進(jìn)行處理，那么解碼后的視頻數(shù)據(jù)就必須從顯存再傳回內(nèi)存中，數(shù)據(jù)處理過之后再傳回顯存進(jìn)行顯示，由于總線數(shù)據(jù)傳送速度的限制，這樣會大大降低解碼器的性能，甚至?xí)菇獯a器的解碼速度達(dá)不到播放的要求。

現(xiàn)在的主流顯卡一般都集成了視頻的后期處理功能，這樣就能夠使解碼后的數(shù)據(jù)不用再傳回內(nèi)存而在顯卡內(nèi)就可以進(jìn)行處理，而且基于硬件的處理操作速度會比軟件更快，這樣也就進(jìn)一步提高了解碼器的性能。DXVA規(guī)范中關(guān)于后期處理的操作是DXVA Video Process?ing，該操作可以完成視頻數(shù)據(jù)的后期處理，包括反交織、視頻流混合、圖像縮放、顏色空間轉(zhuǎn)換和圖像濾波等。其示意圖如圖4所示。

2.3 多路解碼器的設(shè)計與實(shí)現(xiàn)

本文在設(shè)計解碼器的過程中把大量的算術(shù)運(yùn)算轉(zhuǎn)移到GPU上，利用其硬件單元來解碼，但是對于碼流的頭部解析包含大量的邏輯運(yùn)算，如果也轉(zhuǎn)移到GPU上進(jìn)行，對解碼器的性能有很大的損耗。所以在系統(tǒng)設(shè)計時把碼流的頭部解析通過軟件來進(jìn)行。

在整個程序的設(shè)計過程中，主要定義了代表顯卡設(shè)備的數(shù)據(jù)結(jié)構(gòu)和代表解碼器的數(shù)據(jù)結(jié)構(gòu)。因?yàn)轵?qū)動程序允許多個對象共享一個硬件設(shè)備，所以多個解碼器可以關(guān)聯(lián)一個顯卡設(shè)備。顯卡數(shù)據(jù)結(jié)構(gòu)的定義為：

其中，Hwnd是程序創(chuàng)建的一個用來顯示的窗口句柄，pD3D9和pD3DD9分別表示顯卡對象和顯卡設(shè)備，pD3Dmanager是一個顯卡設(shè)備的管理器，主要是用來管理多個解碼器共享顯卡設(shè)備的，PCI_Vendor代表顯卡的制造廠商，DecoderCnt是表示和顯卡關(guān)聯(lián)的解碼器個數(shù)。解碼器定義的數(shù)據(jù)結(jié)構(gòu)如下：

pD3Dmanager是解碼器關(guān)聯(lián)的顯卡設(shè)備，pDX?VADecoder是所創(chuàng)建的解碼器，pD3D9 Surface是解碼后的數(shù)據(jù)存放的表面，DxvaPicParams，DxvaSliceShort和Dx?vaQmatrix是提到的解碼硬件單元用到的數(shù)據(jù)緩沖區(qū)結(jié)構(gòu)，sps和pps是H.264標(biāo)準(zhǔn)中所表示的條帶控制參數(shù)和圖像控制參數(shù)。在設(shè)計中，本文定義了設(shè)備的創(chuàng)建和解碼接口，這樣方便其他的程序或客戶使用，在整個系統(tǒng)中，主要定義了5個接口函數(shù)：

1）HRESULT InitD3D Manager（D3DManager*pMan?ager）。函數(shù)的主要功能是初始化顯卡并創(chuàng)建一個顯卡設(shè)備，檢測顯卡的類型等。

2）HRESULT Create Dxva Decoder（DXVADecoderH264*pDecoder）。函數(shù)的功能是根據(jù)所關(guān)聯(lián)的D3Dmanager創(chuàng)建一個硬件解碼器對象，并使所關(guān)聯(lián)的D3Dmanager數(shù)據(jù)結(jié)構(gòu)中的解碼器的計數(shù)加1。

3）HRESULT Dxva Decode Frame（DXVA DecoderH264*pDecoder，NALU_t*pH264NALU，RECT*pRect）。函數(shù)是解碼器的解碼接口，主要有3個參數(shù)，第1個是代表解碼器，pH264NALU是H.264碼流中的一個NALU單元，pRect是代表該解碼器解碼后的數(shù)據(jù)在顯示窗口的顯示區(qū)域。

4）HRESULT Destroy Dxva Decoder（DXVADecoderH264*pDecoder）。函數(shù)的功能是釋放解碼設(shè)備并使所關(guān)聯(lián)的D3Dmanager數(shù)據(jù)結(jié)構(gòu)中的解碼器計數(shù)減1。

5）HRESULT DestroyD3D Manager（D3DManager*pManager）。函數(shù)的功能是釋放顯卡設(shè)備并銷毀所創(chuàng)建的顯示窗口，該函數(shù)在銷毀之前會檢測其關(guān)聯(lián)的解碼個數(shù)是否為0，如果不為0，則該函數(shù)什么也不執(zhí)行并立即返回，所以在任何時候調(diào)用都能夠確保安全。

整個系統(tǒng)的流程如圖5所示，其中解碼器在解碼一幀數(shù)據(jù)時的內(nèi)部解碼流程如圖6所示。其中在解碼器內(nèi)部加一個阻塞鎖是為了防止多個解碼器同時使用一個硬件解碼單元，因此本文設(shè)計的系統(tǒng)可以開啟多個解碼線程進(jìn)行多路解碼。

3 解碼器性能評測

由于顯卡驅(qū)動程序?qū)τ布獯a單元最大的解碼路數(shù)的限制，其限制最高同時執(zhí)行4路解碼，所以測試時開啟4個解碼線程同時解碼分辨力為1 280×720的高清視頻。評測的環(huán)境是雙核CPU 2.5 GHz，內(nèi)存DDR2 2 Gbyte，顯卡GF9500GT，并在Visual Studio 2008環(huán)境下調(diào)試編譯，計時采用C語言庫的clock（）函數(shù)，精確到毫秒級。解碼器同時解碼4路高清視頻的顯示效果如圖7所示。

本文主要測試解碼器的解碼速度和CPU的占用率這兩個指標(biāo)。測試時，操作系統(tǒng)為Win7，CPU為奔騰雙核E5200 2.5 GHz，顯卡為中低端顯卡NVIDIA GeForce 9500T。在測試解碼速度時，采用固定碼率的碼流，碼率的大小和藍(lán)光DVD的碼率大小相接近，達(dá)18 Mbit/s。解碼速度指標(biāo)用每秒能夠解碼的幀數(shù)來衡量。測試結(jié)果如表1和表2所示。

表1 DXVA與軟解碼1路720p視頻的CPU占用率對比

表2 4路720p視頻解碼的速度

由表1和表2中可以看出，當(dāng)在播放高清視頻時打開DXVA功能時可以大大降低CPU的占用率，解碼速度提升4倍左右。完全可以勝任同時解碼4路720p的視頻，此時CPU的占用率約為40%，僅和CPU解碼一路視頻時的CPU占用率相當(dāng)。當(dāng)把顯卡更換為當(dāng)前市面上主流的中端顯卡GT440時，多路解碼器可以同時開啟12路高清解碼，是GF9500解碼能力的3倍，而且畫面流暢。

4 小結(jié)

隨著高清時代的到來，用戶對于視頻的清晰度有了更高的要求，而高的清晰度意味著對解碼器的解碼速度也提出了更高的要求。本文設(shè)計的基于GPU解碼器利用DXVA接口和GPU實(shí)現(xiàn)了多路高清視頻H.264解碼，大大提高了解碼速度，在實(shí)際應(yīng)用中獲得了很好的解碼效果。

[1]孫立，王健，郭春輝，等.基于CUDA的H.264去方塊濾波的設(shè)計和實(shí)現(xiàn)[J].電視技術(shù)，2010，34（5）：44-46.

[2]DirectX video acceleration specification for H.264/AVC decoding[EB/OL].[2010-12-10].http：//download.microsoft.com/download/5/f/c/5fc4ec5c-bd8c-4624-8034-319c1bab7671/DXVA_H264.pdf.

[3]畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)[M].2版.北京：人民郵電出版社，2009.

[4]H.264/MPEG-4 Part 10 white paper[EB/OL].[2010-12-10].http：//www.vcodex.com.

[5]Joint Video Team（JVT）of ISO/IEC MPEG and ITU-T VCEG.H.264 ISO/IEC 14496-10 AVC，Document JVT-G050[EB/OL].[2010-12-10].http：//wftp3.itu.int/av-arch/jvt-site/2005_07_Poznan/JVT-P050.doc.

[6]朱秀昌，劉峰，胡棟.數(shù)字圖像處理與圖像通信[M].2版.北京：北京郵電大學(xué)出版社，2008.

[7]張帆，史彩成.Windows驅(qū)動開發(fā)技術(shù)詳解[M].北京：電子工業(yè)出版社，2008.

[8]李本齋，吳從中，陳家銀.H.264運(yùn)動估計硬件加速器的設(shè)計[J].電視技術(shù)，2010，34（S1）：79-81.