远程屏幕图象实时传输的原理与实现

摘要:本文就当前的热点远程屏幕图象的抓取及其在网络上传输过程进行了详细介绍,并针对目前这类相关软件中普遍存在的网络带宽过大,实时性差,占用系统资源过多,稳定性差等问题侧重在屏幕图象的抓取与位图数据流的压缩,解压缩两方面提出了较为有效的解决方法,并提供了改进与实现的Delphi代码.本文将对于现有此类相关软件的完善及今后相关软件的研发具有非常重要的指导与参考价值.
关键词:屏幕图象 屏幕抓取 实时传输 网络传输 数据压缩
一, 前言
目前,随着计算机网络的不断推广运用,基于计算机网络的应用软件的研发也就成了众多的软件企业与科研机构的主要研发热点之一.在这些应用软件当中,基于计算机网络的远程实时控制,管理软件因其具有极其广泛的应用领域如网络多媒体教室,网络管理与控制,网络服务,在线技术支持等,所以它具有有非常良好的发展前景与商业价值.虽然目前已经有一些相关的软件产品,但普遍都存在占用网络带宽过大,实时性差,占用系统资源过多,稳定性差等问题,究其原因就在于在远程屏幕图象在网络上传输这个关键技术环节上问题解决的不够理想.
本人经过长期的反复研究与实践,终于找到了一些方法能够很好地解决远程屏幕图象网络传输占用网络带宽过大,实时性差,占用系统资源过多,稳定性差等关键问题,为这类软件研发中的远程屏幕图象在网络上传输提供一种非常有价值的可供参考的解决方法,以下便就此展开叙述与探讨.
二, 远程屏幕图象在网络上传输过程
一般这类软件都采用典型的Client/Server结构,由客户端与服务端两部分构成.客户端主要是负责向服务端发出获取服务端屏幕图象的请求与将从服务端发送而来的屏幕图象在本地实时地显示出来,而服务端主要是负责响应客户端的请求并抓取与发送屏幕图象.由于服务端所抓取的屏幕图象一般为位图格式,其数据量较大,若直接发送则会导致占用网络带宽过大,实时性差,占用系统资源过多,稳定性差等问题,因此需经过压缩后才能将其发送给客户端,而客户端相应地也要将接受到到屏幕图象数据进行解压缩后才能正确地将屏幕图象显示出来.
解决目前普遍存在的问题的关键就在于屏幕图象数据的压缩与解压缩和屏幕图象的抓取上.对于屏幕图象数据的压缩与解压缩这一点,主要追求的是较高的压缩率与较快的压缩与解压缩速度,这可以通过选取一定的压缩与解压缩算法如Huffman,RLE,LZW等来实现,已有的这类软件也非常注重这一点,因此目前这一方面的提高余地已非常有限.对于屏幕图象的抓取这一点,很多这类软件在研发过程中却不够注意甚至是忽略了所选取的屏幕图象抓取方法的重要性,而采用了常用的一般的抓取方法.其实,屏幕图象的抓取与数据的压缩与解压缩一样重要,都将对屏幕图象的实时传输过程产生极其重要的影响,因此这一方面尚有较大的提高空间,本文也就此着重进行详细的阐述.
三, 屏幕抓取与传输方法及其改进实现
1. 屏幕抓取模式的选择
屏幕抓取模式有多种,如在Delphi中可用的抓取模式CopyMode有cmSrcCopy,cmSrcInvert,cmWhiteness等15种.当采用cmSrcCopy模式时,则直接将待拷贝的源位图拷贝至目的画布中,目前普遍的处理方式便是采用这种抓取模式抓取整个屏幕图象,然后直接将其进行压缩.而若采用cmSrcInvert模式时,在服务端则先将目的画布中已有的位图与待拷贝的源位图位值进行XOR异或运算后,然后将运算所得的位图进行压缩,相应地在客户端显示时,应将解压后的位图位值与当前的位图位值进行XOR异或运算,则运算所得的位图便是服务端当前所传送的屏幕图象.虽然后一种屏幕图象抓取方法比前一种分别在客户端与服务端多了一步位图位值XOR异或运算,但是经压缩后,采用后一种方法数据量一般比前一种方法的数据量要小得多.这主要是因为一般情况下屏幕图象总是在一个局部而非整个屏幕发生变化,将当前屏幕图象与上一屏幕图象进行XOR异或运算后,所得屏幕位图未变化部分的位值将为0,而变化部分的位值为1,当屏幕图象变化范围较小时,则所抓取的屏幕图象位图的大量位值将为0,同时压缩率除与压缩算法有关外,还与待压缩的数据本身有关,因此这样对其进行压缩将取得更加理想的压缩效果. 虽然采用两种抓取模式所获得的屏幕图象数据都一样,但从采用采用WinZip压缩后的数据量来看,cmSrcInvert 模式下的压缩数据量明显小于采用cmSrcCopy模式的压缩数据量.本人在测试时使用的是Delphi5.0中自带的一个数据流压缩,解压缩解决方案Zlib.pas和 Zlibconst.pas两个单元文件来解决数据压缩,解压缩问题,实现了很高的数据压缩率(较WinZip高),所得的测试结果也与上表的结果相近.这就说明采用cmSrcInvert 模式将比采用cmSrcCopy模式在传输屏幕图象数据时占用少得多的网络带宽.

下一页