刘 坚，余 综

（华北计算技术研究所，北京100083）

0 引 言

VNC（virtual network computing）是剑桥大学AT＆T实验室设计开发的一款优秀的远程桌面控制软件，它允许用户通过一个简单的客户端软件（VNC viewer），在有互联网的任何地方，控制另一台安装了服务端软件（VNC server）的计算机。用户通过VNC可以在本地控制远程计算机，从而实现了在远程计算机上办公、对远程计算机进行诊断和维护等功能，这给用户和计算机管理员带来了极大的方便，因此VNC也越来越受到人们的广泛关注。然而随着多媒体技术的发展，利用VNC远程观看高清视频、玩3D游戏成为了人们的新需求，在这些场合下，桌面环境变化大、变化频率快。而VNC由于网络带宽及其所采用的请求－应答－请求模式的限制，使得客户端收到的帧率无法达到视频流畅播放所要求的帧率，在客户端看到的图像就如同幻灯片一样，无法给用户提供流畅视频图像［1］。即使达到所要求的帧率，传输的数据量也非常大，对于一般的网络环境而言是无法承受的，这也对VNC提出了新的挑战。

本文对现有的一些解决方案进行了深入的研究，并在其基础上提出了一种改进的混合传输方案。该方案通过一种启发式算法计算出桌面上的视频区域，然后将视频区域经H.264压缩再传输，从而减少了视频在非全屏播放时的网络带宽及CPU利用率。

1 VNC编码技术

VNC采用的通信协议是RFB（remote frame buffer）协议，RFB协议是一个简单的远程图形传输协议，它不依赖于具体的图形接口，因此在所有的窗口系统（X11、Windows、Mac等）和应用程序中都可使用［2］。RFB协议中的编码方法主要包括Raw、Copy Rectangle、RRE、Hextile和 ZRLE等方法［2－3］。

Raw编码是最简单的编码类型，这种编码方式下，屏幕上的像素点简单地从左到右扫描，然后发送到客户端。除非客户端要求其它编码类型，否则服务器端默认采用Raw编码。

Copy Rectangle编码通过使用客户端缓冲区中的数据，让RFB协议在某些情况（如窗口移动等）下变得很高效，因为这时客户端已有了待传输的数据，因此只需将更新区域的坐标发送给客户端，然后客户端在缓冲区中相应位置拷贝即可。

RRE（rise－and－run－length）编码 的 思 想 就 是 将 像 素 值相同的矩形区域作为一个整体传输，从而减少了传输的数据量。RRE编码首先传输的是一个背景色Vb（屏幕上最常用的像素值）和一个矩形计数值N，然后是小矩形块，每个小矩形块的信息包括矩形的左上坐标、高度、宽度以及一个前景色值。在客户端显示时，先填充背景色，然后再在每个小矩形区域填充对应的前景色即可。RRE的解码效率较高，可以减轻客户端的处理负担。

Hextile是RRE编码的变种，Hextile编码把整个屏幕分割成一个个16x16的小片，如果屏幕的宽度（高度）不是16的整数倍，那么最后的小片也相应减少，小片遵守从左到右，自上而下的顺序。每个小片采用的编码方式可以是Raw编码，也可以是RRE编码的变种。

ZRLE（Zlib run－length encoding）编码结合了zlib压缩、分片、调色板和run－length编码等技术，在传输时，首先传输的是一个4字节的长度值，紧接着是该长度的zlib压缩数据。每个RFB连接使用的是一个单一的zlib流对象，因此ZRLE编码的矩形必须严格地按照顺序进行编解码。

上述VNC所采用的这些编码方式的特点是编解码速度较快，但压缩率不高，这些编码对于用户一些普通的使用（如查看文件、浏览网页等）来说，能够工作得很好。但在需要界面高速变化的场合，如观看视频，界面的刷新需要达到每秒25帧左右，由于VNC Viewer采用的单线程模式，使得每秒接收的帧数远小于25帧，即使是达到25帧每秒，服务端向客户端发送的数据将达到几十兆每秒，这也是网络环境无法承受的，因此必须采用一种高压缩率的编码方法。2003年3月，ITU－T/ISO颁布了H.264视频编码标准［4］，就能满足高压缩率的要求。H.264视频标准不仅使视频压缩比以往所有标准有明显提高，而且具有良好的网络亲和性，特别是对IP互联网、无线移动网等易误码、易阻塞、QoS不易保证的网络视频传输性能有明显的改善，由于其相比以往标准的出色的性能，被称为新一代视频编码标准。与 H.263或 MPEG－4相比，在同样质量下，其数码率能降低一半左右；或者说在同样码率下，其信噪比明显提高。因此可以在VNC中引入H.264来降低传输多媒体数据时带来的网络带宽。

2 VNC多媒体传输方案

针对VNC在多媒体数据传输中的缺陷，目前主要有两类改进方案，一类是采用缓冲机制将所要传输的数据先缓存在服务端，然后再传输到客户端，另一类方案是在服务端采用一种高压缩率的编码（如MPEG－4、H.264等）方法，先在服务端将桌面图像数据高度压缩，然后将压缩数据通过网络传输到客户端，客户端再完成解码、图像的显示等。

对于第一类方案，Cynthia Taylor等人［5］通过在客户端和服务端之间增加一个消息加速器来实现，如图1所示。消息加速器与VNC服务端位于同一个局域网或同一台计算机中。由于在VNC中，采用“请求－响应－请求”模式，即只有当一个请求消息达到服务器端得到响应将数据发送到客户端，客户端完成显示后才会产生下一个请求消息，这也意味着客户端每秒能得到响应数也就是用户每秒所能看到的帧数，但由于网络以及服务端、客户端处理的延时，使得客户端的请求信息无法快速得到应答。消息加速器通过缓存客户端的请求信息，由于消息加速器和服务端在同一局域网或同一台机器上，两者之间的传输速度较快，且在加速器中也不需要完成图像的显示，因此当消息加速器把请求消息发送给服务端后，可以很快的得到应答，从而达到了加速的目的。加速器和客户端则可在速度较慢的网络环境下通信，数据更新响应信息可以比较稳定地在消息加速器和客户端之间传输。

图1 VNC消息加速器

对于第二类方案，在文献［6－7］中都采用了一种混合远程传输模式，即在普通情况下，VNC仍然采用其原有的RFB协议进行通信，将其称之为VNC模式（VNC Mode）。当桌面处在需要快速变化的环境中时，切换到流模式（streaming mode），在流模式下，VNC服务端可采用H.264对桌面进行压缩形成视频帧，然后再通过RTP（real－time transport protocol）协议［8］传输到客户端，客户端再完成解码显示，具体流程如图2所示。缓冲机制虽然能够加速客户端得到的应答，但网络带宽并没有减少，在视频传输时的数据量依然很大，对网络的依赖性很强，而且很难达到实时的效果。H.264编码虽然能提供很高的压缩率，减少了带宽，但在原始数据量大时，它的编解码过程将消耗大量的CPU资源，同时也会增加带宽。Pieter Simoens在文献［7］中提出的混合远程传输方案在切换到视频流模式时，把整个桌面图像作为输入，而人们在平常使用中，如在浏览器中观看视频时并没有全屏观看，整个桌面实际上只有一小部分是高速变化的视频区域（高频区域），其它区域仍然处在静止状态（低频区域）。实际上只需要压缩高频区域，而桌面的低频区域仍可通过VNC原有的压缩方式进行通信。这样既可以减少视频流的数据量，降低网络带宽；同时也能降低CPU的负载（这对于计算能力比较弱的瘦客户端来说是极为重要的）；也能够避免一些静态的文字内容等，由于视频有损压缩而带来的失真［9］。在文献［10］中，提出了一种检测高频区域的解决方案——动态图像检测方案（dynamic image detection scheme，DIDS），该方法是通过X－server与X－client的交互检测出高频区域，但该方案最大的缺点是只能在X－windows系统中使用。对于非X－windows系统，如 Windows系统，该方案就无法实现。我们接下来将提出一种工作在帧缓冲级别的检测方法。

图2 混合远程传输

3 混合远程传输协议的改进

我们将在文献［7］提出的方案的基础上加入一种高频区域检测的方法，首先介绍一下文献［7］中的方法。在文献［7］中从VNC模式切换到流模式，他们提供了一种启发式的算法。首先使用变量changemon来标识是否需要切换模式。当检测到屏幕上变化的像素点大于某一个阈值（检测像素点数量的5%）时，changemon的值线性增加，反之，则指数级减少，当changemon的值达到设定模式切换的阈值（MAX＿CHANGEMON/2）时，VNC切换到相应的传输模式。相反，在流模式下当changemon的值从MAX＿CHANGEMON减少到接近0时，VNC切换到原有的传输方式—VNC模式。这样既可以有效地避免由于最大、最小化窗口时瞬间引起的桌面图像的变化给模式切换带来的误判，同时也能快速准确地切换到流模式。在该方案中的另一重点是如何选择待检测的像素点，既要能够客观地反映屏幕上的当前状态，又要使得每次比较的时间尽量少。检测屏幕上所有的像素点虽然可以完全反映屏幕的情况，但这样效率低下，在混合远程传输方案中采用的是每隔一定数量的像素点进行采样，采样方法如图3所示。

图3 像素点采样

上述方案在切换到流模式后将压缩整个桌面，称之为全局压缩法；我们在上述方案的基础上加入一种启发式的方法去检索高频区域，压缩的数据也只有高频区域的像素点，我们称之为局部压缩法。我们方案是：对于每个待检测的像素点i都有一个计数值p［i］，每次检测时，当该像素点i的像素值与上次检测的一致，p［i］减一，最小为0；当像素值与上次不一致，p［i］的值加一，最大为32。在高频区域，每次检测时，其各像素点的像素值基本上都是变化的，因此位于该区域的像素点对应的p［i］的值都应大于低频区域的像素点，我们只要选取合适的阈值PIXEL＿THRSHOLD来判断各像素点所处的位置。由于在文献［7］的方案中，由于changemon每次增加的值为MAX＿CHANGEMON/32，也就是说混合远程传输协议从VNC模式切换到视频流模式只需16次检测，因此位于高频区域的监测点的p值应该大于等于16，而处于低频区域的像素点的p值很小（接近于0）。考虑到视频区域的有些像素点在16次检测中存在没有变化的情况，判断某像素点是否位于高频区域内的阈值应低于16，在实验中PIXEL＿THRSHOLD取值为10。当某像素点对应的p［i］的值大于等于10时，就可认为该像素点处在高频区域内。在像素点的检测过程中，我们只要分别比较记录下从上下左右4个方向每个检测点的p［i］值，当第一次碰到p［i］的值大于等于10时，就可认为该像素点为高频区域的上下左右边界，该上下左右边界围成的矩形区域即为高频区域，在切换到流传输模式时，我们只要将该高频区域经H.264压缩后传送的客户端，而低频区域我们仍然采用VNC的编码方式（Raw、RRE、Hextile、Tight等）传输。

像素点的选取同样采取间隔采样法。间隔采样法选取的像素点原则上应尽量少，这样可以减少检测时间，从而使每秒发送的帧数能达到25帧左右。但在我们的方案中，为了能够准确地判断视频区域的位置，间隔距离不宜过大。在试验中，我们选取的间隔值为12。当然间隔值的减少会带来检测时间的增加，我们采取的方法是适量减少检测的次数，在文献［7］中采用的是每隔40ms检测一次，在我们的方案中每隔100－120ms检测一次，第五部分的实验结果表明，这样能够有效的检测出高频区域的大小，同时也能保持帧率，模式切换的时延也能控制在2s左右。在高频区域大小的选取上，我们采用了宁大勿小的原则，也就是说在检测到高频区域的宽度上适当扩充1到2个间隔距离。具体的流程如算法1所示。从中可以看出，每个检测像素点p值的统计是在每次计算变化的像素点时得到的，因此并没有增加原有算法的时间复杂度。

算法1：

分别记录上下左右4个方向p［i］值第一次大于PIXEL＿THRSHOLD的像素点位置；

由这4个像素点围成的矩形区域即为高频区域

模式切换判断（详细算法参见文献［7］）

End

4 实验与结果

为了验证改进后算法的效率，我们在Windows XP平台下通过修改TightVNC源码［11］实现了该算法，并进行了测试。实验过程主要针对文本编辑、非全屏播放视频和全屏播放视频3种应用情况，并分别在全局压缩和部分压缩算法下，对此3种应用环境下的网络带宽和服务端的CPU利用率进行了统计。实验环境如下：服务端配置为处理器Intel Q9500四核CPU，主频2.83Ghz，内存2GB，客户端处理器为Pentium E5400双核CPU，主频2.7Ghz，内存2GB，网络环境为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宽屏），视频在未最大化播放时，高频区域的传输帧率为25帧/s，最大化后，由于每帧压缩时间的增加，帧率下降到15帧/s左右。实验结果如图4和图5所示，实线代表局部压缩算法，虚线代表全局压缩算法。

在文本编辑时，网络带宽很低，因为此时并没用启动视频压缩，VNC仍然工作在其原有的模式（VNC模式）上，因此该阶段的CPU利用率也会较低。当开始播放视频（20s）时，带宽急剧增加，此时VNC还是工作在其原有模式，检测模块此时还没有确定正处于视频播放模式，大约1～2s后VNC将采用混合远程传输模式，带宽也随之降低，与此同时，由于压缩算法耗费大量的CPU资源，CPU利用率也将大幅度提高。从图4和图5中可以看出，在20～45s（非全屏播放视频）之间，采用部分压缩将比全屏压缩节省大量的带宽，由于压缩数据量少，CPU利用率也明显低于全局压缩算法。45s以后由于播放器已经最大化，此时局部压缩的区域已经接近于整个屏幕，因此其带宽和CPU利用率也趋近于全局压缩。

5 结束语

本文对VNC在视频传输方面现有的一些解决方案进行了介绍，并在混合远程传输方案的基础上提出了一种局部压缩方法，然后在TightVNC上实现了该方法并进行了实验。实验结果表明，在非全屏播放视频的情况下，采用局部压缩在网络带宽和CPU利用率方面都将明显优于全局压缩。混合传输方案是以牺牲了CPU资源，换来了网络带宽的降低，同时也需要客户端有相应的解码硬件支持。在实际应用中，我们应当权衡CPU和带宽两者之间的优劣，选取合适的方法。另外，在混合传输方案中并没有涉及音频传输，如何将音频同步流畅地传输到客户端，将成为下一步的研究重点。

［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协议跨平台网络远程监控技术的研究与实现［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在分层网络视频监控系统中的应用研究［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的高效屏幕编/解码器的设计与实现［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.