基于H.264編碼的多屏共享系統(tǒng)研究

張豐源+黃全明

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

關鍵字： 多頻共享系統(tǒng)； H.264/AVC； 運動估計； 延遲時間

中圖分類號： TN919?34 文獻標識碼： A 文章編號： 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ā)展，各種智能化的家電不斷進入千家萬戶，數(shù)字家庭的概念日漸深入人心。作為數(shù)字家庭的具體應用之一，多屏共享系統(tǒng)旨在隨時隨地支持用戶使用各種設備來訪問在不同設備上的視頻、圖片等各種資源，它給用戶的PC，TV，移動手持設備帶來的是無縫的連接和無縫的播放感受。Android操作系統(tǒng)是一種基于Linux的開放源代碼操作系統(tǒng)，自從問世以來便因其自由開放的特性以及較高的效率受到用戶和廣大廠商的一致追捧，目前市面上絕大多數(shù)的智能手機、智能電視、平板電腦均采用Android作為操作系統(tǒng)。本文將采用Android系統(tǒng)作為研究對象，在其基礎上完成對多屏共享系統(tǒng)的設計和搭建。

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

1 系統(tǒng)總體設計

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

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

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

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

2 系統(tǒng)關鍵技術

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

Android系統(tǒng)上的應用程序使用Java語言編寫，為了提高程序的執(zhí)行效率，服務器端主要代碼全部采用C語言編寫，然后使用Android提供的NDK工具將其編譯成鏈接庫加載至Android工程目錄中供Java程序調用?？蛻舳嗽赑C平臺上進行開發(fā)，選擇Qt做為開發(fā)框架。Qt是一套優(yōu)秀的UI應用程序框架，與其他開發(fā)工具相比Qt具有優(yōu)良的跨平臺特性、面向對象、豐富的API、支持 2D/3D 圖形渲染、支持XML等優(yōu)勢。

2.2 屏幕截取

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

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

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

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

具體編碼流程如下：

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

（2） 調用avcodec_find_decoder（）和avcodec_open（）找到并打開x264編碼器。

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

（4） 調用自定義函數(shù) get_frame_data（）從Framebuffer中獲得當前屏幕截圖，將圖像數(shù)據由RGB24格式轉化為YUV420格式。

（5） 調用avcodec_encode_video2（）函數(shù)對YUV幀進行編碼，將所得數(shù)據存放在結構體AVPacket中供網絡發(fā)送模塊調用。

（6） 等待客戶端下一次請求，然后重復步驟（4）、步驟（5）。

3 H.264運動估計算法的優(yōu)化

3.1 H.264運動估計算法簡介

塊匹配法是目前常用的運動估計算法，X264中提供了4種塊匹配算法：全搜索算法（ESA）、菱形搜索算法（DIA）、六邊形搜索算法（HEX）、非對稱十字形多層次六邊形格點搜索算法（UMH）。

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

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

圖2 六邊形搜索模板

圖3 正方形細化模板

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

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

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

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

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

步驟5：比較b_cost與bpred_cost的大小，若b_cost小于bpred_cost則采用搜索值bmv作為當前宏塊的運動矢量，否則采用預測值pmv。結束整像素搜索，開始[12]和[14]像素的搜索。

3.2 六邊形搜索算法的改進

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

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

4 實驗與分析

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

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

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

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

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

圖4 實驗場景

測試環(huán)境服務器端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。實驗在局域網中進行，編碼器的碼率設為800 Kb/s。結果如表3所示。

表3 延遲時間測試

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

5 結 語

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

參考文獻

[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] 魏星，蔣建國，齊美彬，等.基于預測的自適應運動估計算法[J].中國圖象圖形學報，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 六邊形搜索算法的改進

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

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

4 實驗與分析

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

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

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

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

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

圖4 實驗場景

測試環(huán)境服務器端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。實驗在局域網中進行，編碼器的碼率設為800 Kb/s。結果如表3所示。

表3 延遲時間測試

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

5 結 語

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

參考文獻

[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] 魏星，蔣建國，齊美彬，等.基于預測的自適應運動估計算法[J].中國圖象圖形學報，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 六邊形搜索算法的改進

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

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

4 實驗與分析

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

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

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

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

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

圖4 實驗場景

測試環(huán)境服務器端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。實驗在局域網中進行，編碼器的碼率設為800 Kb/s。結果如表3所示。

表3 延遲時間測試

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

5 結 語

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

參考文獻

[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] 魏星，蔣建國，齊美彬，等.基于預測的自適應運動估計算法[J].中國圖象圖形學報，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.