INTENET屏幕极速传实匿.doc

INTENET屏幕极速传输开发文档目录 一:传统的屏幕传输方法与缺点 二:极速屏幕传输的方法与实现 三:程序流程图与细节 四:后记 附录: 一:压缩方法简介 二:传统的屏幕传输方法代码 三:服务端客户端公共代码列表 网络极速屏幕传输开发文档 一:传统的屏幕传输方法与缺点 传统的屏幕传输采用的是这样的方法: 抓取屏幕--?传输--?显示图像,此为完成传输一幅的过程.不断重复此过程即可实现屏幕监控.但是这种方法因为图像数据容量大,而网络实际信道容量是有限的,所以效果很不理想,具体表现就是每幅图像之间间隔时间长.后来发展到抓取屏幕-?压缩数据-?传输-?解压缩-?显示图像.这样做速度的确有所提高.但是在INTENET上面效果仍然不好. 二:极速屏幕传输的方法与实现 针对上面的情况,我们研究屏幕图像后发现,实际应用中屏幕变化的时候经常变的只是一小部分区域.有时侯(比如说浏览文本文件的时候)屏幕根本不作任何变化.而传统方法只是机械的重复传输整个屏幕的内容.如果我们每次只发送变化的区域部分,那么速度就会显著提高. 在INTENET上面的测试结果如下:客户端:(湖北武汉)ISDN64KB上网局域网接入. 服务端:中山大学宽带接入的.服务端屏幕800X600X256色.屏幕变化不大的时候(比如说在用QQ在聊天),1~2秒钟可以看到一幅.如果变化大的话(比如说新开一个网页)要四秒钟甚至更长时间. 为了减少数据量,除了压缩图像外,可以先把图像转化为256色.我们使用了一个自定义函数来抓取屏幕然后转化为256色. My_GetScreenToBmp(DrawCur:Boolean;StreamName:TMemoryStream);注意函数里面的的Mybmp.PixelFormat:=pf8bit; 它的作用就是转化屏幕为256色图像. 关于如何比较:比如说我们第一副图像的数据为abcdefg,第二副图像数据为abcdefh,把数据相同的数据位标记为0,不同的记录下来.那么对比后可以得到第三副图像的数据为000000g.还原的时候,把第三副图像与第二幅图像比较,就可以得到第一幅图像数据abcdefg. 为什么比较后压缩数据会变小: .可以作个比较:一个文件全部为字符0,另外一个文件字符为不规则字符.压缩前两个文件一样大小,压缩后差别却很大.具体原理见附录. 下面是程序流程图:具体实现请参考代码. 四:后记 因为时间关系,很多地方没有做.还有需要改进的地方: 1:目前只是比较整个屏幕的变化.即使屏幕无变化的话也有几十个字节的数据量(全部为0).可以在发送前比较后作判断:如果无变化那么就发信息叫服务端重新输出原来的内容一次即可而不用重新传输一次. 2: 目前只是比较整个屏幕的变化.即使是屏幕某个小区域变化也把其它无变化的添加进去了.如果改为把屏幕切割称成为4X4块再比较的话速度更快.比如说现在屏幕只是第16块变化了一点,那么我们只要发送此块即可. 3:选择好的压缩算法.我们现在用的是LHARC压缩算法.我们知道:凡是压缩算法肯定是以牺牲CPU时间来达到目的的.LHARC算法不是最好的算法. 4:本算法只适应INTENET.因为,在局部网的话传输789KB的内容与传输536字节(不到1KB)速度是没有多大区别的.而且数据比较后还压缩.压缩就得占用时间.但是在INTENET上面,传输789KB跟传输536字节的区别是非常大的. 附录: 一:压缩方法简介 1、压缩（Encode）假设我们有一些数据：　　a b a b a b a b c d d d a a b c d b a　　怎么样才能使上面的数据变短呢？一般来说毫无规律的字符数据中经常回出现一些重复的串，象上面的“ab”“cd”，如果能将数据中重复出现的串用一个简短的代码表示出来不就做到了数据压缩了吗？但是我们并不知道到底哪些串会重复，难道要事先将所有数据扫描一遍吗？而且有这种情况，比如说当遇到“a b c d e”串时，到底是把它看成一个串还是将它分成“a b”+“c d e”或其它呢？　　有时候想得太复杂不是件好事，可以把事情想得简单一些，我们完全可以在逐个读入数据的时候动态创建一个表来记录数据中重复的串，考虑到我们输出的是代表相应串的代码，假设压缩的是一字节为单位的字符串，所以在建立表时必须先把0 — 255代表的单个字符先放到表中，保证在压缩的时候一定能找到重复的串（至少跟自己本身重复嘛），然后再根据逐个读入的字符来添加我们的表项。当然记录重复串的表不能无限扩大，当大到了一定程度必须将其清空重新来过，所以要保留一个表项（256）为表清空标识，另外为了让我们在解压的时候知道什么时候解压结