徐 揚，趙曉森，高宇翔，王志謙

（北京郵電大學(xué) 網(wǎng)絡(luò)技術(shù)研究院，北京100876）

隨著網(wǎng)絡(luò)的普及，各種應(yīng)用軟件層出不窮，運行應(yīng)用需要足夠的計算能力和存儲空間，很多瘦終端已經(jīng)無法滿足當(dāng)前應(yīng)用所需的處理能力，正面臨被淘汰的局面。然而，云計算有著超強的計算和存儲能力，將瘦終端通過網(wǎng)絡(luò)接入與云計算的優(yōu)勢結(jié)合在一起，應(yīng)用程序本身不在終端上運行，只需要將人機交互數(shù)據(jù)傳送到云端實際運行應(yīng)用的服務(wù)器，云端服務(wù)器將應(yīng)用的計算結(jié)果（即屏幕的更新）返回到終端[1]。這使得用戶能夠不受終端設(shè)備的限制即可獲得極高的用戶體驗，同時帶來了多方面的優(yōu)勢，如解決應(yīng)用的兼容性問題，節(jié)省二次開發(fā)成本，實現(xiàn)應(yīng)用的集中管理和控制等。本文的主要工作是討論如何將應(yīng)用圖形用戶界面（GUI）傳輸給終端，提出一種應(yīng)用遠(yuǎn)程顯示的方法，并對該方法進(jìn)行驗證。

1 相關(guān)工作

隨著人們對瘦終端發(fā)展的重視，現(xiàn)在市面上已經(jīng)存在許多可供選擇的瘦客戶端解決方案，例如X，Microsoft Remote Desktop，Citrix MetraFrame XP，Virtual Network Computing（VNC），GoToMyPC等。然而，這些解決方案都是成熟的商業(yè)產(chǎn)品，客戶端一般只針對計算機和智能手機，存在一定的限制[2]。

X把所有的用戶界面處理交給客戶端，以此來提供遠(yuǎn)程顯示，由于應(yīng)用的顯示邏輯和運行邏輯通常是緊耦合的，那么在客戶端處理用戶界面的同時應(yīng)用邏輯運行在服務(wù)器端，這樣會帶來客戶端與服務(wù)器端的持續(xù)同步。此外，客戶端用于處理應(yīng)用顯示界面的視窗服務(wù)軟件比較復(fù)雜，并需要頻繁更新，隨著用戶界面越來越豐富多彩，將會給客戶端帶來更加復(fù)雜的處理壓力。

Microsoft Remote Desktop，Citrix Metra Frame XP，VNC避免了在客戶端運行復(fù)雜的視窗服務(wù)軟件的情況，所有的應(yīng)用和圖形用戶界面都在服務(wù)器端運行，客戶端相當(dāng)于一個簡單的輸入輸出設(shè)備?？蛻舳吮镜乇４嬉粋€用于刷新顯示的幀緩存副本，當(dāng)應(yīng)用發(fā)出顯示命令時，服務(wù)器處理這些命令并通過網(wǎng)絡(luò)發(fā)送屏幕更新來生成新的客戶端本地幀緩存。GoToMyPC簡化為用原始的像素值來表示顯示更新，從服務(wù)器幀緩存中讀取像素數(shù)據(jù)并編碼壓縮（即屏幕截?。缓蟀l(fā)送給客戶端。屏幕截取是一個簡單的過程，它從發(fā)送給客戶端的應(yīng)用顯示更新中解耦合了顯示命令的處理。服務(wù)器做了所有的應(yīng)用顯示命令到像素數(shù)據(jù)的轉(zhuǎn)換工作，客戶端可以變得非常簡單。但是，僅由原始像素值組成的顯示命令需要更多的傳輸帶寬。

2 一種基于X Window System的應(yīng)用流化方法

為了最大化應(yīng)用的跨平臺性，采用類似GoToMyPC的思想，提出一種基于X Window System的應(yīng)用圖形用戶界面（GUI）流化方法。將應(yīng)用在云端服務(wù)器上運行后的GUI抓取下來，然后通過實時編碼壓縮后以視頻流的方式傳送給客戶端，客戶端解碼呈現(xiàn)應(yīng)用GUI，從而實現(xiàn)應(yīng)用的遠(yuǎn)程顯示。

2.1 FFmpeg和H.264簡介

FFmpeg是一個集錄制、轉(zhuǎn)換、音/視頻編解碼功能為一體的完整的音頻和視頻流開源解決方案。FFmpeg支持MPEG，DivX，MPEG4，AC3，DV，F(xiàn)LV等40多種編碼，以及AVI，MPEG，OGG，ASF等90多種解碼，很多優(yōu)秀的開源播放器如VLC，MPlayer等都用到了FFmpeg。FFmpeg源代碼中主要有以下4個常用庫 文 件：libavcodec，libavformat，libavutil和libswascale。其中，libavcodec是目前領(lǐng)先的音/視頻編解碼庫，用于存放編解碼各種類型音視頻的模塊；libavformat主要用于存放各種音視頻封裝格式的muxer/demuxer模塊；libavutil包含一些公共的工具函數(shù)，用于存放內(nèi)存操作等常用模塊；libswscale主要用來處理視頻圖像的縮放[3]。

由于抓取的原始視頻數(shù)據(jù)量很大，對帶寬要求高，因此有必要在網(wǎng)絡(luò)傳輸前對這些數(shù)據(jù)進(jìn)行壓縮。根據(jù)視頻基礎(chǔ)知識，同一幅圖像中的像素之間具有較強的相關(guān)性，兩個像素之間距離越近，相關(guān)性越強，空間冗余越大。同樣，幀與幀之間也存在這種相關(guān)性，稱之為時間冗余。通過消除空間和時間冗余就可以達(dá)到壓縮的目的，減少數(shù)據(jù)量[4]。H.264是由VCEG和MPEG聯(lián)合制定的一套最新的視頻壓縮標(biāo)準(zhǔn)，它同時采用以上兩種方式來進(jìn)行數(shù)據(jù)壓縮，其編解碼流程主要包括5個部分：幀間和幀內(nèi)預(yù)測、變換和反變換、量化和反量化、環(huán)路濾波、熵編碼。H.264分兩層結(jié)構(gòu)：視頻編碼層（VCL）和網(wǎng)絡(luò)抽象層（NAL）。VCL的主要任務(wù)就是用高效的編碼方式進(jìn)行視頻數(shù)據(jù)壓縮，NAL則根據(jù)網(wǎng)絡(luò)的特性對數(shù)據(jù)進(jìn)行封裝打包，使其適于網(wǎng)絡(luò)傳輸[5]。與之前的視頻編碼標(biāo)準(zhǔn)相比，H.264具有更高的壓縮比率、編碼性能和圖像質(zhì)量，在相同視覺感知質(zhì)量上編碼效率比MPEG-2和MPEG-4提高了50%左右[6]，同時具有很好的抗誤碼能力和網(wǎng)絡(luò)適配性，可以很好地適用于實時通信。

對于H.264協(xié)議的編解碼來說，F(xiàn)Fmpeg能很好地解碼，而編碼需要調(diào)用X264編碼庫。X264摒棄了一些對編碼性能提升很低但計算復(fù)雜度很高的模塊，降低了計算的復(fù)雜度。FFmpeg只需要在配置選項中選擇--enable-libx264就可添加對X264編碼庫的支持，從而實現(xiàn)H.264編碼。

2.2 應(yīng)用圖形界面的流化過程

本文的應(yīng)用流化方法基于X Window System（X11或X）。X Window System是一種位圖顯示的視窗系統(tǒng)，它是在Unix和類Unix操作系統(tǒng)上建立圖形用戶界面的標(biāo)準(zhǔn)工具包和協(xié)議，并可用于幾乎所有已有的現(xiàn)代操作系統(tǒng)。根據(jù)前文所述的方法流程，將其分為視頻采集模塊、壓縮編碼模塊和封裝傳輸模塊3個模塊。

1）視頻采集模塊：根據(jù)客戶端的選擇啟動并運行應(yīng)用，利用應(yīng)用的進(jìn)程號PID查找得到應(yīng)用的窗口ID。首先調(diào)用X11函數(shù)XOpenDisplay（）得到默認(rèn)的display指針，然后調(diào)用XDefaultRootWindow（）返回默認(rèn)屏幕的根窗口，通過函數(shù)XInternAtom（）來獲得PID屬性的Atom，從根窗口開始查找，調(diào)用XGetWindowProperty（）返回窗口對應(yīng)的PID與已知PID比較，若相等則找到應(yīng)用窗口；若不相等，則遞歸查詢子窗口。然后，根據(jù)窗口ID，調(diào)用X11函數(shù)XGetWindowAttributes（）返回應(yīng)用窗口的屬性到結(jié)構(gòu)體XWindowAttributes中，該結(jié)構(gòu)體包含窗口的寬度、高度、位置坐標(biāo)等屬性。最后，根據(jù)窗口信息調(diào)用X11擴展庫MIT-SHM提供的XShmGetImage（）函數(shù)持續(xù)抓取指定的應(yīng)用窗口圖像直到關(guān)閉應(yīng)用。

2）壓縮編碼模塊：FFmpeg調(diào)用X264編碼庫對抓取后的視頻進(jìn)行H.264編碼。FFmpeg首先調(diào)用av_regsiter_all（）注冊編解碼器，然后調(diào)用transcode_init（）初始化編碼器，其中avcodec_find_encoder（）函數(shù)的參數(shù)設(shè)置為CODEC_ID_H264，即使用H.264編碼，設(shè)置codec-＞time_base.num，codec-＞time_base.den，它們的比值為幀率。

3）網(wǎng)絡(luò)傳輸模塊：RTP協(xié)議能對流媒體數(shù)據(jù)進(jìn)行封包并且實現(xiàn)媒體流的實時傳輸，本方法采用IP/UDP/RTP協(xié)議層次結(jié)構(gòu)。H.264視頻流的組包需要適應(yīng)網(wǎng)絡(luò)的MTU，否則可能無法檢測數(shù)據(jù)是否丟失。以太網(wǎng)的MTU為1 500 byte，IP頭至少為20 byte，UDP頭至少為8 byte，RTP頭為12 byte，所以RTP的最大載荷為1 460 byte，如果RTP的載荷數(shù)據(jù)大于1 460 byte，在IP層就會將其拆分為幾個小于MTU尺寸的IP分組，這樣會導(dǎo)致無法檢測數(shù)據(jù)丟失[5]。對于大尺寸NAL單元，在數(shù)據(jù)裝載進(jìn)RTP分組之前就要進(jìn)行拆分；如果RTP載荷過小，協(xié)議頭部所占的比例將增大，這會增大網(wǎng)絡(luò)的開銷，所以可以把幾個較小的NAL單元合并在一個RTP分組中傳輸。首先將編碼后的數(shù)據(jù)流進(jìn)行緩存，接著找到每一個NAL單元的起始地址，根據(jù)每個NAL單元大小采用以上討論方式進(jìn)行封裝后，發(fā)送至客戶端。

3 方案驗證

本方案驗證的硬件環(huán)境為Intel T6600 2.2 GHz CPU，2 Gbyte DDR2內(nèi)存，NVIDIA GeForce G105M顯卡，操作系統(tǒng)為Ubuntu Linux 12.04LTS。通過流化Firefox瀏覽器圖形界面對本方案的可行性進(jìn)行了驗證，并簡單地測試了該方案的性能。

測試按照25 f/s（幀/秒）采集2 min，瀏覽器窗口大小為640×480（單位為像素），流化后視頻的平均碼率為304.8 kbit/s，視頻畫面清晰流暢，無明顯延遲效果。原始應(yīng)用界面和流化后的效果如圖1所示，其中圖1a為服務(wù)器端應(yīng)用的實際顯示，圖1b為服務(wù)器上的模擬客戶端接收到的畫面，兩幅圖是同時被截取的，為了估計出流化過程產(chǎn)生的延時，在瀏覽器中啟動了一個秒表，通過這樣一個直觀的時間顯示，粗略估計出流化過程的時延。采集的10組時間樣本如表1所示，最后得到平均時延約為85.6 ms。由于服務(wù)器和客戶端是在同一臺計算機上運行，幾乎不存在網(wǎng)絡(luò)傳輸時延，所以該延時可表示整個流化過程和客戶端解碼顯示圖像的總時間。可以預(yù)見，這個延時在硬件配置更高的機器上將會更短。測試結(jié)果表明該方法延時低、占用網(wǎng)絡(luò)帶寬較大。

圖1 實際應(yīng)用顯示和流化后的顯示（截圖）

表1 采集的時間樣本

4 小結(jié)

瘦終端具有簡單、低成本、低功耗等優(yōu)勢，本文提出了一種將應(yīng)用GUI轉(zhuǎn)換成視頻流的流化方法，該方法降低了顯示應(yīng)用GUI對瘦終端計算能力的要求，具有良好的跨平臺性，為應(yīng)用在瘦終端上遠(yuǎn)程顯示提供了一種切實可行的方法。筆者后續(xù)將會進(jìn)行瘦客戶端對服務(wù)器應(yīng)用遠(yuǎn)程控制的研究工作。

[1]KIM J，BARATTO R，NIEH J.An application streaming service for mobile handheld devices[C]//Proc.IEEE International Conference on Services Computing(SCC).[S.l.]∶IEEE Press，2006∶323-326.

[2]BARATTO R，KIM L，NIEH J.THINC∶a virtual display architecture for thin client computing[C]//Proc.The 20th ACM Symposium on Operating Systems Principles(SOSP)書S.l.]∶ACM Press，2005：277-290.

[3]胡聰，周甜，唐璐丹.基于FFMPEG的跨平臺視頻編解碼研究[J].武漢理工大學(xué)學(xué)報，2011，33（11）：139-142.

[4]王永剛.3G視頻監(jiān)控系統(tǒng)中H.264編碼實現(xiàn)與應(yīng)用軟件開發(fā)[D].杭州：杭州電子科技大學(xué)，2011.

[5]盛先剛.基于RTP的H.264視頻傳輸系統(tǒng)研究[D].西安：西安電子科技大學(xué)，2006.

[6]王嵩，薛全，張穎，等.H.264視頻編碼新標(biāo)準(zhǔn)及性能分析[J].電視技術(shù)，2003，27（6）：25-27.