一種適用于瘦終端的應用流化方法

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

（北京郵電大學 網絡技術研究院，北京100876）

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

1 相關工作

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

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

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

2 一種基于X Window System的應用流化方法

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

2.1 FFmpeg和H.264簡介

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

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

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

2.2 應用圖形界面的流化過程

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

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

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

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

3 方案驗證

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

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

圖1 實際應用顯示和流化后的顯示（截圖）

表1 采集的時間樣本

4 小結

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

[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].武漢理工大學學報，2011，33（11）：139-142.

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

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

[6]王嵩，薛全，張穎，等.H.264視頻編碼新標準及性能分析[J].電視技術，2003，27（6）：25-27.