陸許明+張嘉文+徐永鍵

摘要：隨著我國信息網(wǎng)絡(luò)的發(fā)展，互聯(lián)網(wǎng)視頻內(nèi)容相關(guān)服務(wù)得到了快速發(fā)展。針對分享式視頻服務(wù)對視頻編碼壓縮的處理需求，提出并設(shè)計了一種利用圖形處理器GPU協(xié)處理視頻編碼的服務(wù)平臺。在該系統(tǒng)中，視頻源輸入后經(jīng)過預(yù)處理得到解碼后的亮度和色度數(shù)據(jù)，然后根據(jù)系統(tǒng)硬件配置和資源占用情況，選擇GPU硬件編碼或CPU軟件編碼，最后得到編碼數(shù)據(jù)。測試結(jié)果表明，所提出的GPU協(xié)處理視頻編碼方案與CPU直接軟編碼方案相比，在保證編碼質(zhì)量的情況下，處理速度更快，編碼效率更高

關(guān)鍵詞：圖形處理器；視頻編碼；計算統(tǒng)一設(shè)備架構(gòu)；服務(wù)器

中圖分類號：TP37 文獻標(biāo)識碼：A 文章編號：1009-3044（2016）28-0206-02

隨著我國信息網(wǎng)絡(luò)基礎(chǔ)設(shè)施的規(guī)劃發(fā)展，高速寬帶網(wǎng)絡(luò)的建設(shè)得到不斷推進，基于網(wǎng)絡(luò)的視頻內(nèi)容急劇增加，視頻內(nèi)容服務(wù)也呈現(xiàn)井噴式的發(fā)展。例如基于互聯(lián)網(wǎng)的網(wǎng)絡(luò)直播、網(wǎng)絡(luò)視頻教學(xué)、視頻內(nèi)容分享等，基于局域網(wǎng)的多媒體共享、無線投屏應(yīng)用等。就技術(shù)的角度而言，視頻內(nèi)容服務(wù)的噴發(fā)一方面依賴于通信技術(shù)的發(fā)展，而另一方面則是依賴于視頻壓縮技術(shù)的不斷發(fā)展和成熟應(yīng)用。因此，高質(zhì)量的視頻壓縮技術(shù)的應(yīng)用就成為了人們關(guān)注的研究熱點[1]。

視頻壓縮是計算復(fù)雜度非常高的操作。對于專用于視頻壓縮的服務(wù)器，利用中央處理器（CPU，Central Processing Unit）進行編碼操作時，大量的視頻數(shù)據(jù)及其壓縮算法處理將會使CPU處于高負(fù)荷運行狀態(tài)。因此服務(wù)器對CPU的性能要求高，而且占用的功耗也非常大，甚至在極端情形下導(dǎo)致服務(wù)器難以對系統(tǒng)其他操作產(chǎn)生實時地響應(yīng)，出現(xiàn)操作系統(tǒng)假死現(xiàn)象。

圖形處理器（GPU，Graphics Processing Unit）是專門用于圖像運算工作的微處理器。隨著GPU的不斷推廣，利用GPU和CPU協(xié)同處理復(fù)雜計算的方法也發(fā)展起來[2]。利用GPU強大的并行運算能力，能夠大幅度提高系統(tǒng)協(xié)作的計算性能，從而將CPU從不擅長的并行運算中解放出來，更好地完成系統(tǒng)的管理控制工作。

H.264/MPEG-4 part 10 AVC （H.264/AVC）視頻編碼標(biāo)準(zhǔn)，是由國際化標(biāo)準(zhǔn)組織（ISO）和國際電信聯(lián)盟（ITU）于2003年共同提出的一種數(shù)字視頻壓縮格式標(biāo)準(zhǔn)[3]。優(yōu)秀的性能讓H.264/AVC廣泛應(yīng)用于廣播電視、無線多媒體等各個領(lǐng)域。因此，本文針對H.264編碼標(biāo)準(zhǔn)，研究CPU與GPU協(xié)同操作的編碼方法，提出一種跨平臺的視頻編碼服務(wù)方案，支持Windows和Linux等操作系統(tǒng)，支持CPU軟件編碼或GPU協(xié)同編碼，當(dāng)無法GPU編碼時，通過軟編碼實現(xiàn)視頻數(shù)據(jù)壓縮。

本文剩余部分安排如下：第1節(jié)介紹系統(tǒng)整體方案；第2節(jié)和第3節(jié)分別介紹系統(tǒng)軟件部分的預(yù)處理和編碼模塊設(shè)計；第4節(jié)對系統(tǒng)進行測試分析；最后總結(jié)全文。

1 系統(tǒng)整體方案

圖1 所示為采用NVIDIA顯卡的系統(tǒng)框圖。計算統(tǒng)一設(shè)備架構(gòu)（CUDA，Compute Unified Device Architecture） 是NVIDIA公司提出的一個基于GPU通用計算的開發(fā)環(huán)境。它針對GPU多處理單元的特性，通過并行計算提高大規(guī)模運算的速度[4]。利用CUDA并行計算架構(gòu)，能夠極大地提升H.264的編碼效率，在保證一定圖像質(zhì)量的前提下，大幅度降低編碼時對CPU核的占用。

系統(tǒng)方案由兩大部分組成，包括視頻源預(yù)處理模塊和視頻編碼模塊。視頻源預(yù)處理模塊根據(jù)視頻源的類型，進行相應(yīng)的處理，將其轉(zhuǎn)化為視頻編碼模塊支持的視頻格式。視頻編碼模塊則是實現(xiàn)視頻編碼操作，在不同的操作系統(tǒng)中調(diào)用不同的處理接口函數(shù)，并根據(jù)系統(tǒng)顯卡的配置，采用純軟件或GPU協(xié)同的方式進行視頻編碼。

2 視頻源預(yù)處理

由于系統(tǒng)的視頻源可能來自不同的采集設(shè)備，因此格式各有不同，特別是視頻的分辨率、幀率、編碼方案等，因此視頻壓縮服務(wù)器并不能直接對這些數(shù)據(jù)進行壓縮。視頻源預(yù)處理模塊就是系統(tǒng)的一個轉(zhuǎn)換接口，將各種視頻源轉(zhuǎn)換成統(tǒng)一的格式，包括分辨率、幀率等，以便輸入到編碼模塊中進行正確的編碼。

總體而言，視頻源預(yù)處理模塊的工作包括視頻解碼、定標(biāo)縮放、幀率轉(zhuǎn)換。視頻解碼可以從源數(shù)據(jù)中獲取視頻每一幀的亮度和色度數(shù)據(jù)；定標(biāo)縮放根據(jù)視頻源的分辨率和輸出目標(biāo)格式的分辨率對每一幀進行相應(yīng)的縮放；幀率轉(zhuǎn)換則將視頻源的幀率轉(zhuǎn)換為目標(biāo)格式的幀率。

3 視頻編碼

視頻編碼模塊是本系統(tǒng)的核心模塊，實現(xiàn)視頻數(shù)據(jù)的壓縮。為了更好適應(yīng)視頻編碼服務(wù)器的配置，系統(tǒng)將實現(xiàn)2套完整的編碼方案，方案一是采用GPU協(xié)處理的硬件編碼方案，二是由CPU直接處理的軟件編碼方案。程序在運行時會判斷硬件系統(tǒng)中是否有顯卡能支持編碼操作，如果有則采用方案一進行硬件編碼；如果沒有，則可以采用CPU進行直接軟件編碼。

硬件編碼方案利用CUDA視頻編碼模塊，將YUV420P或YUV422的視頻數(shù)據(jù)，利用顯卡硬編碼壓縮成數(shù)據(jù)流。NVIDIA提供了視頻編碼的開發(fā)套件，其中包括視頻編碼的加速應(yīng)用編程接口NVENC。由于利用GPU核中專用的編解碼模塊，NVENC能夠提供比一般利用CUDA cores或者系統(tǒng)CPU更快質(zhì)量更好，并且能耗更低的編碼服務(wù)，并且在編碼過程中，其他的CUDA核及系統(tǒng)CPU能夠繼續(xù)執(zhí)行其他進程，從而實現(xiàn)編碼的并行處理。避免服務(wù)器的CPU忙于編碼而無法響應(yīng)其他操作。 CUDA視頻編碼模塊的編碼步驟如圖2的流程圖所示?？傮w而言，程序先創(chuàng)建上下文環(huán)境，配置相關(guān)參數(shù)，分配內(nèi)存，然后一幀一幀圖像進行編碼，編碼結(jié)束后釋放內(nèi)存和編碼器環(huán)境。

為了優(yōu)化編碼器結(jié)構(gòu)，更好地滿足系統(tǒng)的功能需求，按上述步驟將相應(yīng)的函數(shù)進行進一步的封裝，形成以下幾個基本的應(yīng)用程序接口：初始化硬件編碼接口EncodeInit（ ）、分配輸入緩存區(qū)EncodeGetBuffer（ ）、硬編碼EncodeFrame（ ）、編碼結(jié)束清理相關(guān)資源EncodeExit（ ）等。

方案二的視頻軟件編碼使用軟編碼的方式將YUV420P或者YUV422視頻數(shù)據(jù)壓縮編碼。為了方便和硬件編碼方案進行對比分析，這里以領(lǐng)域內(nèi)常用的FFMPEG庫為例進行設(shè)計，使用FFMPEG提供的編碼接口進行壓縮編碼。FFMPEG主要提供三個模塊：encode/decode、muxer/demuxer和內(nèi)存操作。依次存放在庫libavcodec、libavformat、libavutil中[5]。其使用步驟包括初始編碼參數(shù)設(shè)置、分配輸入緩存區(qū)、軟編碼、編碼結(jié)束清理相關(guān)資源等。

4 實驗結(jié)果和分析

為了分析對比本文系統(tǒng)所采用的編碼方案的性能，本節(jié)將直接抓取服務(wù)器的屏幕輸出作為視頻源，這樣可以直接獲得視頻的直接原始數(shù)據(jù)，方便進行分析比較。

視頻的分辨率為1440×900；CPU型號為Intel Xeon? CPU E5-2684W v3@3.10Ghz；內(nèi)存為125.6GB；GPU采用NVIDIA的Quadro K620；操作系統(tǒng)為GENTOO 3.20.2； NVENC版本6.5；編碼方案為H.264編碼。編碼的配置如表1所示，在測試中軟件編碼和硬件編碼均采用同樣的配置。

測試分別針對靜止畫面和動態(tài)畫面進行對比，其中靜止畫面測試是讓服務(wù)器的屏幕輸出靜態(tài)圖像，對其屏幕數(shù)據(jù)按30幀每秒的幀率抓取視頻流再進行編碼；動態(tài)畫面測試是讓服務(wù)器播放一段視頻圖像，然后對其屏幕數(shù)據(jù)按30幀每秒的幀率抓取視頻流再進行編碼。編碼過程對內(nèi)存和CPU資源的占用情況如表2所示。表中硬編碼為采用GPU進行協(xié)處理的編碼方案；軟編碼為CPU直接編碼方案。表2的結(jié)果顯示，硬編碼方案在內(nèi)存占用和CPU資源占用方面都優(yōu)于軟編碼方案?？傮w而言，軟編碼方案對CPU資源占用在5%左右并不高，這是因為所選用的CPU功能較強，而且視頻源來自于屏幕數(shù)據(jù)，無需視頻解壓的預(yù)處理操作。盡管如此，不考慮系統(tǒng)調(diào)度等其他操作對CPU的占用，在此測試服務(wù)器中同時運行20個編碼程序顯然將造成CPU資源耗盡。因此對于編碼服務(wù)器而言，采用硬編碼方案將大大提高系統(tǒng)性能。

接下來分析系統(tǒng)的編碼效率。將編碼過程所用時間除以視頻流所有的幀數(shù)，得到編碼一幀數(shù)據(jù)的平均使用時間。結(jié)果如表3所示。對于靜止畫面，軟編碼方案耗時比硬編碼方案略低，這一方面是因為測試所用服務(wù)器處理能力足夠強大，其運算頻率高于GPU，另一方面ffmpeg調(diào)用的x264庫對H.264編碼過程采取了很多優(yōu)化措施，包括拋棄了很多消耗資源但不是特別能提高編碼質(zhì)量的特性，開啟多線程并行編碼等等；而對于動態(tài)畫面，硬編碼方案的速度明顯高于軟編碼，所用時間僅為軟編碼的20%-25%。在編碼壓縮率方面，表3也給出了最終的結(jié)果，硬編碼的結(jié)果都比軟編碼的結(jié)果好。

最后，對編碼的效果進行對比，主要的對比參數(shù)選擇峰值信噪比PSNR值。對比結(jié)果由表4給出。由于系統(tǒng)編碼模塊分別對亮度和色度進行處理，因此表4將亮度和色度分量的PSNR單獨列出。由表4可知，硬編碼和軟編碼的PSNR值差別不大，因此兩者的性能在PSNR評價指標(biāo)上可以認(rèn)為相同。這是因為兩者的編碼配置是相同的，都采用了表1的配置，因此得出了相同的編碼效果。但是結(jié)合表3的編碼壓縮率結(jié)果，測試結(jié)果顯示出硬編碼的在較高壓縮率的情況下獲得了與軟編碼相同的效果，因此具有更好的應(yīng)用價值。

綜上，采用GPU協(xié)處理的硬編碼方案比CPU軟編碼方案在較少的內(nèi)存和CPU資源占用條件下，以更快的速度實現(xiàn)了性能更好的編碼輸出。而如果要提高軟編碼器的性能，將使得編碼算法的計算復(fù)雜度更高，資源占用更多，處理速度更慢。

5 總結(jié)

本文針對視頻服務(wù)平臺的視頻編碼需求設(shè)計了一套高效的視頻編碼系統(tǒng)。利用GPU的并行運算能力，在編碼系統(tǒng)中將復(fù)雜的編碼操作分配在GPU中執(zhí)行，從而實現(xiàn)了更快速更高效的編碼效果。同時在軟件上配置了軟件編碼方案，使得視頻編碼服務(wù)器能靈活地進行軟硬件配置。因此，可以通過在板級增加顯卡數(shù)量，迅速提高系統(tǒng)的視頻處理吞吐量；也可在沒有顯卡或所有顯卡均占用的情況下直接由軟件實現(xiàn)編碼。

參考文獻：

[1] 樊曉平， 熊哲源， 陳志杰，等. 無線多媒體傳感器網(wǎng)絡(luò)視頻編碼研究[J]. 通信學(xué)報， 2011， 32（9）：137-146.

[2] 戴長江， 張尤賽. 基于圖形處理器的通用計算技術(shù)的研究[J]. 現(xiàn)代電子技術(shù)， 2013， 36（4）：157-161.

[3] 趙耀， 黃晗， 林春雨， 白慧慧. 新一代視頻編碼標(biāo)準(zhǔn)HEVC的關(guān)鍵技術(shù)[J]， 2014， 1（29）： 1-10.

[4] 張然， 劉佩林. 基于CUDA平臺的并行化實時視頻編碼[J]. 信息技術(shù)， 2011， 35（4）：14-18.

[5] 劉建敏， 楊斌. 嵌入式linux下基于ffmpeg的視頻硬件編解碼[J]， 單片機與嵌入式系統(tǒng)應(yīng)用， 2011（6）： 28-31.