[发明专利]云计算环境中通过混合使用RFB和H.264编码提高虚拟桌面显示质量的方法

说明书

技术领域

本发明涉及云计算应用领域，尤其是一种云计算环境中通过混合使用RFB和H.264编码提高虚拟桌面显示质量的方法，其显著特点是服务端根据屏幕内容的更新率动态切换使用RFB或H.264编码方案，将屏幕内容流化发送到客户端，以提高客户端虚拟桌面的屏幕显示质量。

背景技术

虚拟桌面是云计算的一种应用，其特点是应用程序都在服务器上运行，而屏幕显示却在远程的客户端机器上。

在计算机技术中，屏幕所显示的内容来自一个“帧缓冲区（Frame Buffer）”，也可以称作“画面缓冲区”，缩写为FB。在计算机上运行的程序将需要显示的内容写入帧缓冲区，显示器则按每秒25次或30次、即每秒25帧或30帧的速率将帧缓冲区的内容逐个像素地显示在屏幕上。之所以是每秒25帧或30帧，是因为人的视觉在这么高的速率下才能感到画面上显示的动作连贯平滑而且不闪烁。注意屏幕内容的更新速率与帧的速率不是同一回事，即使内容长时间保持不变，显示器仍是按每秒25帧或30帧的速率刷新。

在云计算环境中的虚拟桌面应用中，服务器上运行着多个虚拟机,每个虚拟机对应着一个客户端,运行客户端用户的程序，因此每个虚拟机、也即每个用户都有一个独立的FB。但是具体用户的客户端及其显示器却在远地，所以在远地的客户端上也需要有一个“远地FB”、即RFB，这个RFB中的内容应该从服务端FB复制过来并频繁加以刷新，与服务端FB保持一致。这样，如果在服务器上为用户运行桌面系统，例如Windows，那么用户在远地的客户端上看到的就是一个桌面，好像所面对和操作的客户端就是一个桌面系统一样，所以叫虚拟桌面。但是，对于客户端计算能力的要求却可以比真正的桌面系统大大降低，成为一个很“瘦”的客户端，其成本连同所占用的服务端虚拟机也可以比一台真正的桌面系统低。

但是，要把服务端FB的内容复制到客户端FB中却非易事，倘若按每秒25帧的速率每秒复制25次，屏幕的分辨率为1024x1024，每个象素24位，则所需的带宽为：

25x1024x1024x24=600Mbps=75MB/s

这样的带宽要求，对于现今的网络显然是不现实的，所以必须加以压缩。压缩的方法主要有两类。一类特别适合一般的计算机应用，就是那种屏幕内容相对稳定、较少变化,但是对所显示内容的保真度却要求很高的应用，例如文档的编辑，文字性网页和图表的显示等等。另一类则特别适合“活动画面”的显示，例如电影、电视等等的播放,人类对于活动画面的保真度要求相对较低。

上述的第一类方法就称为RFB，其基本的方法已经标准化成为RFC-6143。其思路是：服务端FB与客户端FB之间的复制必须是高保真的,但是只需要在内容有变化的时候才需要，而且每次都只需要传送所变化的那一部分，不妨称之为Δ复制。进一步，对于变化了的那部分画面内容还可以进行基于像素“跨度（Run-Length）”等方法的无损压缩。这样，尽管客户端的显示器还是按每秒25或30帧的频率刷新屏幕，但是对于客户端FB的内容复制更新的频率却可以很低，占用带宽也可以很小。特别是对于办公一类的应用，人们在屏幕上阅读时很可能好几秒钟才需要变更一下画面的内容，而且每次变更的幅度一般都很小。但是，如果是高清播放电影和视频，情况就不同了,活动图像的更新一般比较频繁,变更的幅度也往往比较大。市面上有许多基于RFC-6143的产品，其牌号名称各不相同，但是所采用的基本技术都是一样的，只是有些产品（如开源软件VNC）采用RFC-6143中所述的CopyRect方法，即每次都通过比对找出画面上那些内容有变化的大小不一的矩形块；有些产品则采用RFC-6143中所述的TRLE方法，把整个画面固定划分成许多矩形的“瓦片（Tile）”，每次刷新那些有变化的瓦片。

在实用中，RFB方法对于屏幕内容相对静止而较少变化的应用效果很好，但是对于电影、电视、动画等活动图像的高清播放就效果不好，因为这些画面的内容变化很快、而且很可能是几乎所有的“瓦片”都在变化，这样一方面可能每一帧都需要传送，另一方面每一帧的传输量都可能很大，这就使得传输过程中实际上必然发生丢包，使显示效果大大下降。因此，RFB不适合电影、电视节目的播放，这对于现下计算机使用者的普遍要求当然很不适应。不仅如此，实际上RFB对于办公类的应用也未必都合适，例如一个网页上有许多图片，如果观看时要在屏幕上左右或上下平移（Pan）画面，这些图片就在一定程度上变成了活动图像，此时的带宽要求也会陡然上升，使效果变差。