捐赠 | 广告 | 注册 | 发布 | 上传 | 关于我们    
  沪ICP备05001939号 DELPHI盒子 | 盒子论坛 | 盒子文章 | 盒子问答悬赏 | 最新更新 | 论坛检索 | 下载中心 | 高级搜索    
  精品专区 | 繁體中文 | 奖励公告栏 | 直通车账号登陆 | 关闭GOOGLE广告 | 临时留言    
 
广告
评论:远程屏幕传输 (差异截图)
dldengli 61241 2013/9/11 15:19:14
多年后又看到了这个,回头再看看,我热衷与技术但最终没有成为技术大神,还是因为自己比较浮躁了,也许正象有人说的“在真正的成熟到来前,我们需要在迷茫和阵痛中多一些耐心和自省”。
wskc 42054 2012/1/1 22:20:47
一帮牛人
286251099 39406 2010/1/12 1:24:35
楼上有些东西说的是那么回事 只是火气大了点
ljmenglong 36794 2009/2/18 15:21:24
条条大路通罗马,各位大虾,这样大吵大闹真是有失身份.程序本来就是为人服务的,能满足自己的要求就OK.代码每个人都有自己的风格,并不是大家都要和你一样才算好.
本人认为aizjcn确实是有点过分.
kfo2046 35230 2008/8/9 1:55:03
讨论很精彩,不过最有启发的是 :如果娶个老婆可听的懂自己在说什么就真是算人生一大快事了
ljf 30468 2007/7/21 1:54:32
aizjcn 小时候一定没好好学习。满篇的错别字不说、写出的语句没有几句通顺的。小学生写的作文都比你写的帖子通顺。
chiru 29997 2007/6/16 17:19:45
哎~~~真是热闹!一个屏幕传输引发的血案。

还是WSDGS中肯啊~~~~~~
liudinglong 29619 2007/5/25 16:31:44
啊啊啊???
liudinglong 29618 2007/5/25 16:27:21
这是什么地方啊???
怎么讨论这么激烈呢???
tom_hanks 27918 2007/2/3 14:37:48
作差异的比较时不妨先转为黑白图象.
myhhs 27374 2006/11/30 9:07:47
现在牛一点似乎都用mirror driver.据说速度快,CPU占用低,那位能介绍一下.
luckygame 27026 2006/11/7 5:41:56
今天查了下邮箱,都快爆了,一看竟然全是这里的回复,于是把盒子所发的邮件拉黑,从些清静。无论如何我非常讨厌aizjcn这类垃圾,佩服138soft这种高手。
学技术先学做人,不管你aizjcn的技术如何如何高,首先你的人品非常垃圾,不知道现实生活中的你是怎么样的,我想你一定会常常碰钉子的那类人,犯众憎那类,好好检讨下吧。
说句实话,你在这里骂人一点用也没有,气的只有你自己。明白不?你的话对我不起任何作用!那怕你再骂luckygame这个ID n遍,气的绝对不是我。
如果你对我的话很介意的话,那么,请容许我说你垃圾
wsdgs 26933 2006/11/1 1:52:21
看了变天热闹,没意思,雷声大,雨点小,讨论了半天还是在差异对比上,在下不才,虚心请教:
1、算法上现成的压缩算法没有改进的余地?屏幕画面具有色相单一,色块较大的特殊性,屏幕桌面是固定不动的色块位置,压缩字典不可以做一些针对优化?
2、吵了半天都是无损静态压缩,只提到了JPG,为什么不考虑MPGE4,H264?当然,对于屏幕传输,帧间压缩同样具有特异性,可以针对优化(CPU?不错,这些压缩算法CPU占用比较高,可以改进啊!MPGE4也不是最好的,目前还没有专门的屏幕传输算法呢,要求服务端占用资源少,和目前的一些压缩算法理念是相反的)
3、网络传输上没有优化余地?RA和VNC还有个不同,一个是UDP,一个是TCP,对于屏幕传输,UDP发挥的余地当然更大一些,把容错控制在用户可以接受的范围内,而没必要像TCP一样精准无误。
4、压缩传送不能智能化?非要在一个思路上吊死?既然各种思路算法各有所长,为什么不选取几种在不同的网络环境中使用呢?

不知两位是来传道的呢?还是来争斗的呢?若是传道而来,自当洗耳恭听,若是争斗,不妨一笑泯之,留下我的QQ号:82317916
hke 26909 2006/10/30 17:49:16
要是能参考VNC的截图方法就好了
人家也是开源的
不过代码是C++的
wealsh 26898 2006/10/29 22:03:56
对比算法是不太好,打开任务管理器,最小化,在最右上角随便点一下鼠标右键,两张图片就相差不远了。
dldengli 26842 2006/10/26 14:57:28
小丑也好菜鸟也好,虽然你们在这里讨论的是远程高效率屏幕传输,但请注意已经跑体了,“分 类:图形”虽然我是用远程来演示差异截图,但我并没有说我写的是最快最高效率的屏幕传输,aizjcn你掌握的BMP图象的那点知识不是想贬你,我早在99年就在搞,我是做电子电路设计的,当时做盗版电子产品一般都会用到BMP2PCB的软件,为了研究这东西我花了1年的时间当然其间走了很多弯路,但这并不是说就是坏事,正是这样我对BMP的结构有了很深刻的了解,你在远程偷窥上的研究可能是很厉害,但领域不同个领域的高人实在太多,高效率大图片区域比较我和你条你接吗?还是那句霍元甲里的那句话“在擂台上以命相搏是中国人的一个漏习惯,但我们国人也有另外一种习惯叫以武会友”。
aizjcn 26838 2006/10/26 4:19:09
PS:今天过的很过瘾;有的东西你和别人说别人也不明白;和明白人说话心情就是舒畅啊;开天亮了;吃夜宵;如果娶个老婆可听的懂自己在说什么就真是算人生一大快事了;
aizjcn 26837 2006/10/26 3:48:03
"说句题外话,不知道你工作了否.否则劝你最好把写程序当作一个爱好.因为这个行业实在是非常辛苦的.如果让我重新选择,我不会选择计算机."

PS:我从2001点到现在都没有工作过;每天都对着计算机;我没有工作原因很多;只能说我环境比较特殊;不用工作;所以我每天的时间都在电脑上;除了电脑我的生活很单调;我是学计算机专业本科毕业的比你的起点或许要高一点点;但是我这本科一样的找不到工作;或者说环境不同不需要工作;但是你佩服你的经历;说实话我还真的没有留意你以前发表的文章的时间;你提起了;我才注意到;算我的错;以前在富翁我也做过同样荒唐的事;抱歉
aizjcn 26836 2006/10/26 3:39:06
"如果没有用到算法;那么是否说明就是内存比较的模式的延伸呢?" 对.
Zlib其实不是好的压缩算法,因为对于复杂图像,它的压缩率非常低.你可以做个试验:1024X768X24位色,抓下的图像大小就是1024X768X24字节(如果保存为文件,还要加上文件头结构之类).你分别抓两幅:一幅是桌面没背景的,一幅是有背景的,保存为BMP.大小应该是一样的,然后随便找个压缩算法,例如直接把文件压缩成ZIP或RAR.差别却很大.
然后,你再分别把这两张BMP压缩成JPG.再来和之前的ZIP或RAR比较.有桌面背景的情况下,JPG压缩率比它们都要高.
为什么我那DEMO比RA的CPU消耗少和占用内存小?其实是我耍了个花招.就是测试的时候是选择没背景(服务器本身也不用设置背景).这种情况下,ZLIB的优势出来了,就是CPU占用少.但是如果测试有背景的话,差别就出来了.RA会变得非常非常慢,而使用ZLIB压缩算法的DEMO,根本就无法传输第一幅.因为压缩后都差不多700多K.所以RA之所以占用CPU是有原因的,因为它要考虑到有桌面和无桌面两种情况.选择折中的压缩算法.因为压缩算法其实无非是CPU运算(压缩算法的实质是把很多相同的内容用一个东西表示.例如123123123123123可以直接用A来代替.这时候就需要个字典来表示A代表什么.不同算法又有固定字典,或动态生成字典.还有压缩内容中是否带字典.除了字典方法外,还有一种就是树了,根据压缩内容找出最短路径的树.但是压缩其实都是数学计算,所以肯定消耗CPU)

PS:看完你的解释对你的看法好点了;首先我有点怀疑你是不是正版但是问题说到这里了;只论技术;
Zlib是无损压缩;JPG是有损压缩;我曾经花了一个星期的通宵来看国外的相关资料;在国内很少;最近的只到2003年;大多是2001-2002的资料;同时我怀疑你是否正版的原因是你好象对自己发过东西没影响;首先内存比较模式是把相同数据用固定的符号填充;你原版代码中包括了BMP头部;如果用0填充,这样的出的数据只是000000000010000000000200000000001这样的形式;只能用Zlib压缩;JPG压缩对这样的数据根本无能为力;反之如果你复杂的再还原出BMP保存为JPG只是加大了数据传输量;和你最初的思路完全不相符合;全0的压缩用Zlib或者别的算法;在静态桌面下结果一样;相差不会过1KB;在动态的图象压缩时;用Zlib和你说的一样CPU站用非常厉害;所以你考虑到JPG这样的图象专用的有损压缩;这样的方法很好;但是这样必须抛弃简单的内存比较;捕捉动态的改变区域;也就是2者结合;如果只是在传输第一幅图象上使用JPG;后面的数据进行起来很麻烦;因为JPG是有损的;这就是你推出动态区域捕捉的新想法的目的?但是这样的改变对服务端本身的处理要求就很高;除非你控制每秒的帧数;我以前测试过只要把屏幕图象控制在3-6帧以下Zlib压缩不用JPG;一样看不出CPU使用率;对于肉眼来说根本没有太大的差别;中间控制帧数的延时就应该是显示快慢的的比较了;如果整理一下思路;应该能做出很好的屏幕传输程序;休息了;
138soft 26834 2006/10/26 1:07:17
要想提高编程水平,除了个人天赋外(其实每个人的天赋不会差别太大,而且勤能补倔),找到正确的方法是很重要的.
(1)佛家有"所知障"的说法.意思是已有的知识会阻碍一个人接受新的知识.但是阅读高手的代码仍然是提高自己水平的一个最好最快的方法.特别是在初期."假传万卷书,真传一句话."其实很多东西,点穿了就一句话而已.
(2)遇到问题多找资料.不过现在网络那么发达,找资料实在是太容易了.当年我读大学的时候,才刚刚开始有网络,上网要坐1个小时车到华中科技测距大学门口的电脑城,ISDN龟速还要6块钱一个小时.我本身农村出身,费用实在是太吃力了.幸好后来发现投稿可以赚钱(那些文章就是那时候写的了),终于减轻一点负担.我当初发表了一些文章,还有做过很多免费共享软件,无意中慢慢的积累了点名声.但是其实这是无心插柳而已,而且早期一个人想成名是很容易的.不象现在高手满天飞.一条街道就能找到一打.
(3)多动手写代码.这是最重要的.也是最快速的提高水平的办法.我刚开始的时候,还没学PASCAL,就自己动手写Delphi了.现在想起来都觉得大胆.然后遇到问题马上找资料.只有带着问题找答案,才能给你留下深刻的印象.迅速提高水平.
(4)多和志同道合的人交流.如果你在正规大学计算机系.那么这点就不用担心了.我当初那民办学校,10个人9个只懂玩游戏,你学程序,上进一些,还会被排挤.千方百计给你阻力.真是惨.不过倒可以锻炼心理承受能力.
不过上面四点,我只做到第三点.早期做到第二点.
说句题外话,不知道你工作了否.否则劝你最好把写程序当作一个爱好.因为这个行业实在是非常辛苦的.如果让我重新选择,我不会选择计算机.
第一页 上一页 下一页 最后页 有 59 条纪录 共3页 1 - 20
 用户名:
 密 码:
自动登陆(30天有效)
 
  DELPHI盒子版权所有 1999-2012 V3.01 沪ICP备05001939号 更新RSS列表