我在做一个通过网络传输远程桌面的小程序,采用的是截屏转换为JPGSTREAM然后进行传输,不过尽管进行了50%的质量压缩每一桢的画面仍然是80~90K,这对于512Kb的ADSL普通用户来说真是要了命的大小,就算每秒种一桢传输起来也是够呛。本人学习编程纯属个人爱好加上学的时候学习的专业根本没有数字课,我虽然知道可以通过XOR进行异或运算,取得前后二桢的差异后再进行传输还原会减少数量传输量,无奈实在想不出具体的计算方法。不知道可有高人愿意指导一下?
本人刚刚上手DELPHI不足三个星期,之前一直是VB,和VB.NET忠实用户,所以还请大家多帮忙!
谢谢!

解决方案 »

  1.   

    512Kb的ADSL 你也可以减少截屏的频率
    那个图片算法不懂
      

  2.   

    就是图像压缩的预测算法嘛,屏幕分成若干块,每块单独传送。
    传送的是每块当前帧与前一帧的差值(你可以直接用对应像素的RGB去减),这样屏幕变化小的时候每块的差值就包含大量的0或者很小的数字,可以获得很高的压缩比。
      

  3.   

    你去盒子的网站找一下DGScreenSpy_0.4c这个源代码,就是采用分块的思路。速度比较不错,我以前的软件也是参考这个源代码写的
    http://www.2ccc.com/article.asp?articleid=5284
    盒子上的东西挺不错的,有空上上,一定会对你有所帮助。
      

  4.   

    以下是我个人想法,做了简单测试,效果还不错。
      {服务端}
      BitBlt({初始帧}, 0, 0, bmp1.Width, bmp1.Height, {当前帧}, 0, 0, SRCINVERT);{XOR}
      png := TPNGObject.Create;{这里采用png格式压缩数据,或者jpg}
      png.Assign({初始帧});
      {服务端}
      {将png形式的压缩的差异数据传输到客户端...}
      {客户端}
      {差异帧}.Assign(png);
      BitBlt({初始帧}, 0, 0, bmp2.Width, bmp2.Height, {差异帧}, 0, 0, SRCINVERT);{XOR}
      {客户端}
      {还可以通过调节bmp.PixelFormat、jpg.CompressionQuality、png.CompressionLevel进一步降低传输的数据量}
      

  5.   

    DELPHI版好人真多啊!感谢大家帮助,看来我要好好的学学DELPHI.
    4楼的兄弟,我下了盒子上的源码,说实话对于我一个DELPHI新人来说完全看懂真的有不少困难里面太多WIN API而且还有ASM,但是很感谢你的帮助。
    7楼的兄弟,非常感谢我马上来试试你的方案开始来混,真的非常感谢你们!
      

  6.   

    想等我做出来再结贴,不好意思再等等,我已经大概的看明白了。说实话.NET的managed code我比较喜欢跟API打交道我相当的头疼。