徐 扬，赵晓森，高宇翔，王志谦

（北京邮电大学 网络技术研究院，北京100876）

随着网络的普及，各种应用软件层出不穷，运行应用需要足够的计算能力和存储空间，很多瘦终端已经无法满足当前应用所需的处理能力，正面临被淘汰的局面。然而，云计算有着超强的计算和存储能力，将瘦终端通过网络接入与云计算的优势结合在一起，应用程序本身不在终端上运行，只需要将人机交互数据传送到云端实际运行应用的服务器，云端服务器将应用的计算结果（即屏幕的更新）返回到终端[1]。这使得用户能够不受终端设备的限制即可获得极高的用户体验，同时带来了多方面的优势，如解决应用的兼容性问题，节省二次开发成本，实现应用的集中管理和控制等。本文的主要工作是讨论如何将应用图形用户界面（GUI）传输给终端，提出一种应用远程显示的方法，并对该方法进行验证。

1 相关工作

随着人们对瘦终端发展的重视，现在市面上已经存在许多可供选择的瘦客户端解决方案，例如X，Microsoft Remote Desktop，Citrix MetraFrame XP，Virtual Network Computing（VNC），GoToMyPC等。然而，这些解决方案都是成熟的商业产品，客户端一般只针对计算机和智能手机，存在一定的限制[2]。

X把所有的用户界面处理交给客户端，以此来提供远程显示，由于应用的显示逻辑和运行逻辑通常是紧耦合的，那么在客户端处理用户界面的同时应用逻辑运行在服务器端，这样会带来客户端与服务器端的持续同步。此外，客户端用于处理应用显示界面的视窗服务软件比较复杂，并需要频繁更新，随着用户界面越来越丰富多彩，将会给客户端带来更加复杂的处理压力。

Microsoft Remote Desktop，Citrix Metra Frame XP，VNC避免了在客户端运行复杂的视窗服务软件的情况，所有的应用和图形用户界面都在服务器端运行，客户端相当于一个简单的输入输出设备。客户端本地保存一个用于刷新显示的帧缓存副本，当应用发出显示命令时，服务器处理这些命令并通过网络发送屏幕更新来生成新的客户端本地帧缓存。GoToMyPC简化为用原始的像素值来表示显示更新，从服务器帧缓存中读取像素数据并编码压缩（即屏幕截取），然后发送给客户端。屏幕截取是一个简单的过程，它从发送给客户端的应用显示更新中解耦合了显示命令的处理。服务器做了所有的应用显示命令到像素数据的转换工作，客户端可以变得非常简单。但是，仅由原始像素值组成的显示命令需要更多的传输带宽。

2 一种基于X Window System的应用流化方法

为了最大化应用的跨平台性，采用类似GoToMyPC的思想，提出一种基于X Window System的应用图形用户界面（GUI）流化方法。将应用在云端服务器上运行后的GUI抓取下来，然后通过实时编码压缩后以视频流的方式传送给客户端，客户端解码呈现应用GUI，从而实现应用的远程显示。

2.1 FFmpeg和H.264简介

FFmpeg是一个集录制、转换、音/视频编解码功能为一体的完整的音频和视频流开源解决方案。FFmpeg支持MPEG，DivX，MPEG4，AC3，DV，FLV等40多种编码，以及AVI，MPEG，OGG，ASF等90多种解码，很多优秀的开源播放器如VLC，MPlayer等都用到了FFmpeg。FFmpeg源代码中主要有以下4个常用库 文 件：libavcodec，libavformat，libavutil和libswascale。其中，libavcodec是目前领先的音/视频编解码库，用于存放编解码各种类型音视频的模块；libavformat主要用于存放各种音视频封装格式的muxer/demuxer模块；libavutil包含一些公共的工具函数，用于存放内存操作等常用模块；libswscale主要用来处理视频图像的缩放[3]。

由于抓取的原始视频数据量很大，对带宽要求高，因此有必要在网络传输前对这些数据进行压缩。根据视频基础知识，同一幅图像中的像素之间具有较强的相关性，两个像素之间距离越近，相关性越强，空间冗余越大。同样，帧与帧之间也存在这种相关性，称之为时间冗余。通过消除空间和时间冗余就可以达到压缩的目的，减少数据量[4]。H.264是由VCEG和MPEG联合制定的一套最新的视频压缩标准，它同时采用以上两种方式来进行数据压缩，其编解码流程主要包括5个部分：帧间和帧内预测、变换和反变换、量化和反量化、环路滤波、熵编码。H.264分两层结构：视频编码层（VCL）和网络抽象层（NAL）。VCL的主要任务就是用高效的编码方式进行视频数据压缩，NAL则根据网络的特性对数据进行封装打包，使其适于网络传输[5]。与之前的视频编码标准相比，H.264具有更高的压缩比率、编码性能和图像质量，在相同视觉感知质量上编码效率比MPEG-2和MPEG-4提高了50%左右[6]，同时具有很好的抗误码能力和网络适配性，可以很好地适用于实时通信。

对于H.264协议的编解码来说，FFmpeg能很好地解码，而编码需要调用X264编码库。X264摒弃了一些对编码性能提升很低但计算复杂度很高的模块，降低了计算的复杂度。FFmpeg只需要在配置选项中选择--enable-libx264就可添加对X264编码库的支持，从而实现H.264编码。

2.2 应用图形界面的流化过程

本文的应用流化方法基于X Window System（X11或X）。X Window System是一种位图显示的视窗系统，它是在Unix和类Unix操作系统上建立图形用户界面的标准工具包和协议，并可用于几乎所有已有的现代操作系统。根据前文所述的方法流程，将其分为视频采集模块、压缩编码模块和封装传输模块3个模块。

1）视频采集模块：根据客户端的选择启动并运行应用，利用应用的进程号PID查找得到应用的窗口ID。首先调用X11函数XOpenDisplay（）得到默认的display指针，然后调用XDefaultRootWindow（）返回默认屏幕的根窗口，通过函数XInternAtom（）来获得PID属性的Atom，从根窗口开始查找，调用XGetWindowProperty（）返回窗口对应的PID与已知PID比较，若相等则找到应用窗口；若不相等，则递归查询子窗口。然后，根据窗口ID，调用X11函数XGetWindowAttributes（）返回应用窗口的属性到结构体XWindowAttributes中，该结构体包含窗口的宽度、高度、位置坐标等属性。最后，根据窗口信息调用X11扩展库MIT-SHM提供的XShmGetImage（）函数持续抓取指定的应用窗口图像直到关闭应用。

2）压缩编码模块：FFmpeg调用X264编码库对抓取后的视频进行H.264编码。FFmpeg首先调用av_regsiter_all（）注册编解码器，然后调用transcode_init（）初始化编码器，其中avcodec_find_encoder（）函数的参数设置为CODEC_ID_H264，即使用H.264编码，设置codec-＞time_base.num，codec-＞time_base.den，它们的比值为帧率。

3）网络传输模块：RTP协议能对流媒体数据进行封包并且实现媒体流的实时传输，本方法采用IP/UDP/RTP协议层次结构。H.264视频流的组包需要适应网络的MTU，否则可能无法检测数据是否丢失。以太网的MTU为1 500 byte，IP头至少为20 byte，UDP头至少为8 byte，RTP头为12 byte，所以RTP的最大载荷为1 460 byte，如果RTP的载荷数据大于1 460 byte，在IP层就会将其拆分为几个小于MTU尺寸的IP分组，这样会导致无法检测数据丢失[5]。对于大尺寸NAL单元，在数据装载进RTP分组之前就要进行拆分；如果RTP载荷过小，协议头部所占的比例将增大，这会增大网络的开销，所以可以把几个较小的NAL单元合并在一个RTP分组中传输。首先将编码后的数据流进行缓存，接着找到每一个NAL单元的起始地址，根据每个NAL单元大小采用以上讨论方式进行封装后，发送至客户端。

3 方案验证

本方案验证的硬件环境为Intel T6600 2.2 GHz CPU，2 Gbyte DDR2内存，NVIDIA GeForce G105M显卡，操作系统为Ubuntu Linux 12.04LTS。通过流化Firefox浏览器图形界面对本方案的可行性进行了验证，并简单地测试了该方案的性能。

测试按照25 f/s（帧/秒）采集2 min，浏览器窗口大小为640×480（单位为像素），流化后视频的平均码率为304.8 kbit/s，视频画面清晰流畅，无明显延迟效果。原始应用界面和流化后的效果如图1所示，其中图1a为服务器端应用的实际显示，图1b为服务器上的模拟客户端接收到的画面，两幅图是同时被截取的，为了估计出流化过程产生的延时，在浏览器中启动了一个秒表，通过这样一个直观的时间显示，粗略估计出流化过程的时延。采集的10组时间样本如表1所示，最后得到平均时延约为85.6 ms。由于服务器和客户端是在同一台计算机上运行，几乎不存在网络传输时延，所以该延时可表示整个流化过程和客户端解码显示图像的总时间。可以预见，这个延时在硬件配置更高的机器上将会更短。测试结果表明该方法延时低、占用网络带宽较大。

图1 实际应用显示和流化后的显示（截图）

表1 采集的时间样本

4 小结

瘦终端具有简单、低成本、低功耗等优势，本文提出了一种将应用GUI转换成视频流的流化方法，该方法降低了显示应用GUI对瘦终端计算能力的要求，具有良好的跨平台性，为应用在瘦终端上远程显示提供了一种切实可行的方法。笔者后续将会进行瘦客户端对服务器应用远程控制的研究工作。

[1]KIM J，BARATTO R，NIEH J.An application streaming service for mobile handheld devices[C]//Proc.IEEE International Conference on Services Computing(SCC).[S.l.]∶IEEE Press，2006∶323-326.

[2]BARATTO R，KIM L，NIEH J.THINC∶a virtual display architecture for thin client computing[C]//Proc.The 20th ACM Symposium on Operating Systems Principles(SOSP)书S.l.]∶ACM Press，2005：277-290.

[3]胡聪，周甜，唐璐丹.基于FFMPEG的跨平台视频编解码研究[J].武汉理工大学学报，2011，33（11）：139-142.

[4]王永刚.3G视频监控系统中H.264编码实现与应用软件开发[D].杭州：杭州电子科技大学，2011.

[5]盛先刚.基于RTP的H.264视频传输系统研究[D].西安：西安电子科技大学，2006.

[6]王嵩，薛全，张颖，等.H.264视频编码新标准及性能分析[J].电视技术，2003，27（6）：25-27.