張豐源+黃全明

摘 要： H.264/AVC是一種由ITU?T視頻編碼專家組合ISO/IEC JTC1動(dòng)態(tài)圖像專家組聯(lián)合提出的高度壓縮視頻編碼器標(biāo)準(zhǔn)。然而H.264/AVC編碼器較高的運(yùn)算復(fù)雜度提高了多屏共享系統(tǒng)的延遲時(shí)間。H.264/AVC 由多種開源的實(shí)現(xiàn)，其中X264因簡(jiǎn)單高效而得到廣泛的應(yīng)用。在此對(duì)多頻共享系統(tǒng)的關(guān)鍵技術(shù)進(jìn)行實(shí)現(xiàn)，分析X264編碼器提供的運(yùn)動(dòng)估計(jì)算法并且提出一種優(yōu)化的算法。實(shí)驗(yàn)表明，新的算法提高了編碼的速度、減少了系統(tǒng)延遲時(shí)間，同時(shí)視頻質(zhì)量幾乎沒有產(chǎn)生損失。

關(guān)鍵字： 多頻共享系統(tǒng)； H.264/AVC； 運(yùn)動(dòng)估計(jì)； 延遲時(shí)間

中圖分類號(hào)： TN919?34 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2014）16?0104?04

Multi?screen sharing system based on H.264/AVC encoder

ZHANG Feng?yuan， HUANG Quan?ming

（College of Information Science and Engineering， Ocean University of China， Qingdao 266100， China）

Abstract： H.264/AVC is a high compression video encoder standard proposed by the ITU?T Video Coding Experts Group （VCEG） and ISO/IEC JTC1 Moving Picture Experts Group （MPEG）. However， the higher computational complexity of H.264/AVC encoder increased the delay time of multi?screen sharing system. The motion estimation algorithms provided in X264 are analyzed in this paper. An optimized algorithm is proposed， which can reduce the unnecessary computation a lot. The multi?screen sharing system with the improved encoder was designed and implemented. Experimental results show that the proposed method has increased the encoding speed and decreased the delay time significantly， while little loss in quality incurred if any.

Keywords： multi?screen sharing system； H.264/AVC； motion estimation； delay time

0 引 言

隨著科技的發(fā)展，各種智能化的家電不斷進(jìn)入千家萬戶，數(shù)字家庭的概念日漸深入人心。作為數(shù)字家庭的具體應(yīng)用之一，多屏共享系統(tǒng)旨在隨時(shí)隨地支持用戶使用各種設(shè)備來訪問在不同設(shè)備上的視頻、圖片等各種資源，它給用戶的PC，TV，移動(dòng)手持設(shè)備帶來的是無縫的連接和無縫的播放感受。Android操作系統(tǒng)是一種基于Linux的開放源代碼操作系統(tǒng)，自從問世以來便因其自由開放的特性以及較高的效率受到用戶和廣大廠商的一致追捧，目前市面上絕大多數(shù)的智能手機(jī)、智能電視、平板電腦均采用Android作為操作系統(tǒng)。本文將采用Android系統(tǒng)作為研究對(duì)象，在其基礎(chǔ)上完成對(duì)多屏共享系統(tǒng)的設(shè)計(jì)和搭建。

H.264/AVC[1]是國(guó)際標(biāo)準(zhǔn)化組織（ISO）和國(guó)際電信聯(lián)盟（ITU）共同提出的繼MPEG?4之后的新一代數(shù)字視頻壓縮格式。與其他現(xiàn)有視頻編碼標(biāo)準(zhǔn)相比，H.264最大的特點(diǎn)在于具有很高的數(shù)據(jù)壓縮比率和高質(zhì)量的視頻畫面，但這些都是以增加算法復(fù)雜性為代價(jià)而獲得的。在H.264算法中運(yùn)動(dòng)估計(jì)是最重要且最耗時(shí)的一部分，在編碼器中運(yùn)動(dòng)估計(jì)過程的耗時(shí)平均達(dá)到總耗時(shí)[2]的74.29%。H264/AVC的運(yùn)動(dòng)估計(jì)采用塊匹配（MB）的算法，目前研究人員已經(jīng)提出了多種的快速塊匹配算法，包括三步法（TSS）[3]、菱形搜索（DS）[4]、六邊形搜索（HEX）[5]和非對(duì)稱十字形多層次六邊形格點(diǎn)搜索（UMH）[6]。本文選擇X264作為測(cè)試編碼器，分析了其中的4種運(yùn)動(dòng)估計(jì)算法并對(duì)其中的六邊形搜索算法（HEX）進(jìn)行了改進(jìn)，通過實(shí)驗(yàn)與未改進(jìn)算法對(duì)比，在不影響視頻質(zhì)量的基礎(chǔ)上降低視頻編碼的算法復(fù)雜度，達(dá)到了降低時(shí)延、優(yōu)化系統(tǒng)資源的目的。

1 系統(tǒng)總體設(shè)計(jì)

本系統(tǒng)具體分為服務(wù)器端和客戶端，為了提高系統(tǒng)功能的擴(kuò)展性和可移植性，服務(wù)器端按功能劃分成4個(gè)模塊：請(qǐng)求響應(yīng)模塊、屏幕截取模塊、視頻編碼模塊、網(wǎng)絡(luò)傳輸模塊，客戶端同樣分為4個(gè)模塊：客戶請(qǐng)求模塊、數(shù)據(jù)接收模塊、視頻解碼模塊、GUI顯示模塊。圖1描述了系統(tǒng)的模塊劃分和各模塊之間的交流流程。

圖1 系統(tǒng)模塊劃分

在服務(wù)器端中，請(qǐng)求響應(yīng)模塊負(fù)責(zé)接收客戶端的數(shù)據(jù)請(qǐng)求，然后從設(shè)備文件中讀取屏幕參數(shù)以實(shí)現(xiàn)對(duì)編碼器的初始化、緩存分配等工作；屏幕截取模塊負(fù)責(zé)截取當(dāng)前屏幕顯示的圖像并將其轉(zhuǎn)化為視屏編碼所需要的格式；視屏編碼模塊負(fù)責(zé)對(duì)從屏幕截取模塊所獲得的圖像進(jìn)行壓縮、編碼等工作，生成提供給網(wǎng)絡(luò)傳輸?shù)囊曨l碼流；網(wǎng)絡(luò)傳輸模塊負(fù)責(zé)對(duì)視頻編碼模塊所生成的碼流打包、封裝然后傳遞給客戶端。

在客戶端中，客戶請(qǐng)求模塊負(fù)責(zé)將數(shù)據(jù)請(qǐng)求發(fā)送給服務(wù)器，同時(shí)完成解碼器的初始化、緩存分配等任務(wù)；數(shù)據(jù)接收模塊負(fù)責(zé)從服務(wù)器獲得經(jīng)過打包、封裝的視頻數(shù)據(jù)包，然后從中提取出原始的視頻碼流數(shù)據(jù)；視頻解碼模塊負(fù)責(zé)對(duì)視頻碼流進(jìn)行解碼、重構(gòu)，生成可以直接顯示的RGB圖像；GUI顯示模塊負(fù)責(zé)將解碼獲得的RGB圖像顯示給用戶。

2 系統(tǒng)關(guān)鍵技術(shù)

2.1 軟件開發(fā)環(huán)境建立

Android系統(tǒng)上的應(yīng)用程序使用Java語言編寫，為了提高程序的執(zhí)行效率，服務(wù)器端主要代碼全部采用C語言編寫，然后使用Android提供的NDK工具將其編譯成鏈接庫(kù)加載至Android工程目錄中供Java程序調(diào)用。客戶端在PC平臺(tái)上進(jìn)行開發(fā)，選擇Qt做為開發(fā)框架。Qt是一套優(yōu)秀的UI應(yīng)用程序框架，與其他開發(fā)工具相比Qt具有優(yōu)良的跨平臺(tái)特性、面向?qū)ο蟆⒇S富的API、支持 2D/3D 圖形渲染、支持XML等優(yōu)勢(shì)。

2.2 屏幕截取

Framebuffer通常譯作幀緩存，它是出現(xiàn)在Linux 2.2.xx內(nèi)核中的一種驅(qū)動(dòng)程序接口。作為圖形基礎(chǔ)設(shè)施，這種接口將具體的顯示設(shè)備抽象為幀緩沖區(qū)，用戶可以將它看成是顯存的一個(gè)映像而不必關(guān)心物理顯存的位置、換頁(yè)機(jī)制等硬件層的具體細(xì)節(jié)， 這些都是由Framebuffer 設(shè)備驅(qū)動(dòng)來完成的。 只要將它映射到進(jìn)程地址空間里就可以直接進(jìn)行讀/寫操作，讀操作可以獲得到當(dāng)前設(shè)備屏幕的顯示而寫操作可以立即反應(yīng)在屏幕上[7]。

Android系統(tǒng)使用的是修改過的Linux內(nèi)核，其Framebuffer驅(qū)動(dòng)程序原理和Linux系統(tǒng)是一樣的。Linux系統(tǒng)中它的主設(shè)備號(hào)為29，Linux系統(tǒng)最多可支持32個(gè)顯卡，因此它的次設(shè)備號(hào)為0～31，其對(duì)應(yīng)的設(shè)備文件名為/dev/fb0～/dev/fb31。在Android系統(tǒng)中Framebuffer的設(shè)備名稱與Linux系統(tǒng)中不同，一般為“/dev/graphics/fb0”和“/dev/graphics/fb1”。

2.3 視頻編碼實(shí)現(xiàn)

FFmpeg[8]是一個(gè)開源免費(fèi)跨平臺(tái)的視頻和音頻流方案，本文使用FFmpeg作為編碼的框架。在Android系統(tǒng)中使用FFmpeg調(diào)用X264編碼器，首先需要對(duì)修改后的X264源代碼交叉編譯生成靜態(tài)鏈接庫(kù)libx264.a，然后交叉編譯FFmpeg時(shí)在選項(xiàng)中加上libx264并將鏈接庫(kù)提供給編譯器，最終生成libffmpeg.so文件供程序調(diào)用。

具體編碼流程如下：

（1） 調(diào)用av_register_all（）函數(shù)注冊(cè)所有容器格式和編碼器。

（2） 調(diào)用avcodec_find_decoder（）和avcodec_open（）找到并打開x264編碼器。

（3） 調(diào)用自定義函數(shù)get_frame_info（）從Framebuffer中獲取屏幕分辨率等參數(shù)，跟據(jù)這些參數(shù)設(shè)置編碼器碼率、幀分辨率等參數(shù)。

（4） 調(diào)用自定義函數(shù) get_frame_data（）從Framebuffer中獲得當(dāng)前屏幕截圖，將圖像數(shù)據(jù)由RGB24格式轉(zhuǎn)化為YUV420格式。

（5） 調(diào)用avcodec_encode_video2（）函數(shù)對(duì)YUV幀進(jìn)行編碼，將所得數(shù)據(jù)存放在結(jié)構(gòu)體AVPacket中供網(wǎng)絡(luò)發(fā)送模塊調(diào)用。

（6） 等待客戶端下一次請(qǐng)求，然后重復(fù)步驟（4）、步驟（5）。

3 H.264運(yùn)動(dòng)估計(jì)算法的優(yōu)化

3.1 H.264運(yùn)動(dòng)估計(jì)算法簡(jiǎn)介

塊匹配法是目前常用的運(yùn)動(dòng)估計(jì)算法，X264中提供了4種塊匹配算法：全搜索算法（ESA）、菱形搜索算法（DIA）、六邊形搜索算法（HEX）、非對(duì)稱十字形多層次六邊形格點(diǎn)搜索算法（UMH）。

全搜索算法類似于數(shù)學(xué)中的窮舉法，其精度最高但是計(jì)算量太大不適合實(shí)時(shí)編碼。UMH算法是H.264官方算法模型JM所采用的運(yùn)動(dòng)估計(jì)算法，是目前搜索效果最好的快速搜索算法，但與菱形算法、六邊形算法比起來它的計(jì)算復(fù)雜度較高，也難以滿足實(shí)時(shí)編碼的要求。 菱形算法使用的模板搜索步長(zhǎng)較小，當(dāng)塊的運(yùn)動(dòng)比較劇烈、運(yùn)動(dòng)向量大時(shí)菱形模板需要多次移位計(jì)算才能得到運(yùn)動(dòng)向量的估計(jì)值。

六邊形算法使用的模板如圖2、圖3所示。

圖2 六邊形搜索模板

圖3 正方形細(xì)化模板

六邊形算法搜索過程如下：

步驟1：利用空間的相關(guān)性預(yù)測(cè)搜索起點(diǎn)，計(jì)算當(dāng)前宏塊左、上、右上鄰塊的運(yùn)動(dòng)矢量（mv1，mv2，mv3）的中間值mv0，將以上4個(gè)運(yùn)動(dòng)矢量和原點(diǎn)運(yùn)動(dòng)矢量mv4=（0，0）作為候選點(diǎn)分別計(jì)算它們的誤差代價(jià)函數(shù)cost，選擇其中最小值記作bpred_cost，bpred_cost所在點(diǎn)記為pmv。

步驟2：將步驟1所的pmv轉(zhuǎn)化為整像素并作為六邊形的中心點(diǎn)，計(jì)算圖2中中心點(diǎn)以及六邊形的6個(gè)頂點(diǎn)的誤差代價(jià)函數(shù)cost，若cost值最小的點(diǎn)中心點(diǎn)則轉(zhuǎn)到步驟4，否則轉(zhuǎn)到步驟3。

步驟3：將cost值最小點(diǎn)為中心做出新六邊形（見圖2中空心點(diǎn)），計(jì)算多出來的3個(gè)點(diǎn)的誤差代價(jià)函數(shù)并與中心點(diǎn)比較，若此cost值最小點(diǎn)為中心點(diǎn)則轉(zhuǎn)到步驟4，否則重復(fù)執(zhí)行步驟3。

步驟4：將上述步驟中得到cost值最小點(diǎn)作為中心進(jìn)行正方形細(xì)化，計(jì)算其周圍8個(gè)點(diǎn)（如圖3所示）的cost值并與中心點(diǎn)比較，選擇其中最小值計(jì)作b_cost，b_cost所在點(diǎn)記為bmv。

步驟5：比較b_cost與bpred_cost的大小，若b_cost小于bpred_cost則采用搜索值bmv作為當(dāng)前宏塊的運(yùn)動(dòng)矢量，否則采用預(yù)測(cè)值pmv。結(jié)束整像素搜索，開始[12]和[14]像素的搜索。

3.2 六邊形搜索算法的改進(jìn)

由上一節(jié)的分析可以看出，擁有較大運(yùn)動(dòng)矢量的塊可以使用六邊形模板快速定位到其運(yùn)動(dòng)矢量的周圍，然后再用正方形進(jìn)行細(xì)化得到準(zhǔn)確的矢量。統(tǒng)計(jì)試驗(yàn)表明運(yùn)動(dòng)矢量具有中心偏置性和相關(guān)性，對(duì)于運(yùn)動(dòng)緩慢的視頻序列，最佳運(yùn)動(dòng)矢量[9]在3×3區(qū)域內(nèi)占90%左右，即使運(yùn)動(dòng)劇烈的視頻序列football[9]分布在3×3區(qū)域內(nèi)的仍有72%，因此過早的使用六邊形模板帶來了許多不必要的運(yùn)算。為了解決這一問題，本文結(jié)合菱形搜索算法的特點(diǎn)并引入提前終止策略對(duì)六邊形搜索算法予以改進(jìn)，具體方案如下：

使用六邊形模板搜索之前在搜素起點(diǎn)先使用正方形模板搜索一次，模板如圖3所示，分別計(jì)算正方形形中心點(diǎn)和周圍8個(gè)點(diǎn)的誤差代價(jià)cost，將上述9個(gè)點(diǎn)中cost值最小點(diǎn)記為bmv，bmv點(diǎn)對(duì)應(yīng)cost記為bcost，比較bcost與預(yù)測(cè)最佳誤差代價(jià)bpred_cost，若bcost小于bpred_cost則整像素搜索結(jié)束，否則以bmv為搜索起點(diǎn)開始六邊形搜索。當(dāng)宏塊靜止或運(yùn)動(dòng)緩慢時(shí)，其運(yùn)動(dòng)矢量分布在搜索起點(diǎn)周圍區(qū)域的概率較大，使用改進(jìn)前的六邊形的搜索算法需要計(jì)算15個(gè)點(diǎn)的誤差代價(jià)而改進(jìn)后只需要計(jì)算9個(gè)點(diǎn)，效率得到了大大的提高。

4 實(shí)驗(yàn)與分析

首先通過實(shí)驗(yàn)對(duì)改進(jìn)后的六邊形搜索算法和原來的4種搜索進(jìn)行比較。分別取運(yùn)動(dòng)比較緩慢的cif序列akiyo和運(yùn)動(dòng)較為劇烈的foreman經(jīng)行編碼測(cè)試，選擇峰值信噪比PSNR做為衡量視頻質(zhì)量的客觀參數(shù)，PSNR值越大說明視頻質(zhì)量越高。實(shí)驗(yàn)選擇X86平臺(tái)，CPU為Intel（R）Core（TM）i3 M390，RAM大小為2 GB，操作系統(tǒng)為Ubuntu 11.0。對(duì)每個(gè)序列使用改進(jìn)后的算法和原算法分別進(jìn)行100次編碼測(cè)試，取其平均值記錄在表1、表2中。

表1 “akiyo”的編碼表現(xiàn)

表2 “foreman”的編碼表現(xiàn)

由以上兩組測(cè)試數(shù)據(jù)可以看出：DS算法擁有最快的速度然而其視頻質(zhì)量下降較大；TESA和UMH表現(xiàn)出了最好的圖像質(zhì)量但是它們的速度較慢；與HEX算法相比優(yōu)化后的OHEX算法在兩次實(shí)驗(yàn)中將速度分別提升了12.53%和8.56%，其圖像質(zhì)量損失幾乎可以忽略。

對(duì)于用戶來講，多屏共享系統(tǒng)最直觀也是最重要的參數(shù)就是視頻的延遲時(shí)間。其中視頻的延遲時(shí)間是指從服務(wù)器端開始對(duì)設(shè)備的屏幕截圖到客戶端最終完成對(duì)這一幀的解碼并將其顯示的時(shí)間。為了評(píng)估編碼器的優(yōu)化對(duì)延遲時(shí)間的影響，使用原編碼器和改進(jìn)后的編碼器進(jìn)行比較，實(shí)驗(yàn)場(chǎng)景如圖4所示。

圖4 實(shí)驗(yàn)場(chǎng)景

測(cè)試環(huán)境服務(wù)器端CPU為Nvidia Tegra3 1.3 GHz 處理器， RAM為2 GB，操作系統(tǒng)為Android 4.1.1，屏幕分辨率為1 280×720?？蛻舳薈PU為Intel（R）Core（TM）i3 M390 2.67 GHz，RAM為2 GB，操作系統(tǒng)為Ubuntu 11.0。實(shí)驗(yàn)在局域網(wǎng)中進(jìn)行，編碼器的碼率設(shè)為800 Kb/s。結(jié)果如表3所示。

表3 延遲時(shí)間測(cè)試

表3中系統(tǒng)的最大延遲時(shí)間被縮短了13.77%，平均延遲時(shí)間被縮短了7.65%。盡管延遲時(shí)間最主要是由視頻編碼和網(wǎng)絡(luò)傳輸所產(chǎn)生，本文所提出的算法改進(jìn)還是在相當(dāng)可觀的范圍內(nèi)減小了它。

5 結(jié) 語

本文提出了一種優(yōu)化的H.264運(yùn)動(dòng)估計(jì)算法，并通過實(shí)驗(yàn)證明了新的算法可以平均節(jié)約10%的編碼時(shí)間與此同時(shí)幾乎不產(chǎn)生圖像質(zhì)量的下降。另外本文還設(shè)計(jì)并實(shí)現(xiàn)了一種使用改進(jìn)后H.264算法的運(yùn)動(dòng)估計(jì)算法的多屏共享系統(tǒng)。這一研究成果可以用于智能電視、智能手機(jī)、平板電腦等消費(fèi)類電子產(chǎn)品的應(yīng)用開發(fā)，并極大程度的改善用戶的娛樂體驗(yàn)。

參考文獻(xiàn)

[1] ITU. H.264 standard [EB/OL]. [2007?06?26]. http：//bbs.chinavideo.org/.

[2] CHEN T C， CHIEN S Y. Analysis and architecture design of an HDTV720p 30 frames/s H.264/AVC encoder [J]. IEEE Transactions on Circuits and Systems for Video Technology， 2006， 16（6）： 673?688.

[3] KOGA T， IINUMA K， HIRANO A， et al. Motion compensated interframe coding for video conferencing [C]// Proceedings of National Telecommunications Conference. [S.l.]： NTC， 1981： 1?5.

[4] ZHU S， MA K K. A new diamond search algorithm for fast block?matching motion estimation [J]. IEEE Transaction on Image Process， 2000， 9（2）： 287?290.

[5] ZHU C， LIN X， CHAU L P. Hexagon?based search pattern for fast block motion estimation [J]. IEEE Transactions on Circuits and System for Video Technology， 2002， 12（5）： 349?355.

[6] XU X， HE Y. Improvements on fast motion estimation strategy for H.264/AVC [J]. IEEE Transaction on Circuits and System for Video Technology， 2008， 18（3）： 285?293.

[7] Anon. Framebuffer HOW TO [EB/OL]. [2010?08?05]. http：//www.tldp.org/HOWTO/Framebuffer?HOWTO.

[8] FfmpegEngineering Group. FFmpeg development mahual [EB/OL]. [2010?09?28]. http：//www.ffmpeg.com.cn/index.php.

[9] 魏星，蔣建國(guó)，齊美彬，等.基于預(yù)測(cè)的自適應(yīng)運(yùn)動(dòng)估計(jì)算法[J].中國(guó)圖象圖形學(xué)報(bào)，2005（7）：873?877.

[10] CAI J， WU Y. Spatial characteristic based rate control initialization method for conversational video communication of H.264/AVC using linear prediction [J]. Journal of Multimedia， 2013， 8（5）： 489?495.

3.2 六邊形搜索算法的改進(jìn)

由上一節(jié)的分析可以看出，擁有較大運(yùn)動(dòng)矢量的塊可以使用六邊形模板快速定位到其運(yùn)動(dòng)矢量的周圍，然后再用正方形進(jìn)行細(xì)化得到準(zhǔn)確的矢量。統(tǒng)計(jì)試驗(yàn)表明運(yùn)動(dòng)矢量具有中心偏置性和相關(guān)性，對(duì)于運(yùn)動(dòng)緩慢的視頻序列，最佳運(yùn)動(dòng)矢量[9]在3×3區(qū)域內(nèi)占90%左右，即使運(yùn)動(dòng)劇烈的視頻序列football[9]分布在3×3區(qū)域內(nèi)的仍有72%，因此過早的使用六邊形模板帶來了許多不必要的運(yùn)算。為了解決這一問題，本文結(jié)合菱形搜索算法的特點(diǎn)并引入提前終止策略對(duì)六邊形搜索算法予以改進(jìn)，具體方案如下：

使用六邊形模板搜索之前在搜素起點(diǎn)先使用正方形模板搜索一次，模板如圖3所示，分別計(jì)算正方形形中心點(diǎn)和周圍8個(gè)點(diǎn)的誤差代價(jià)cost，將上述9個(gè)點(diǎn)中cost值最小點(diǎn)記為bmv，bmv點(diǎn)對(duì)應(yīng)cost記為bcost，比較bcost與預(yù)測(cè)最佳誤差代價(jià)bpred_cost，若bcost小于bpred_cost則整像素搜索結(jié)束，否則以bmv為搜索起點(diǎn)開始六邊形搜索。當(dāng)宏塊靜止或運(yùn)動(dòng)緩慢時(shí)，其運(yùn)動(dòng)矢量分布在搜索起點(diǎn)周圍區(qū)域的概率較大，使用改進(jìn)前的六邊形的搜索算法需要計(jì)算15個(gè)點(diǎn)的誤差代價(jià)而改進(jìn)后只需要計(jì)算9個(gè)點(diǎn)，效率得到了大大的提高。

4 實(shí)驗(yàn)與分析

首先通過實(shí)驗(yàn)對(duì)改進(jìn)后的六邊形搜索算法和原來的4種搜索進(jìn)行比較。分別取運(yùn)動(dòng)比較緩慢的cif序列akiyo和運(yùn)動(dòng)較為劇烈的foreman經(jīng)行編碼測(cè)試，選擇峰值信噪比PSNR做為衡量視頻質(zhì)量的客觀參數(shù)，PSNR值越大說明視頻質(zhì)量越高。實(shí)驗(yàn)選擇X86平臺(tái)，CPU為Intel（R）Core（TM）i3 M390，RAM大小為2 GB，操作系統(tǒng)為Ubuntu 11.0。對(duì)每個(gè)序列使用改進(jìn)后的算法和原算法分別進(jìn)行100次編碼測(cè)試，取其平均值記錄在表1、表2中。

表1 “akiyo”的編碼表現(xiàn)

表2 “foreman”的編碼表現(xiàn)

由以上兩組測(cè)試數(shù)據(jù)可以看出：DS算法擁有最快的速度然而其視頻質(zhì)量下降較大；TESA和UMH表現(xiàn)出了最好的圖像質(zhì)量但是它們的速度較慢；與HEX算法相比優(yōu)化后的OHEX算法在兩次實(shí)驗(yàn)中將速度分別提升了12.53%和8.56%，其圖像質(zhì)量損失幾乎可以忽略。

對(duì)于用戶來講，多屏共享系統(tǒng)最直觀也是最重要的參數(shù)就是視頻的延遲時(shí)間。其中視頻的延遲時(shí)間是指從服務(wù)器端開始對(duì)設(shè)備的屏幕截圖到客戶端最終完成對(duì)這一幀的解碼并將其顯示的時(shí)間。為了評(píng)估編碼器的優(yōu)化對(duì)延遲時(shí)間的影響，使用原編碼器和改進(jìn)后的編碼器進(jìn)行比較，實(shí)驗(yàn)場(chǎng)景如圖4所示。

圖4 實(shí)驗(yàn)場(chǎng)景

測(cè)試環(huán)境服務(wù)器端CPU為Nvidia Tegra3 1.3 GHz 處理器， RAM為2 GB，操作系統(tǒng)為Android 4.1.1，屏幕分辨率為1 280×720?？蛻舳薈PU為Intel（R）Core（TM）i3 M390 2.67 GHz，RAM為2 GB，操作系統(tǒng)為Ubuntu 11.0。實(shí)驗(yàn)在局域網(wǎng)中進(jìn)行，編碼器的碼率設(shè)為800 Kb/s。結(jié)果如表3所示。

表3 延遲時(shí)間測(cè)試

表3中系統(tǒng)的最大延遲時(shí)間被縮短了13.77%，平均延遲時(shí)間被縮短了7.65%。盡管延遲時(shí)間最主要是由視頻編碼和網(wǎng)絡(luò)傳輸所產(chǎn)生，本文所提出的算法改進(jìn)還是在相當(dāng)可觀的范圍內(nèi)減小了它。

5 結(jié) 語

本文提出了一種優(yōu)化的H.264運(yùn)動(dòng)估計(jì)算法，并通過實(shí)驗(yàn)證明了新的算法可以平均節(jié)約10%的編碼時(shí)間與此同時(shí)幾乎不產(chǎn)生圖像質(zhì)量的下降。另外本文還設(shè)計(jì)并實(shí)現(xiàn)了一種使用改進(jìn)后H.264算法的運(yùn)動(dòng)估計(jì)算法的多屏共享系統(tǒng)。這一研究成果可以用于智能電視、智能手機(jī)、平板電腦等消費(fèi)類電子產(chǎn)品的應(yīng)用開發(fā)，并極大程度的改善用戶的娛樂體驗(yàn)。

參考文獻(xiàn)

[1] ITU. H.264 standard [EB/OL]. [2007?06?26]. http：//bbs.chinavideo.org/.

[2] CHEN T C， CHIEN S Y. Analysis and architecture design of an HDTV720p 30 frames/s H.264/AVC encoder [J]. IEEE Transactions on Circuits and Systems for Video Technology， 2006， 16（6）： 673?688.

[3] KOGA T， IINUMA K， HIRANO A， et al. Motion compensated interframe coding for video conferencing [C]// Proceedings of National Telecommunications Conference. [S.l.]： NTC， 1981： 1?5.

[4] ZHU S， MA K K. A new diamond search algorithm for fast block?matching motion estimation [J]. IEEE Transaction on Image Process， 2000， 9（2）： 287?290.

[5] ZHU C， LIN X， CHAU L P. Hexagon?based search pattern for fast block motion estimation [J]. IEEE Transactions on Circuits and System for Video Technology， 2002， 12（5）： 349?355.

[6] XU X， HE Y. Improvements on fast motion estimation strategy for H.264/AVC [J]. IEEE Transaction on Circuits and System for Video Technology， 2008， 18（3）： 285?293.

[7] Anon. Framebuffer HOW TO [EB/OL]. [2010?08?05]. http：//www.tldp.org/HOWTO/Framebuffer?HOWTO.

[8] FfmpegEngineering Group. FFmpeg development mahual [EB/OL]. [2010?09?28]. http：//www.ffmpeg.com.cn/index.php.

[9] 魏星，蔣建國(guó)，齊美彬，等.基于預(yù)測(cè)的自適應(yīng)運(yùn)動(dòng)估計(jì)算法[J].中國(guó)圖象圖形學(xué)報(bào)，2005（7）：873?877.

[10] CAI J， WU Y. Spatial characteristic based rate control initialization method for conversational video communication of H.264/AVC using linear prediction [J]. Journal of Multimedia， 2013， 8（5）： 489?495.

3.2 六邊形搜索算法的改進(jìn)

由上一節(jié)的分析可以看出，擁有較大運(yùn)動(dòng)矢量的塊可以使用六邊形模板快速定位到其運(yùn)動(dòng)矢量的周圍，然后再用正方形進(jìn)行細(xì)化得到準(zhǔn)確的矢量。統(tǒng)計(jì)試驗(yàn)表明運(yùn)動(dòng)矢量具有中心偏置性和相關(guān)性，對(duì)于運(yùn)動(dòng)緩慢的視頻序列，最佳運(yùn)動(dòng)矢量[9]在3×3區(qū)域內(nèi)占90%左右，即使運(yùn)動(dòng)劇烈的視頻序列football[9]分布在3×3區(qū)域內(nèi)的仍有72%，因此過早的使用六邊形模板帶來了許多不必要的運(yùn)算。為了解決這一問題，本文結(jié)合菱形搜索算法的特點(diǎn)并引入提前終止策略對(duì)六邊形搜索算法予以改進(jìn)，具體方案如下：

使用六邊形模板搜索之前在搜素起點(diǎn)先使用正方形模板搜索一次，模板如圖3所示，分別計(jì)算正方形形中心點(diǎn)和周圍8個(gè)點(diǎn)的誤差代價(jià)cost，將上述9個(gè)點(diǎn)中cost值最小點(diǎn)記為bmv，bmv點(diǎn)對(duì)應(yīng)cost記為bcost，比較bcost與預(yù)測(cè)最佳誤差代價(jià)bpred_cost，若bcost小于bpred_cost則整像素搜索結(jié)束，否則以bmv為搜索起點(diǎn)開始六邊形搜索。當(dāng)宏塊靜止或運(yùn)動(dòng)緩慢時(shí)，其運(yùn)動(dòng)矢量分布在搜索起點(diǎn)周圍區(qū)域的概率較大，使用改進(jìn)前的六邊形的搜索算法需要計(jì)算15個(gè)點(diǎn)的誤差代價(jià)而改進(jìn)后只需要計(jì)算9個(gè)點(diǎn)，效率得到了大大的提高。

4 實(shí)驗(yàn)與分析

首先通過實(shí)驗(yàn)對(duì)改進(jìn)后的六邊形搜索算法和原來的4種搜索進(jìn)行比較。分別取運(yùn)動(dòng)比較緩慢的cif序列akiyo和運(yùn)動(dòng)較為劇烈的foreman經(jīng)行編碼測(cè)試，選擇峰值信噪比PSNR做為衡量視頻質(zhì)量的客觀參數(shù)，PSNR值越大說明視頻質(zhì)量越高。實(shí)驗(yàn)選擇X86平臺(tái)，CPU為Intel（R）Core（TM）i3 M390，RAM大小為2 GB，操作系統(tǒng)為Ubuntu 11.0。對(duì)每個(gè)序列使用改進(jìn)后的算法和原算法分別進(jìn)行100次編碼測(cè)試，取其平均值記錄在表1、表2中。

表1 “akiyo”的編碼表現(xiàn)

表2 “foreman”的編碼表現(xiàn)

由以上兩組測(cè)試數(shù)據(jù)可以看出：DS算法擁有最快的速度然而其視頻質(zhì)量下降較大；TESA和UMH表現(xiàn)出了最好的圖像質(zhì)量但是它們的速度較慢；與HEX算法相比優(yōu)化后的OHEX算法在兩次實(shí)驗(yàn)中將速度分別提升了12.53%和8.56%，其圖像質(zhì)量損失幾乎可以忽略。

對(duì)于用戶來講，多屏共享系統(tǒng)最直觀也是最重要的參數(shù)就是視頻的延遲時(shí)間。其中視頻的延遲時(shí)間是指從服務(wù)器端開始對(duì)設(shè)備的屏幕截圖到客戶端最終完成對(duì)這一幀的解碼并將其顯示的時(shí)間。為了評(píng)估編碼器的優(yōu)化對(duì)延遲時(shí)間的影響，使用原編碼器和改進(jìn)后的編碼器進(jìn)行比較，實(shí)驗(yàn)場(chǎng)景如圖4所示。

圖4 實(shí)驗(yàn)場(chǎng)景

測(cè)試環(huán)境服務(wù)器端CPU為Nvidia Tegra3 1.3 GHz 處理器， RAM為2 GB，操作系統(tǒng)為Android 4.1.1，屏幕分辨率為1 280×720?？蛻舳薈PU為Intel（R）Core（TM）i3 M390 2.67 GHz，RAM為2 GB，操作系統(tǒng)為Ubuntu 11.0。實(shí)驗(yàn)在局域網(wǎng)中進(jìn)行，編碼器的碼率設(shè)為800 Kb/s。結(jié)果如表3所示。

表3 延遲時(shí)間測(cè)試

表3中系統(tǒng)的最大延遲時(shí)間被縮短了13.77%，平均延遲時(shí)間被縮短了7.65%。盡管延遲時(shí)間最主要是由視頻編碼和網(wǎng)絡(luò)傳輸所產(chǎn)生，本文所提出的算法改進(jìn)還是在相當(dāng)可觀的范圍內(nèi)減小了它。

5 結(jié) 語

本文提出了一種優(yōu)化的H.264運(yùn)動(dòng)估計(jì)算法，并通過實(shí)驗(yàn)證明了新的算法可以平均節(jié)約10%的編碼時(shí)間與此同時(shí)幾乎不產(chǎn)生圖像質(zhì)量的下降。另外本文還設(shè)計(jì)并實(shí)現(xiàn)了一種使用改進(jìn)后H.264算法的運(yùn)動(dòng)估計(jì)算法的多屏共享系統(tǒng)。這一研究成果可以用于智能電視、智能手機(jī)、平板電腦等消費(fèi)類電子產(chǎn)品的應(yīng)用開發(fā)，并極大程度的改善用戶的娛樂體驗(yàn)。

參考文獻(xiàn)

[1] ITU. H.264 standard [EB/OL]. [2007?06?26]. http：//bbs.chinavideo.org/.

[2] CHEN T C， CHIEN S Y. Analysis and architecture design of an HDTV720p 30 frames/s H.264/AVC encoder [J]. IEEE Transactions on Circuits and Systems for Video Technology， 2006， 16（6）： 673?688.

[3] KOGA T， IINUMA K， HIRANO A， et al. Motion compensated interframe coding for video conferencing [C]// Proceedings of National Telecommunications Conference. [S.l.]： NTC， 1981： 1?5.

[4] ZHU S， MA K K. A new diamond search algorithm for fast block?matching motion estimation [J]. IEEE Transaction on Image Process， 2000， 9（2）： 287?290.

[5] ZHU C， LIN X， CHAU L P. Hexagon?based search pattern for fast block motion estimation [J]. IEEE Transactions on Circuits and System for Video Technology， 2002， 12（5）： 349?355.

[6] XU X， HE Y. Improvements on fast motion estimation strategy for H.264/AVC [J]. IEEE Transaction on Circuits and System for Video Technology， 2008， 18（3）： 285?293.

[7] Anon. Framebuffer HOW TO [EB/OL]. [2010?08?05]. http：//www.tldp.org/HOWTO/Framebuffer?HOWTO.

[8] FfmpegEngineering Group. FFmpeg development mahual [EB/OL]. [2010?09?28]. http：//www.ffmpeg.com.cn/index.php.

[9] 魏星，蔣建國(guó)，齊美彬，等.基于預(yù)測(cè)的自適應(yīng)運(yùn)動(dòng)估計(jì)算法[J].中國(guó)圖象圖形學(xué)報(bào)，2005（7）：873?877.

[10] CAI J， WU Y. Spatial characteristic based rate control initialization method for conversational video communication of H.264/AVC using linear prediction [J]. Journal of Multimedia， 2013， 8（5）： 489?495.