劉 堅(jiān)，余 綜

（華北計(jì)算技術(shù)研究所，北京100083）

0 引 言

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

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

1 VNC編碼技術(shù)

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

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

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

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

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

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

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

2 VNC多媒體傳輸方案

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

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

圖1 VNC消息加速器

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

圖2 混合遠(yuǎn)程傳輸

3 混合遠(yuǎn)程傳輸協(xié)議的改進(jìn)

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

圖3 像素點(diǎn)采樣

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

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

算法1：

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

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

模式切換判斷（詳細(xì)算法參見文獻(xiàn)［7］）

End

4 實(shí)驗(yàn)與結(jié)果

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

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

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

5 結(jié)束語(yǔ)

本文對(duì)VNC在視頻傳輸方面現(xiàn)有的一些解決方案進(jìn)行了介紹，并在混合遠(yuǎn)程傳輸方案的基礎(chǔ)上提出了一種局部壓縮方法，然后在TightVNC上實(shí)現(xiàn)了該方法并進(jìn)行了實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果表明，在非全屏播放視頻的情況下，采用局部壓縮在網(wǎng)絡(luò)帶寬和CPU利用率方面都將明顯優(yōu)于全局壓縮。混合傳輸方案是以犧牲了CPU資源，換來(lái)了網(wǎng)絡(luò)帶寬的降低，同時(shí)也需要客戶端有相應(yīng)的解碼硬件支持。在實(shí)際應(yīng)用中，我們應(yīng)當(dāng)權(quán)衡CPU和帶寬兩者之間的優(yōu)劣，選取合適的方法。另外，在混合傳輸方案中并沒有涉及音頻傳輸，如何將音頻同步流暢地傳輸?shù)娇蛻舳?，將成為下一步的研究重點(diǎn)。

［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é)議跨平臺(tái)網(wǎng)絡(luò)遠(yuǎn)程監(jiān)控技術(shù)的研究與實(shí)現(xiàn)［D］.北京：北京化工大學(xué)，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在分層網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)中的應(yīng)用研究［J］.計(jì)算機(jī)應(yīng)用研究，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的高效屏幕編/解碼器的設(shè)計(jì)與實(shí)現(xiàn)［J］.計(jì)算機(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的自適應(yīng)屏幕錄制算法［J］.計(jì)算機(jī)工程，2011，37（11）：281－282.］

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