劉 堅，余 綜

（華北計算技術研究所，北京100083）

0 引 言

VNC（virtual network computing）是劍橋大學AT＆T實驗室設計開發(fā)的一款優(yōu)秀的遠程桌面控制軟件，它允許用戶通過一個簡單的客戶端軟件（VNC viewer），在有互聯(lián)網的任何地方，控制另一臺安裝了服務端軟件（VNC server）的計算機。用戶通過VNC可以在本地控制遠程計算機，從而實現(xiàn)了在遠程計算機上辦公、對遠程計算機進行診斷和維護等功能，這給用戶和計算機管理員帶來了極大的方便，因此VNC也越來越受到人們的廣泛關注。然而隨著多媒體技術的發(fā)展，利用VNC遠程觀看高清視頻、玩3D游戲成為了人們的新需求，在這些場合下，桌面環(huán)境變化大、變化頻率快。而VNC由于網絡帶寬及其所采用的請求－應答－請求模式的限制，使得客戶端收到的幀率無法達到視頻流暢播放所要求的幀率，在客戶端看到的圖像就如同幻燈片一樣，無法給用戶提供流暢視頻圖像［1］。即使達到所要求的幀率，傳輸?shù)臄?shù)據(jù)量也非常大，對于一般的網絡環(huán)境而言是無法承受的，這也對VNC提出了新的挑戰(zhàn)。

本文對現(xiàn)有的一些解決方案進行了深入的研究，并在其基礎上提出了一種改進的混合傳輸方案。該方案通過一種啟發(fā)式算法計算出桌面上的視頻區(qū)域，然后將視頻區(qū)域經H.264壓縮再傳輸，從而減少了視頻在非全屏播放時的網絡帶寬及CPU利用率。

1 VNC編碼技術

VNC采用的通信協(xié)議是RFB（remote frame buffer）協(xié)議，RFB協(xié)議是一個簡單的遠程圖形傳輸協(xié)議，它不依賴于具體的圖形接口，因此在所有的窗口系統(tǒng)（X11、Windows、Mac等）和應用程序中都可使用［2］。RFB協(xié)議中的編碼方法主要包括Raw、Copy Rectangle、RRE、Hextile和 ZRLE等方法［2－3］。

Raw編碼是最簡單的編碼類型，這種編碼方式下，屏幕上的像素點簡單地從左到右掃描，然后發(fā)送到客戶端。除非客戶端要求其它編碼類型，否則服務器端默認采用Raw編碼。

Copy Rectangle編碼通過使用客戶端緩沖區(qū)中的數(shù)據(jù)，讓RFB協(xié)議在某些情況（如窗口移動等）下變得很高效，因為這時客戶端已有了待傳輸?shù)臄?shù)據(jù)，因此只需將更新區(qū)域的坐標發(fā)送給客戶端，然后客戶端在緩沖區(qū)中相應位置拷貝即可。

RRE（rise－and－run－length）編碼 的 思 想 就 是 將 像 素 值相同的矩形區(qū)域作為一個整體傳輸，從而減少了傳輸?shù)臄?shù)據(jù)量。RRE編碼首先傳輸?shù)氖且粋€背景色Vb（屏幕上最常用的像素值）和一個矩形計數(shù)值N，然后是小矩形塊，每個小矩形塊的信息包括矩形的左上坐標、高度、寬度以及一個前景色值。在客戶端顯示時，先填充背景色，然后再在每個小矩形區(qū)域填充對應的前景色即可。RRE的解碼效率較高，可以減輕客戶端的處理負擔。

Hextile是RRE編碼的變種，Hextile編碼把整個屏幕分割成一個個16x16的小片，如果屏幕的寬度（高度）不是16的整數(shù)倍，那么最后的小片也相應減少，小片遵守從左到右，自上而下的順序。每個小片采用的編碼方式可以是Raw編碼，也可以是RRE編碼的變種。

ZRLE（Zlib run－length encoding）編碼結合了zlib壓縮、分片、調色板和run－length編碼等技術，在傳輸時，首先傳輸?shù)氖且粋€4字節(jié)的長度值，緊接著是該長度的zlib壓縮數(shù)據(jù)。每個RFB連接使用的是一個單一的zlib流對象，因此ZRLE編碼的矩形必須嚴格地按照順序進行編解碼。

上述VNC所采用的這些編碼方式的特點是編解碼速度較快，但壓縮率不高，這些編碼對于用戶一些普通的使用（如查看文件、瀏覽網頁等）來說，能夠工作得很好。但在需要界面高速變化的場合，如觀看視頻，界面的刷新需要達到每秒25幀左右，由于VNC Viewer采用的單線程模式，使得每秒接收的幀數(shù)遠小于25幀，即使是達到25幀每秒，服務端向客戶端發(fā)送的數(shù)據(jù)將達到幾十兆每秒，這也是網絡環(huán)境無法承受的，因此必須采用一種高壓縮率的編碼方法。2003年3月，ITU－T/ISO頒布了H.264視頻編碼標準［4］，就能滿足高壓縮率的要求。H.264視頻標準不僅使視頻壓縮比以往所有標準有明顯提高，而且具有良好的網絡親和性，特別是對IP互聯(lián)網、無線移動網等易誤碼、易阻塞、QoS不易保證的網絡視頻傳輸性能有明顯的改善，由于其相比以往標準的出色的性能，被稱為新一代視頻編碼標準。與 H.263或 MPEG－4相比，在同樣質量下，其數(shù)碼率能降低一半左右；或者說在同樣碼率下，其信噪比明顯提高。因此可以在VNC中引入H.264來降低傳輸多媒體數(shù)據(jù)時帶來的網絡帶寬。

2 VNC多媒體傳輸方案

針對VNC在多媒體數(shù)據(jù)傳輸中的缺陷，目前主要有兩類改進方案，一類是采用緩沖機制將所要傳輸?shù)臄?shù)據(jù)先緩存在服務端，然后再傳輸?shù)娇蛻舳?，另一類方案是在服務端采用一種高壓縮率的編碼（如MPEG－4、H.264等）方法，先在服務端將桌面圖像數(shù)據(jù)高度壓縮，然后將壓縮數(shù)據(jù)通過網絡傳輸?shù)娇蛻舳耍蛻舳嗽偻瓿山獯a、圖像的顯示等。

對于第一類方案，Cynthia Taylor等人［5］通過在客戶端和服務端之間增加一個消息加速器來實現(xiàn)，如圖1所示。消息加速器與VNC服務端位于同一個局域網或同一臺計算機中。由于在VNC中，采用“請求－響應－請求”模式，即只有當一個請求消息達到服務器端得到響應將數(shù)據(jù)發(fā)送到客戶端，客戶端完成顯示后才會產生下一個請求消息，這也意味著客戶端每秒能得到響應數(shù)也就是用戶每秒所能看到的幀數(shù)，但由于網絡以及服務端、客戶端處理的延時，使得客戶端的請求信息無法快速得到應答。消息加速器通過緩存客戶端的請求信息，由于消息加速器和服務端在同一局域網或同一臺機器上，兩者之間的傳輸速度較快，且在加速器中也不需要完成圖像的顯示，因此當消息加速器把請求消息發(fā)送給服務端后，可以很快的得到應答，從而達到了加速的目的。加速器和客戶端則可在速度較慢的網絡環(huán)境下通信，數(shù)據(jù)更新響應信息可以比較穩(wěn)定地在消息加速器和客戶端之間傳輸。

圖1 VNC消息加速器

對于第二類方案，在文獻［6－7］中都采用了一種混合遠程傳輸模式，即在普通情況下，VNC仍然采用其原有的RFB協(xié)議進行通信，將其稱之為VNC模式（VNC Mode）。當桌面處在需要快速變化的環(huán)境中時，切換到流模式（streaming mode），在流模式下，VNC服務端可采用H.264對桌面進行壓縮形成視頻幀，然后再通過RTP（real－time transport protocol）協(xié)議［8］傳輸?shù)娇蛻舳?，客戶端再完成解碼顯示，具體流程如圖2所示。緩沖機制雖然能夠加速客戶端得到的應答，但網絡帶寬并沒有減少，在視頻傳輸時的數(shù)據(jù)量依然很大，對網絡的依賴性很強，而且很難達到實時的效果。H.264編碼雖然能提供很高的壓縮率，減少了帶寬，但在原始數(shù)據(jù)量大時，它的編解碼過程將消耗大量的CPU資源，同時也會增加帶寬。Pieter Simoens在文獻［7］中提出的混合遠程傳輸方案在切換到視頻流模式時，把整個桌面圖像作為輸入，而人們在平常使用中，如在瀏覽器中觀看視頻時并沒有全屏觀看，整個桌面實際上只有一小部分是高速變化的視頻區(qū)域（高頻區(qū)域），其它區(qū)域仍然處在靜止狀態(tài)（低頻區(qū)域）。實際上只需要壓縮高頻區(qū)域，而桌面的低頻區(qū)域仍可通過VNC原有的壓縮方式進行通信。這樣既可以減少視頻流的數(shù)據(jù)量，降低網絡帶寬；同時也能降低CPU的負載（這對于計算能力比較弱的瘦客戶端來說是極為重要的）；也能夠避免一些靜態(tài)的文字內容等，由于視頻有損壓縮而帶來的失真［9］。在文獻［10］中，提出了一種檢測高頻區(qū)域的解決方案——動態(tài)圖像檢測方案（dynamic image detection scheme，DIDS），該方法是通過X－server與X－client的交互檢測出高頻區(qū)域，但該方案最大的缺點是只能在X－windows系統(tǒng)中使用。對于非X－windows系統(tǒng)，如 Windows系統(tǒng)，該方案就無法實現(xiàn)。我們接下來將提出一種工作在幀緩沖級別的檢測方法。

圖2 混合遠程傳輸

3 混合遠程傳輸協(xié)議的改進

我們將在文獻［7］提出的方案的基礎上加入一種高頻區(qū)域檢測的方法，首先介紹一下文獻［7］中的方法。在文獻［7］中從VNC模式切換到流模式，他們提供了一種啟發(fā)式的算法。首先使用變量changemon來標識是否需要切換模式。當檢測到屏幕上變化的像素點大于某一個閾值（檢測像素點數(shù)量的5%）時，changemon的值線性增加，反之，則指數(shù)級減少，當changemon的值達到設定模式切換的閾值（MAX＿CHANGEMON/2）時，VNC切換到相應的傳輸模式。相反，在流模式下當changemon的值從MAX＿CHANGEMON減少到接近0時，VNC切換到原有的傳輸方式—VNC模式。這樣既可以有效地避免由于最大、最小化窗口時瞬間引起的桌面圖像的變化給模式切換帶來的誤判，同時也能快速準確地切換到流模式。在該方案中的另一重點是如何選擇待檢測的像素點，既要能夠客觀地反映屏幕上的當前狀態(tài)，又要使得每次比較的時間盡量少。檢測屏幕上所有的像素點雖然可以完全反映屏幕的情況，但這樣效率低下，在混合遠程傳輸方案中采用的是每隔一定數(shù)量的像素點進行采樣，采樣方法如圖3所示。

圖3 像素點采樣

上述方案在切換到流模式后將壓縮整個桌面，稱之為全局壓縮法；我們在上述方案的基礎上加入一種啟發(fā)式的方法去檢索高頻區(qū)域，壓縮的數(shù)據(jù)也只有高頻區(qū)域的像素點，我們稱之為局部壓縮法。我們方案是：對于每個待檢測的像素點i都有一個計數(shù)值p［i］，每次檢測時，當該像素點i的像素值與上次檢測的一致，p［i］減一，最小為0；當像素值與上次不一致，p［i］的值加一，最大為32。在高頻區(qū)域，每次檢測時，其各像素點的像素值基本上都是變化的，因此位于該區(qū)域的像素點對應的p［i］的值都應大于低頻區(qū)域的像素點，我們只要選取合適的閾值PIXEL＿THRSHOLD來判斷各像素點所處的位置。由于在文獻［7］的方案中，由于changemon每次增加的值為MAX＿CHANGEMON/32，也就是說混合遠程傳輸協(xié)議從VNC模式切換到視頻流模式只需16次檢測，因此位于高頻區(qū)域的監(jiān)測點的p值應該大于等于16，而處于低頻區(qū)域的像素點的p值很?。ń咏?）?？紤]到視頻區(qū)域的有些像素點在16次檢測中存在沒有變化的情況，判斷某像素點是否位于高頻區(qū)域內的閾值應低于16，在實驗中PIXEL＿THRSHOLD取值為10。當某像素點對應的p［i］的值大于等于10時，就可認為該像素點處在高頻區(qū)域內。在像素點的檢測過程中，我們只要分別比較記錄下從上下左右4個方向每個檢測點的p［i］值，當?shù)谝淮闻龅絧［i］的值大于等于10時，就可認為該像素點為高頻區(qū)域的上下左右邊界，該上下左右邊界圍成的矩形區(qū)域即為高頻區(qū)域，在切換到流傳輸模式時，我們只要將該高頻區(qū)域經H.264壓縮后傳送的客戶端，而低頻區(qū)域我們仍然采用VNC的編碼方式（Raw、RRE、Hextile、Tight等）傳輸。

像素點的選取同樣采取間隔采樣法。間隔采樣法選取的像素點原則上應盡量少，這樣可以減少檢測時間，從而使每秒發(fā)送的幀數(shù)能達到25幀左右。但在我們的方案中，為了能夠準確地判斷視頻區(qū)域的位置，間隔距離不宜過大。在試驗中，我們選取的間隔值為12。當然間隔值的減少會帶來檢測時間的增加，我們采取的方法是適量減少檢測的次數(shù)，在文獻［7］中采用的是每隔40ms檢測一次，在我們的方案中每隔100－120ms檢測一次，第五部分的實驗結果表明，這樣能夠有效的檢測出高頻區(qū)域的大小，同時也能保持幀率，模式切換的時延也能控制在2s左右。在高頻區(qū)域大小的選取上，我們采用了寧大勿小的原則，也就是說在檢測到高頻區(qū)域的寬度上適當擴充1到2個間隔距離。具體的流程如算法1所示。從中可以看出，每個檢測像素點p值的統(tǒng)計是在每次計算變化的像素點時得到的，因此并沒有增加原有算法的時間復雜度。

算法1：

分別記錄上下左右4個方向p［i］值第一次大于PIXEL＿THRSHOLD的像素點位置；

由這4個像素點圍成的矩形區(qū)域即為高頻區(qū)域

模式切換判斷（詳細算法參見文獻［7］）

End

4 實驗與結果

為了驗證改進后算法的效率，我們在Windows XP平臺下通過修改TightVNC源碼［11］實現(xiàn)了該算法，并進行了測試。實驗過程主要針對文本編輯、非全屏播放視頻和全屏播放視頻3種應用情況，并分別在全局壓縮和部分壓縮算法下，對此3種應用環(huán)境下的網絡帶寬和服務端的CPU利用率進行了統(tǒng)計。實驗環(huán)境如下：服務端配置為處理器Intel Q9500四核CPU，主頻2.83Ghz，內存2GB，客戶端處理器為Pentium E5400雙核CPU，主頻2.7Ghz，內存2GB，網絡環(huán)境為1Gb局域網；在服務端安裝了 Mirage Driver for TightVNC［12］快速截取屏幕［13］。視頻編碼采用了FFmpeg［14］提供的 H.264編解碼器。

實驗中在測試全局壓縮和局部壓縮時使用的是同一段視頻。測試流程如下：0－20s在Word中進行文本編輯，20－45s非全屏播放視頻（大小為480＊270），45s以后播放器最大化的全屏模式（大小1024＊768）。部分壓縮算法在非全屏模式下檢測到的大小為490＊270，全屏播放檢測到的大小為1020＊636（視頻為16：9寬屏），視頻在未最大化播放時，高頻區(qū)域的傳輸幀率為25幀/s，最大化后，由于每幀壓縮時間的增加，幀率下降到15幀/s左右。實驗結果如圖4和圖5所示，實線代表局部壓縮算法，虛線代表全局壓縮算法。

在文本編輯時，網絡帶寬很低，因為此時并沒用啟動視頻壓縮，VNC仍然工作在其原有的模式（VNC模式）上，因此該階段的CPU利用率也會較低。當開始播放視頻（20s）時，帶寬急劇增加，此時VNC還是工作在其原有模式，檢測模塊此時還沒有確定正處于視頻播放模式，大約1～2s后VNC將采用混合遠程傳輸模式，帶寬也隨之降低，與此同時，由于壓縮算法耗費大量的CPU資源，CPU利用率也將大幅度提高。從圖4和圖5中可以看出，在20～45s（非全屏播放視頻）之間，采用部分壓縮將比全屏壓縮節(jié)省大量的帶寬，由于壓縮數(shù)據(jù)量少，CPU利用率也明顯低于全局壓縮算法。45s以后由于播放器已經最大化，此時局部壓縮的區(qū)域已經接近于整個屏幕，因此其帶寬和CPU利用率也趨近于全局壓縮。

5 結束語

本文對VNC在視頻傳輸方面現(xiàn)有的一些解決方案進行了介紹，并在混合遠程傳輸方案的基礎上提出了一種局部壓縮方法，然后在TightVNC上實現(xiàn)了該方法并進行了實驗。實驗結果表明，在非全屏播放視頻的情況下，采用局部壓縮在網絡帶寬和CPU利用率方面都將明顯優(yōu)于全局壓縮?；旌蟼鬏敺桨甘且誀奚薈PU資源，換來了網絡帶寬的降低，同時也需要客戶端有相應的解碼硬件支持。在實際應用中，我們應當權衡CPU和帶寬兩者之間的優(yōu)劣，選取合適的方法。另外，在混合傳輸方案中并沒有涉及音頻傳輸，如何將音頻同步流暢地傳輸?shù)娇蛻舳?，將成為下一步的研究重點。

［1］Deboosere L，De Wachter J，Simoens P，et al.Thin client computing solutions in low－and high－motion scenarios［C］.Proc IEEE Third International Conference on Networking and Service，2007：38－43.

［2］Richardson T.The RFB protocol［EB/OL］.http：//www.realvnc.com/docs/rfbproto.pdf，2011.

［3］LIU Zhi.Cross－platform remote monitoring and control technology study and design based on RFB protocol［D］.Beijing：Beijing University of Chemical Technology，2009：8－22（in Chinese）.［劉治.基于RFB協(xié)議跨平臺網絡遠程監(jiān)控技術的研究與實現(xiàn)［D］.北京：北京化工大學，2009：8－22.］

［4］YANG Maolin，CHENG Weiming.Design and complementation of hierarchical network surveillance system based on H.264［J］.Application Research of Computers，2006，23（4）：155－157（in Chinese）.［楊茂林，程偉明.H.264在分層網絡視頻監(jiān)控系統(tǒng)中的應用研究［J］.計算機應用研究，2006，23（4）：155－157.］

［5］Cynthia Taylor，Joe Pasquale.Improving video performance in VNC under latency conditions［C］.International Symposium on Collaborative Technologies and Systems，2010：26－35.

［6］De Winter D，Simoens P，Deboosere L，et al.A hybrid thin－client protocol for multimedia streaming and interactive gaming applications［C］.Proceedings of Network and Operating Systems Support for Digital Audio and Video.Newport，Rhode Island，USA：Association for Computing Machinery，2006：86－92.

［7］Simoens P，Praet P，Vankeirbilck B，et al.Design and implementation of a hybrid remote display protocol to optimize multimedia experience on thin client devices［C］.Proc IEEE Telecommunication Networks and Applications Conference，2008：391－396.

［8］RTP Payload format for H.264［EB/OL］.http：//tools.ietf.org/html/rfc3984.2011.

［9］YANG Chao，SHEN Ruiming，WU Zongming.Design ＆implementation of an efficient screen CODEC based on MPEG－4［J］.Computer Engineering，2005，31（21）：180－182（in Chinese）.［楊超，申瑞民，吳宗明.基于MPEG－4的高效屏幕編/解碼器的設計與實現(xiàn)［J］.計算機工程，2005，31（21）：180－182.］

［10］Tan Kheng－Joo，Gong Jia－Wei，Wu Bing－Tsung.A remote thin client system for real time multimedia streaming over VNC［C］.IEEE International Conference on Multimedia and Expo，2010：992－997.

［11］TightVNC［CP/OL］.http：//www.tightvnc.com，2011.

［12］Mirage Driver for TightVNC［CP/OL］.http：//www.demoforge.com/dfmirage.htm，2011.

［13］NI Xiaojun，ZHENG Long.Adaptive screen capturing algorithm based on mirror driver［J］.Computer Engineering，2011，37（11）：281－282（in Chinese）.［倪曉軍，鄭龍.基于Mirror Driver的自適應屏幕錄制算法［J］.計算機工程，2011，37（11）：281－282.］

［14］FFmpeg SDK［CP/OL］.http：//bairuitech.com/html/ruanjianxiazai/20070812/51.html，2011.