袁三男, 王孟彬, 陶倩昀, 張艷秋
(上海電力大學(xué) 電子與信息工程學(xué)院, 上海 200090)
科學(xué)技術(shù)的進(jìn)步使人類(lèi)社會(huì)不斷走向高科技,視頻和音頻的應(yīng)用逐漸深入人們的生活,遍及社會(huì)的各個(gè)方面,從而導(dǎo)致了視音頻流量、占用空間以及所需的傳輸帶寬也越來(lái)越大[1]。這意味著對(duì)視音頻編碼的研究開(kāi)發(fā)已成為一個(gè)重要課題。
在云服務(wù)方面,研究人員針對(duì)視頻編碼發(fā)布了高效視頻編碼(High Efficiency Video Coding,HEVC)[2]新編碼標(biāo)準(zhǔn)。在云端,離線(xiàn)編碼通??梢越柚诖罅康挠?jì)算資源來(lái)保持較高的編碼效率。HEVC是在H.264/AVC的基礎(chǔ)上發(fā)展而來(lái),其視頻壓縮的編碼效率是H.264/AVC的2倍[3],但HEVC的編碼時(shí)間和所需的計(jì)算資源有所增加,因此編碼復(fù)雜度也進(jìn)一步提高[4]。究其原因是HEVC標(biāo)準(zhǔn)增加了新工具和新模式[5],導(dǎo)致編碼速度達(dá)不到要求,而且還增加了不必要的開(kāi)銷(xiāo)。值得慶幸的是,云端的并行化資源十分強(qiáng)大,如多核中央處理器(CPUs)和圖形處理器(GPUs)等。本文為了提高HEVC的編碼效率,對(duì)多核CPU及其對(duì)應(yīng)的GPU協(xié)同工作進(jìn)行了研究。
目前,異構(gòu)多處理平臺(tái)中應(yīng)用最多的架構(gòu)是CPU+GPU架構(gòu)。CPU和GPU的建造結(jié)構(gòu)、硬件特點(diǎn)互不相同,因此二者的數(shù)據(jù)處理能力和對(duì)應(yīng)的運(yùn)行任務(wù)也不相同。依據(jù)這一原則分配任務(wù),就可以充分利用CPU和GPU內(nèi)核不同的計(jì)算能力。
GPU的計(jì)算能力比CPU強(qiáng),數(shù)據(jù)傳輸帶寬更大,性能功耗比更高[6],因此一般利用GPU處理高并行計(jì)算任務(wù),利用CPU處理邏輯運(yùn)算和任務(wù)調(diào)度。此外,與CPU相比,GPU擁有的數(shù)據(jù)緩沖和控制單元數(shù)量較少,因此正常情況下GPU更適用于執(zhí)行密集型數(shù)據(jù)計(jì)算以及高數(shù)據(jù)并行的計(jì)算任務(wù)[7]。在視頻壓縮過(guò)程中,數(shù)據(jù)之間必然相互關(guān)聯(lián),也就是說(shuō)數(shù)據(jù)與數(shù)據(jù)之間存在著相關(guān)性。與串行視頻編碼框架相比,異構(gòu)多處理平臺(tái)的視頻編碼框架主要是通過(guò)CPU和GPU的高效率協(xié)作,實(shí)現(xiàn)最佳的視頻編碼效率。
無(wú)論是在時(shí)間還是空間上,相鄰塊皆存在著非常強(qiáng)的相關(guān)性。由于時(shí)間上相鄰塊存在強(qiáng)烈相關(guān)性,且運(yùn)動(dòng)估計(jì)(在相鄰幀中找到最佳預(yù)測(cè)塊并記錄相對(duì)運(yùn)動(dòng)向量)的預(yù)測(cè)塊來(lái)源于已編碼的視頻幀,與當(dāng)前視頻幀無(wú)關(guān),因此可以在GPU中實(shí)現(xiàn)運(yùn)動(dòng)估計(jì)的并行處理。但在空間上,對(duì)幀內(nèi)編碼時(shí)采用并行處理會(huì)破壞相鄰塊的相關(guān)性,導(dǎo)致編碼效率急劇下降,因此GPU不適用于并行處理空間相鄰塊。
相對(duì)于運(yùn)動(dòng)估計(jì)來(lái)說(shuō),變換和量化所占用的處理時(shí)間有限,并行處理對(duì)于加速編碼和減少計(jì)算時(shí)間的作用有限,熵編碼過(guò)程中不同編碼樹(shù)單元(Coding Tree Unit,CTU)之間互不依賴(lài)、相互獨(dú)立,但是熵編碼過(guò)程需要利用各種信息及指令,而GPU具有強(qiáng)大的計(jì)算能力,但不適合處理各種判斷指令,所以在GPU上不適合熵編碼及變換和量化的并行處理。圖1為基于異構(gòu)多處理平臺(tái)的視頻編碼框架。
圖1 基于異構(gòu)多處理平臺(tái)的視頻編碼框架
綜上所述,在異構(gòu)多處理平臺(tái)的視頻編碼框架中,GPU僅執(zhí)行運(yùn)動(dòng)估計(jì)過(guò)程,其他過(guò)程如變換與量化、幀內(nèi)預(yù)測(cè)、熵編碼等,都在CPU中處理和執(zhí)行。
本文將編碼器分成大小可變塊運(yùn)動(dòng)估計(jì)(Motion Estimation with Variable Block Size,VBSME)、模式?jīng)Q策、編碼與重建、去塊濾波、分?jǐn)?shù)像素插值和熵編碼6個(gè)部分。其中VBSME是編碼器中最耗時(shí)的模塊。在本文設(shè)計(jì)的異構(gòu)處理器并行編碼框架中,VBSME、去塊濾波和分?jǐn)?shù)像素插值模塊將由GPU處理,其他剩余模塊在多核CPU中處理。上述并行編碼框架如圖2所示。
圖2 異構(gòu)處理器并行編碼框架
本文提出的編碼框架有以下兩級(jí)并行。
(1)第1級(jí)是CPU和GPU的并行。將讀到的一幀圖像復(fù)制到GPU中,然后進(jìn)行插值同步判斷,由插值同步單元負(fù)責(zé)決定GPU中是執(zhí)行運(yùn)動(dòng)估計(jì)還是執(zhí)行插值。若已經(jīng)是插值同步,則GPU執(zhí)行運(yùn)動(dòng)估計(jì),否則,GPU執(zhí)行插值。
(2)第2級(jí)是多核CPU中的多流水線(xiàn)并行[8]。運(yùn)動(dòng)估計(jì)完成后,在多核CPU中創(chuàng)建多條流水線(xiàn),通過(guò)波前并行處理(Wavefront Parrallel Processing,WPP)同步單元判斷是否由WPP同步來(lái)做下一步的決定,即處理模式?jīng)Q策、編碼、重建或等待所有的CTU完成。
在第1級(jí)并行中,插值同步單元保證了第1級(jí)的并行化執(zhí)行。在第2級(jí)并行中,WPP同步單元負(fù)責(zé)多核CPU中的多條流水線(xiàn)同步問(wèn)題,保證了第2級(jí)的并行化執(zhí)行。多核CPU的多條流水線(xiàn)并行化是基于文獻(xiàn)[8]提出的WPP并行策略。在CPU創(chuàng)建的多條流水線(xiàn)中用單條流水線(xiàn)執(zhí)行熵編碼。在波前并行中,每幀圖像被劃分為CTU行,在同一CTU行的所有CTU將作為同一流水線(xiàn)處理。只有當(dāng)上一行CTU被編碼和重建時(shí),來(lái)自不同CTU行的CTU才能夠被同時(shí)處理。這個(gè)條件由WPP同步單元保證。
在視頻編碼中,運(yùn)動(dòng)估計(jì)是最重要的部分,運(yùn)動(dòng)估計(jì)的好壞將直接影響到編碼效率。本文將第1級(jí)并行中的運(yùn)動(dòng)估計(jì)最小塊限制為8×8像素,在此條件下,一個(gè)CTU能分為64個(gè)8×8像素塊。GPU中基于運(yùn)動(dòng)估計(jì)的算法采用了文獻(xiàn)[9]的思想,利用全搜索算法和1/4像素精度插值。該算法分為以下4個(gè)部分。
(1)8×8像素塊的絕對(duì)差值和(Sum of Absolute Difference,SAD)計(jì)算。運(yùn)動(dòng)估計(jì)搜索范圍設(shè)定為32×32像素,因此對(duì)于每個(gè)8×8像素塊有1 024個(gè)候選運(yùn)動(dòng)向量。
(2)其他尺寸塊的SAD計(jì)算。算出8×8像素塊的SAD后,只需將相應(yīng)的8×8像素塊的SAD相加即可獲得其他尺寸的SAD[10]。例如,8×16像素或16×8像素塊的SAD可以由其對(duì)應(yīng)的兩個(gè)8×8像素塊的SAD相加得到。更大的SAD可按此方法依次生成。
(3)最佳整像素運(yùn)動(dòng)矢量(Interger pixel Motion Vector,IMV)選擇。最小SAD對(duì)應(yīng)的IMV就是最佳IMV,最小的SAD需要通過(guò)比較判決來(lái)選擇。采用1個(gè)線(xiàn)程處理1 024個(gè)SAD,共有256個(gè)線(xiàn)程,每個(gè)線(xiàn)程分配4個(gè)SAD,再給256個(gè)SAD值分配128線(xiàn)程,每個(gè)線(xiàn)程比較兩個(gè)SAD。依次迭代計(jì)算8次,最后得出最小的SAD及其對(duì)應(yīng)的運(yùn)動(dòng)向量(Motion Vector,MV)。
(4)分?jǐn)?shù)像素插值及運(yùn)動(dòng)估計(jì)。在插值運(yùn)算后每個(gè)整數(shù)像素周?chē)?4個(gè)分?jǐn)?shù)像素,因此可以對(duì)整數(shù)像素周?chē)?4個(gè)分?jǐn)?shù)像素進(jìn)行運(yùn)動(dòng)估計(jì)。
GPU經(jīng)過(guò)以上過(guò)程處理完一幀視頻,將每種塊的最小SAD及其對(duì)應(yīng)MV傳送至CPU內(nèi)存,CPU利用WPP單元進(jìn)行并行處理,找出最優(yōu)良的CTU劃分模式。
在WPP單元的模式?jīng)Q策中,為了使CPU和GPU的工作量達(dá)到平衡,并加速模式?jīng)Q策,本文提出了以下快速預(yù)測(cè)單元(Prediction Units,PU)劃分方案[11-13]。
步驟1 采用SKIP檢測(cè)和CBF_fast檢測(cè)算法。若SKIP不滿(mǎn)足,則進(jìn)行CBF_fast檢測(cè),并且當(dāng)CBF_fast的條件也不滿(mǎn)足,則跳轉(zhuǎn)到步驟2;否則將編碼單元(Code Units,CU)深度設(shè)置為數(shù)字4并跳轉(zhuǎn)到步驟5。
步驟2 快速CU劃分。判斷4個(gè)N×N像素PU的MV與2N×2N像素PU的MV之間的最大差值是否小于等于6。如果是,那么CU以2N×2N的大小編碼,并將其深度賦值為4,然后跳到步驟5;否則,執(zhí)行步驟3。
步驟3 用2N×2N像素的PU和其對(duì)應(yīng)的MV進(jìn)行運(yùn)動(dòng)補(bǔ)償,并計(jì)算殘差塊的紋理圖案。
步驟4 計(jì)算率失真代價(jià),對(duì)比并選擇最小的一個(gè)值。
步驟5 檢查CU深度是否為4,所有的4個(gè)N×N塊是否已經(jīng)處理完。如果條件為真,則處理編碼重建;否則,將CU劃分為4個(gè)子CU或處理下一個(gè)CU,并回到步驟1。
在所有CPU流水線(xiàn)完成一幀圖像的重建后,將重建圖像復(fù)制到GPU。CPU主流水線(xiàn)(在OpenMP[14]中主線(xiàn)程的編號(hào)為0)控制GPU按照順序異步執(zhí)行去塊濾波和插值。CPU熵編碼的執(zhí)行和GPU主流水線(xiàn)對(duì)插值和邊界填充任務(wù)的執(zhí)行是同時(shí)進(jìn)行的。在插值同步單元保證下最后重建幀的邊界擴(kuò)展分?jǐn)?shù)像素圖像準(zhǔn)備就緒后,CPU主流水線(xiàn)對(duì)當(dāng)前幀啟動(dòng)新的VBSME任務(wù)。
本文基于實(shí)用性的開(kāi)源編碼器X265[15-16],支持H.265/HEVC主要檔次的大部分功能,用C語(yǔ)言實(shí)現(xiàn),硬件采用HP Z620工作站,其配置為8核CPU,工作頻率2.6 GHz,NVIDIA Tesla C2050 GPU,操作系統(tǒng)為64位Windows7旗艦版。
用Proposed表示本文所設(shè)計(jì)的并行編碼器,利用HM10.0,X265和Proposed分別對(duì)BasketballDrive視頻序列和Cactus視頻序列進(jìn)行編碼。3種編碼器的壓縮性能和編碼速度分別如表1和表2所示。其中,采用峰值信噪比(Peak Signal to Noise Ratio,PSNR)作為壓縮性能的評(píng)價(jià)指標(biāo)。采用8線(xiàn)程WPP,所有編碼器的主要配置為:編碼測(cè)試序列前50幀,一個(gè)I幀和49個(gè)P幀;關(guān)閉近似消息傳遞功能;關(guān)閉樣本自適應(yīng)偏移(Sample Adaptive Offset,SAO)功能;搜索范圍為32×32像素;HM參考模型軟件使用TZ快速搜索,其他編碼器使用全搜索;關(guān)閉碼率控制功能,6個(gè)量化參數(shù)(Quantization Parameter,QP)分別為22,24,26,28,31,34;測(cè)試序列選為BasketballDrive_1 920×1 080_50.yuv和Cactus_1 920×1 080_50.yuv。由于高清視頻尺寸為1 920×1 080,不可劃分為整數(shù)個(gè)CTU,為此在GPU中對(duì)視頻序列填充了8行(1 920×1 088),使輸入和預(yù)測(cè)視頻幀可以劃分為整數(shù)個(gè)CTU。
由表1數(shù)據(jù)可以看出,Proposed編碼BasketballDrive視頻序列的速度最高可達(dá)26.31幀/s,相對(duì)于HM10.0的0.031幀/s,加速比為848,PSNR為0.620 dB(QP=34);相對(duì)于X265的2.41幀/s,加速比為11,PSNR為0.133 dB(QP=34)。
表1 3種編碼器對(duì)BasketballDrive序列的編碼實(shí)驗(yàn)結(jié)果
表2中數(shù)據(jù)表明,Proposed編碼Cactus視頻序列的速度可達(dá)26.32幀/s,相對(duì)于HM10.0的0.032幀/s,加速比為822,PSNR為0.798 dB(QP=34);相對(duì)于X265的2.43幀/s,加速比為11,PSNR為0.221 dB(QP=34)。
表2 3種編碼器對(duì)Cactus序列的編碼實(shí)驗(yàn)結(jié)果
采用調(diào)用函數(shù)計(jì)算得出,本文所設(shè)計(jì)的并行編碼器編碼BasketballDrive序列的總體速度相對(duì)HM10.0編碼器加速比約為790,PSNR約為0.700 dB;編碼Cactus序列的總體速度相對(duì)HM10.0加速比約為790,PSNR約為0.840 dB。
本文提出的編碼器雖然率失真性能有一定的損失,但是其最快的編碼速度相對(duì)于其他編碼器有極大的提高,已接近于實(shí)時(shí)編碼,有較好的應(yīng)用前景。
為了達(dá)到HEVC高清視頻實(shí)時(shí)編碼這一目標(biāo),本文采用異構(gòu)多核CPU+GPU多處理平臺(tái),利用該平臺(tái)的并行加速性能來(lái)加速HEVC編碼。根據(jù)CPU和GPU的不同結(jié)構(gòu)和數(shù)據(jù)處理能力,對(duì)二者的性能進(jìn)行了剖析,并按照其不同的特點(diǎn),設(shè)計(jì)了相應(yīng)的算法以實(shí)現(xiàn)異構(gòu)多處理平臺(tái)的并行視頻編碼,加快了對(duì)高清視頻的編碼速度,使其極大地接近實(shí)時(shí)編碼。實(shí)驗(yàn)結(jié)果表明,該編碼器對(duì)高清視頻的編碼速度最高可達(dá)26.31幀/s,加速比高達(dá)848,具有良好的應(yīng)用前景。