2011-07-21 10:44:53 来源:新浪博客
直至现在,云屏幕虚拟化仍然是云计算领域内进展不尽如人意的分支。相比之下,更加缺乏关注的领域是如何在云中利用虚拟屏幕,并将其与本地渲染能力相结合,通过各种不同的设备,提供相等甚至更好的用户体验,而不论其计算能力、渲染能力、带宽和屏幕分辨率的高下。图1描述了云-端计算概念性架构,其中的虚拟屏幕是在云中进行渲染的。屏幕的行为与数据和程序类似,可以根据云和客户端的具体能力状况,在两者之间进行自适应性和协作性处理。正如我们前面提到的,带有屏幕自适应(screen adaptation)功能的云-端架构可以提供以下好处:
通过笔记本电脑、电视和电话等各种不同的屏幕,为终端用户提供优化的互动体验;
为开发者简化编程模型,就像编写本地应用程序,而无需纠结于各种类型的实时数据通信;
通过虚拟机机制和屏幕远程处理能力,为软件供应商提供部署云软件服务的快速模型,例如,这种模型能够帮助快速??部署试用版软件,而无需担心盗版问题。[page] 现在,我们能否通过互联网,将屏幕作为一种实时服务交付给用户,实现近似本地的互动体验?屏幕作为显示图像,确实包含了大量的数据。幸运的是,它表现为图像序列时,其中存在很多可以有效去除的冗余成分。此外,带有全帧单元的屏幕刷新可以使客户端一侧的屏幕更新延迟变得相对固定。虽然多媒体、硬件和网络技术的突破指日可待,但我们在虚拟屏幕远程计算系统方面的最新进展表明,即便使用现有的技术,屏幕压缩和传输技术也可以做得非常高效。
虚拟屏幕的远程计算(Remote Computing with Virtualized Screen)
按照如图1所示的云计算概念结构,我们已经开发出一种能够利用交互式屏幕远程处理技术的瘦客户端远程计算系统。
(1)系统架构(System Architecture)
瘦客户端远程计算系统可以为最终用户提供高保真显示和高响应性的互动,就好像使用本地计算机一样。然而,复杂的图形界面和多媒体应用往往会向瘦客户端的开发者提出挑战:如何利用低带宽连接实现高效的传输。图2描述我们所提议的瘦客户端远程计算系统,该系统实现了应用程序逻辑(远程)和用户界面(本地)的脱钩,客户端因而能够使用作为云虚拟机部署的远程服务器。服务器和客户端之间通过互动屏幕远程处理机制,实现了网上双向沟通。客户端将用户输入发送到远程服务器,作为响应,服务器将屏幕更新返回给客户端。
屏幕更新模式决定了屏幕能否有效地压缩并传输到客户端。现有的瘦客户端系统,例如虚拟网络计算(VNC)(注2)和远程桌面协议(RDP)(注3),大多数情况下将屏幕更新表现为任意大小区域的基本图形。这种机制允许服务器简单地将需要更新的基本图形转发至压缩模块,而直接丢弃其它的稳定区域信息。在客户端,屏幕显示模块对所收到基本图形加以渲染,并覆盖指定部分矩形区域的像素。然而,需要更新的区域往往较小,而且可能出现在任意位置,如菜单或编辑框等。对这些小区域和任意位置进行编码,将导致系统受制于压缩效率的衰减。
图2:互动屏幕远程处理系统
与基于任意尺寸区域的架构不同,我们的瘦客户端系统采用了基于帧的屏幕表现模型(frame-based screen-representation model)。这种模型从帧缓冲区中一次性读取屏幕上的所有像素,并将整个屏幕图像送入压缩模块和传送模块。在客户端,屏幕显示模块将整个屏幕替换为新解码的屏幕。如图2所示,服务器和客户端存储着相同的参照帧,用于清除连续帧之间的冗余数据。除了在压缩方面的优势外,基于帧的屏幕表现模型还简化系统架构,免去了调度屏幕区域更新所需的固定带宽占用。此外,基于帧的屏幕表现模式还可以非常迅速地恢复由于丢包(packet loss)而导致的错误,无须通过关键帧刷新进行重传。
相对于VNC和RDP等现有的远程计算系统,我们所提出的解决方案能显着改善用户体验,它同时反映在屏幕更新和互动反应的平滑度上;而使之成为现实的,就是我们下面要介绍的高级屏幕压缩和传输技术。[page] (2)屏幕压缩(Screen Compression)
屏幕图像可能包括但不限于网页、幻灯片、海报、图像、视频以及其他任何显示在计算机屏幕上的内容。对于自然图片,许多现有的图像和视频编码标准(如JPEG2000和H.264/高级视频编码)已具有出色的编码性能。但是它们在屏幕图像压缩(大多数情况下包含富文本)方面的效率却不高。屏幕图像压缩所面临的挑战归纳如下:
计算复杂性(computational complexity)。屏幕编解码器不得不处理大量数据,以保持屏幕更新的高分辨率和高帧率。同时,编解码器还必须腾出绝大部分处理资源用于执行其它的常规应用;
压缩性能(compression performance)。组成屏幕图像的文本、图形和图片都有各自不同的特点和对编码工具的敏感性。屏幕编解码器必须在一个框架内有效处理各类数据,并同时维持较低的计算成本。
一般来说,典型的屏幕图像可以划分成四类区域:平滑、文本、图片和图片上的文本。根据我们的统计分析,平滑和图片区域更适合于变换域的编码;而文本和图片上的文本区域则更合适于像素域的有效压缩。为了简化编解码器的架构,我们提出了一种基于块的编码算法,它仅包含两种编码类型:图片和文本。文本块编码方案还包含“逃脱像素编码(escape pixel-coding technique)”技术,它专门用于处理“图片上的文本”区域内的背景图片像素。
图3:本文提出的屏幕压缩算法框架图
图3描述了我们所提出的屏幕压缩算法。捕获的屏幕图像被分割成互不重叠的16×16区块。与前一帧图像进行比较后,每个区块被都被识别为“可跳过”或“不可跳过”两类。接着,分类操作将不可跳过的区块划分成图片块和文本块,然后调用与这两类区块相关联的自适应编码方案。在区块分类中运用了统计梯度直方图(statistical gradient histogram)。100%准确的区块分类是几乎不可能的,因为“图片上的文本”区域本身是千变万化的。幸运的是,我们提出的“逃脱像素”编码方案可避免在分类失当的情况下避免画质损失,并仅有微小的码率增加。
这种屏幕编解码器在编码速度、质量和计算复杂性等方面的表现都超过了用于屏幕图像编码的传统自然图像和视频编解码器。编码和解码过程对GPU也十分友好。主流显卡的GPU加速能够轻而易举地使屏幕捕捉和编码的帧速率达到无GPU加速系统的两倍。[page] (3)屏幕传输(Screen Transmission)
在远程计算系统中,屏幕传输延迟可能是影响用户体验的最重要因素。由于屏幕图像是按照与视频类似的时间序列加以组织的,我们在其中利用了一些现有的视频传输技术。经过预测式编码的各帧之间具有强烈的相互依赖性,使得视频流对传输错误异常敏感。因此,必须运用一些缓冲和错误控制机制,这样,在固有的网络传输延迟以外,又产生了额外的延迟。
此外,互动屏幕远程处理(interactive screen remoting)对延迟的要求要比实时视频通信严格得多。例如,用户通常期望在点击某个按钮后,本地显示器立即做出反应,就像使用本地计算机一样。为了达到这一性能,要求云虚拟屏幕和本地设备显示器之间的快速往返消息处理以及几乎即时的更新速度。因此,现有的视频传输技术可能无法满足交互式屏幕远程处理场景的要求。
幸运的是,我们提出的屏幕编解码器并不会引起连续帧之间的高度依赖性,它可以在一定程度上缓解经过解码的屏幕图像中由传输错误引起的漂移误差??。此外,屏幕远程处理还具有与视频传输场景迥然相异的独特功能。例如,它并不需要每次都对整个屏幕画面进行更新。相反,一些出现问题的屏幕区域可以在得到信号时立即呈现。因此,有可能通过一些具有内容感知能力的调度方案来帮助最大程度地减少传输延迟。
图4:我们提出的屏幕传输算法框架图
图4描述了我们所提出的屏幕传输算法,其基础是屏幕压缩和传输的联合优化。屏幕图像处理分为三个层面:
在编解码器层面,屏幕图像编码通过一种灵活的切片结构(slicing structure),帮助客户端对隐藏了错误的屏幕进行重构。此外,屏幕解码器可以处理外出现故障的屏幕数据包,而不会产生漂移误差(drifting errors);
在控制层面,拥塞-失真优化算法(congestion-distortion optimization algorithm)可以调度发送缓冲区中的数据包。这些数据包的调度依据是其对网络拥塞和显示失真的影响程度。有些数据包可能会被丢弃,而不会对后续帧进行重新编码;
在传输层面,我们运用了带有自动重复请求的UDP传输协议,以平衡传输速率和错误控制。为了避免网络拥塞,我们利用TCP友好型速率控制器来估计可用带宽。
免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。