邹航宇

0 引言

桌面共享系统是一种同步交流工具，广泛应用于网上虚拟教室系统。在WEB2.0时代，通过浏览器的桌面共享系统，参与的用户可以分享自己的桌面，从而达到资源共享的目的。在虚拟教室中，常常的情况为老师需要面对多个学生，网络情况也极为复杂，因此对系统的性能与健壮性提出了更高的要求。本文就将论述桌面共享系统的实现架构以及性能的优化。

1 系统设计

1.1 部署

屏幕共享系统组件的配置架构，如图1所示：

图1 共享桌面组件架构图

客户端采用Adobe Flash Player，目前应用范围最广泛的丰富互联网应用程序(RIA)。Flash Player通过实时消息协议(RTMP)，连接到开源流媒体服务器Red5所提供的应用服务。

RTMP协议是一个基于TCP的，在Flash player与服务器之间进行音视频流媒体传输的专用协议，能够保证链接的持久稳定，通讯的实时顺畅。RTMP可以封装MP3或AAC格式的音频，以及FLV格式的视频等流媒体，也可以通过AMF进行异步的服务器端远程程序调用。其默认端口为1935。当1935端口无法连接时，Flash Player可以通过变种RTMP Tunneled隧道协议，将RTMP网络包封装在Http网络包中，再通过80端口的Http服务器Nginx进行中转。Nginx是著名的开源轻量级网页服务器，相比Apache具有内存占用少，稳定性高，并发能力强的特点。

Red5是对应Adobe官方Flash Media Server的一款开源流媒体服务器，能够提供多用户音视频流的优秀解决方案，适合不同规模的企业级应用。Red5由Java语言开发，建立在Jetty(servlet engine), Mina(network)基础之上，并通过Spring框架整合起来[3]。

1.2 系统架构

桌面共享系统作为网络虚拟教室系统的一个模块，运行在浏览器中的adobe flash Player中。因此，整个系统分为客户端部分与服务器端部分。客户端部分负责抓取屏幕，将截屏图像封装为视频，再将视频转化为兼容 Red 5服务器和Flash Player客户端的编码格式，发往服务器端。虽然Red 5与Flash支持包括 F4V、FLV在内的多种音视频流格式，但考虑到Red 5的API仅支持FLV格式的视频流录制[16]，为了将来功能拓展的需求，FLV无疑是视频流的最佳选择。如果在这两个阶段中再次从外部引入第三方的编码组件，显然这样会再次带来额外的不可控因素，也不符合完全自有实现的预定目标。

幸运的是，Adobe官方提供的FLV视频文件规范中，提供了一种简单可行的实现思路。屏幕视频比特流的帧编码格式，如图2所示：

Screen Video BitStream Format(svc1)是一种无损的Codec，因此这种编码方式会成为系统的瓶颈之一[4]。

服务器端收取客户端发来的视频帧，暂存到flv临时文件，供各客户端通过RTMP协议进行连接、下载和播放。

1.2.1 源客户端设计

要从系统客户端，也就是Flash Player上启动屏幕摄录功能，一个最常用的办法就是使用 Java Applet。利用 flex与JavaScript之间的通信，调用JavaScript函数，在JS中启动applet。在Java.awt库中的Robot类，正好也提供了API函数可以调用，即 createScreenCapture()方法，便捷地执行屏幕截取，返回 BufferedImage。接着将整个屏幕的BufferedImage通过GetRGB()方法转换为AGRB像素格式的Int[]。Int[]中原本从左到右、从上到下的像素遍历顺序不符合屏幕视频比特流的规范，必须转变为从左到右、从下到上的顺序，并随之完成分块过程生 Queue格式的块队列。队列中的每个块需要依次从各自ARGB像素数据中抽取出符合BGR像素顺序的信息，交java.util.zip库Deflater类，完成ZLIB格式的数据压缩。最后使用固定端口与服务器端的Share Svc建立TCP连接后，依次传输队列中转码后的块数据。TCP正文的头部只需简单加上标示字符，以筛除无效数据包。

1.2.2 服务器端的设计

在服务端，FLVGen事先将flv的辨识头信息以及为0的前项容量信息以字节流的方式写入一个flv临时文件，完成了流数据传输的准备工作。当接收端从 TCP正文还原出屏幕更新数据后，FrameGen将依照 flv格式要求，依次将flv类型（视频明文为0x09）、时间戳、流标示符（恒为0）、实际荷载和总数据量写入数据流，并暂存到flv临时文件，供各客户端通过RTMP协议进行连接、下载和播放。

2 系统优化

2.1 瓶颈分析

屏幕摄录已经在在上一节中给出了基础实现，然而其实际测试效果比较一般。Applet的截屏操作基于主讲人的整个屏幕，生成的所有BufferedImage数据需要完整地进行转码、压缩和传输，客户端的运算负载和网络带宽需求相当可观。特别是考虑到在以ADSL为主的当前国内网络环境中，数据上传的效率受到更多限制，上传网络包可能出现堆积，发送端不得不进行主动丢包，以保持视频的实时性。当然，可以通过降低截屏的帧率，从源头上控制数据量，但和主动丢包一样，客户端视频的刷新率会降低，延时会增长，进而影响用户体验。

根据前文的叙述，客户端的数据的上传使用的是Screen Video Codec 1 Format。Screen Video Codec 1 Format是无损的压缩方式，桌面数据经过压缩以后达 2.0M，显然我们系统的性能问题已经非常明显，显然对于实时系统，每帧的到达2.0M,这是不能接受的。

因此，系统性能的优化核心在于源数据的量，经过我的分析可以从以下三个方面降低源数据的量。

2.2 优化方式

2.2.1 关键帧技术

由于在实际的虚拟教室共享桌面系统中，桌面大部分时候为静止状态。如果源端不停的截屏并往服务器端上传数据，会导致过多的无用数据，造成带宽的浪费。在前文叙述的SVC中，屏幕视频比特流（Screen Video BitStream）的每一帧被划分为类似网格的一系列块。块的尺寸上限为长宽各 256个像素。块的顺序从左下角按行排列直至右上角，如图 3所示：

图3 块的顺序图

通过块的尺寸与整个图像的尺寸，解码器可以简单计算出屏幕边缘块的实际尺寸，进行准确地像素绘制。像素信息在实际编码和传输时，采用了ZLIB开源格式的压缩。

当applet程序从客户端每一次截取屏幕，则会被程序转变为从左到右、从下到上的顺序，并随之完成分块过程生成Queue格式的块队列。块队列里存的就是如图3所示屏幕比特率的分块数据。在大部分时间里，屏幕信息并不会发生变化，即时变化，也很有可能变化的只是整个屏幕中的一部分，也就是所有块中的一部分。因此对Queue队列中所存储的每个小块图像计算一次哈希值，暂存在内存中。除首次截屏的第一帧之外，后续帧的在完成分块后，将使用新计算出的哈希值与原哈希值进行比对。如果值相等，可以判定该图像块在两帧之间没有发生变化，不必对其执行后续的BGR抽取与ZLIB压缩操作，并直接从队列中删除此块。如果哈希值不匹配，则需要为变化的图像执行原算法操作。上传时相应的需要在 TCP正文头部添加块的编号信息，供服务端在接收后，恢复对应的局部图像。最终FLVGen生成flv视频时，也使用一个队列缓存每个图像块转码压缩后的数据。如果 TCP正文中缺少某块的更新数据，则FLVGen判定此图像块没有更新，使用缓存的前一帧中对应块数据填充进FLV视频流。反之如果包含某块的更新数据，则需要在填充FLV视频流的同时更新缓存队列。

在这种设计下，客户端必须多执行一次哈希计算，换取的收益是可能减少执行转码、压缩和传输的数据量。如果屏幕共享的内容是画面时刻变化的电影等，那么采用新设计的收益可能会非常有限，多执行的哈希计算甚至会使得客户端性能出现下降。不过在日常应用中，屏幕共享的内容变化速率一般比较慢，演示时更多的是屏幕关注点的部分更新。因此采用优化设计可以有效地精简冗余的数据处理与传输。

2.2.2 压缩方式

前文提到，系统使用的是 adobe公司官方提供的 FLV视频文件规范中Screen Video BitStream Format(svc1)编码，而 SVC1编码虽然简单，但却属于无损压缩方式。对于1440*900左右的分辨率，经过 SVC1的压缩后，桌面数据大概达到2M。对于每一帧，尽管可以改变帧与帧的更新策略，但是原始桌面数据太大，当桌面信息频繁发生变化时，数据量会陡然变大，从而导致系统性能急剧下降。因此，改变压缩方式，减小源端每一帧的数据量，定能大幅提高系统性能。

Adobe官方提供了另外一种 codec，即 Screen Video Codec 2 Format(SVC2)。SVC2比SVC1在压缩效率上有了很大的提升，SVC1只支持24Bit的RGB bitmap,而SVC2支持16bit RGB555和RGB565，SVC2采用了颜色表，颜色表是一个长度是128的颜色数组，Flash decoder里面有对应默认的颜色表，相比SVC1而言，SVC2只要求传一个byte（8个bit）的index来代表一个颜色，显然数据量减少了一半，而这些128长度的颜色表能够表达大多数颜色，因此命中后的颜色，数据大小将减少一半。改变codec后，原本大概2M的数据量，可以减少为500KB左右，大大减小了桌面频繁变化时数据量的传输[4]。

2.2.3 分辨率问题

分辨率问题是系统必须讨论的。考虑这种情况，如果教师端的屏幕为 1440*900，而学生端的屏幕为 800*600,1024*768等不同的分辨率。在源端 applet截屏后，得到的截屏BufferedImage为1440*900的分辨率，如果就这也传输到学生端，在学生端1024*768的显示器上，将不能完全显示。也就是有一部分像素点浪费，同理在800*600的显示器也会出现相同的情况。因此，在客户端显示器分辨率不统一的情况下，对源端上传的BufferedImage做一定程度的压缩不仅能减少数据量，并且能满足不同客户端的需求。对1024分辨率以上的屏幕，做一个缩略，缩减为800像素。这样大多数情况下，数据量可以变为原来的0.6左右，大大减小了数据量。

2.3 性能分析

以分辨率为为1440*900的屏幕为例分析优化前与优化后性能的改善。Applet每 200ms对屏幕进行一次截图，那每秒会得到5个1440*900的BufferedImage，经ZLIB压缩后每个 BufferedImage为 3MB，则需要的传输速度为15MB/S。显然现有的网络条件不可能达到这样的速度，这是不能接受的。

首先将SVC1的编码格式改变为SVC2的编码格式，构造一个大小为128的颜色数组。因此在编码后的Image每个像素的大小从SVC1时候的4byte变为现在的1byte，意味着总的数据量变为 1/4，此时需要的传输速度骤减为3.75MB/S。根据更新策略，假设视频教室中，PPT的翻页速度平均为30秒一次(老师讲课时时间远远不止)，则30秒内的最坏情况为页面上每一块都进行过更新，即每30秒需要传 2次屏幕的所有像素约为 1.5MB，则平均每秒为51KB/S。再进一步经过图像的缩小，使所有的帧转化为800*600帧后，只需要31.25KB/S。对于这个上传速度，正常情况下的网络条件都能满足，因此经过优化的桌面共享系统具有了一定可用性。

3 结论

基于RED5的WEB桌面共享系统，是WEB2.0时代典型的 RIA应用，在网络教学中教师与学生的信息的交流与互动上具有优势。系统应用 RTMP网络通信协议，实现Screen Video Codec 2 Format(SVC2),部署 Red5，Nginx，Applet等服务组件，实现了一个用户体验良好，性能强大，健壮的Flash/Flex RIA程序，能很好地满足网络教学应用的实际需求。

[1]陈旭玲，刘苏. 基于 JAVA的网络教学电子白板的设计与实现[J]. 计算机技术与发展，2006.4(16): 167-169

[2]刘璐，董小国.Red5 Flash服务器研究. [J]网络安全技术与应用，2009.6:78-79

[3]Adobe Systems Incorporated. SWF File Format Specification Version 10[S]. 2008