基于DXVA的多路H.264高清視頻解碼器的實現

蘇俊峰，朱秀昌

（南京郵電大學 江蘇省圖像處理和通信重點實驗室，江蘇 南京 210003）

0 引言

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

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

1 H.264標準和DXVA技術

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

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

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

2 高清解碼器的設計和實現

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

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

2.1 DXVA解碼器使用的緩沖區

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

1）圖片參數。在DXVA解碼器解碼當前幀時需要一個對當前幀描述的參數，對于H.264標準用DX?VA_PicParams_H264結構體描述。圖片級別中每個圖片的信息會不一樣，所以每解碼一幀圖片之前，此結構體都要被傳送。以下是DXVA_PicParams_H264結構體的定義：

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

2）條帶控制參數。條帶控制參數是對當前碼流的描述，用DXVA_Slice_H264_Short結構體來描述，其定義為：

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

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

該緩沖區數據結構包括兩種反量化矩陣，即4×4和8×8反量化矩陣。碼流緩沖區是一塊分配的顯存地址，把解碼的碼流通過該緩沖區傳送給GPU。

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

NV12格式中每個視頻數據采樣點的每個分量用1 byte表示，存放的方式是一幀數據中所有的Y分量存儲在第一個區域內，后面是UV數據的打包形式，即每個像素的UV分量交替存儲。而數據在表面中存儲也是按行存儲的，即表面每行視頻數據的字節數是和分辨力有關的，但每行的實際長度和分辨力不一定一樣，這主要取決于顯卡驅動程序。可以通過調用顯卡驅動的API函數來獲取表面中每行的實際長度。圖3是NV12類型的表面示意圖，其中視頻的分辨力是1 280×720，驅動程序是NVIDIA 266.58版本。由圖3可知，表面的實際長度是2 048，而不是1 280。

2.2 視頻數據的后期處理

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

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

2.3 多路解碼器的設計與實現

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

在整個程序的設計過程中，主要定義了代表顯卡設備的數據結構和代表解碼器的數據結構。因為驅動程序允許多個對象共享一個硬件設備，所以多個解碼器可以關聯一個顯卡設備。顯卡數據結構的定義為：

其中，Hwnd是程序創建的一個用來顯示的窗口句柄，pD3D9和pD3DD9分別表示顯卡對象和顯卡設備，pD3Dmanager是一個顯卡設備的管理器，主要是用來管理多個解碼器共享顯卡設備的，PCI_Vendor代表顯卡的制造廠商，DecoderCnt是表示和顯卡關聯的解碼器個數。解碼器定義的數據結構如下：

pD3Dmanager是解碼器關聯的顯卡設備，pDX?VADecoder是所創建的解碼器，pD3D9 Surface是解碼后的數據存放的表面，DxvaPicParams，DxvaSliceShort和Dx?vaQmatrix是提到的解碼硬件單元用到的數據緩沖區結構，sps和pps是H.264標準中所表示的條帶控制參數和圖像控制參數。在設計中，本文定義了設備的創建和解碼接口，這樣方便其他的程序或客戶使用，在整個系統中，主要定義了5個接口函數：

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

2）HRESULT Create Dxva Decoder（DXVADecoderH264*pDecoder）。函數的功能是根據所關聯的D3Dmanager創建一個硬件解碼器對象，并使所關聯的D3Dmanager數據結構中的解碼器的計數加1。

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

4）HRESULT Destroy Dxva Decoder（DXVADecoderH264*pDecoder）。函數的功能是釋放解碼設備并使所關聯的D3Dmanager數據結構中的解碼器計數減1。

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

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

3 解碼器性能評測

由于顯卡驅動程序對硬件解碼單元最大的解碼路數的限制，其限制最高同時執行4路解碼，所以測試時開啟4個解碼線程同時解碼分辨力為1 280×720的高清視頻。評測的環境是雙核CPU 2.5 GHz，內存DDR2 2 Gbyte，顯卡GF9500GT，并在Visual Studio 2008環境下調試編譯，計時采用C語言庫的clock（）函數，精確到毫秒級。解碼器同時解碼4路高清視頻的顯示效果如圖7所示。

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

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

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

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

4 小結

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

[1]孫立，王健，郭春輝，等.基于CUDA的H.264去方塊濾波的設計和實現[J].電視技術，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]畢厚杰.新一代視頻壓縮編碼標準[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]朱秀昌，劉峰，胡棟.數字圖像處理與圖像通信[M].2版.北京：北京郵電大學出版社，2008.

[7]張帆，史彩成.Windows驅動開發技術詳解[M].北京：電子工業出版社，2008.

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