最初由 lady 发布
如果是单纯按CPU的主频来比较的话
1.6G的AMDXP,要比2.4G的一般P4快
不论压DIVX还是WMV9的都一样
原来也不相信,不过,事实最终打败了我
appleapple@2005-01-29 20:16
cpu的发展以经出现严重的高频低能现象！！！！！！曾半仙@2005-01-30 02:25
我知道你说的那种，现在还有利用快速网络进行的实时分布，不是基于广域范围的在家计算那种，当然也有人说这不是真正的分布计算，有悖于现有的利用慢速网络的情况，所以不通用，我倒是认为这就是可以解决以前的（受益软件）不通用的情况，虽然他要求的数据传输率高那是建立在不确定的传输量上，如果把数据的传输/广播等做在虚拟机和系统那一层，现在那些虚拟机里面和已安装系统交互都是比较成熟了（设备，共享，驱动等等），把任务细化到进程来看，例如压片更多的是依赖CPU的马力而不是超大内存，每一个进程所存取的内存并不多，发生变化的部分还要少一些，这样让存储端的CPU专门负责压缩和处理数据，每次将进程的单个线程的任务传输给计算端，时间到以后将内存的计算结果和计算现场传回存储端，偶认为只要调度得当，咱们的家用网络也能上阵，就现在的操作系统软件来说，这种降级了的结构只能用于支持多CPU机器的程序，也就是说不必要让软件自身将任务在时间向量上切割为几陀，也不必去关心软件怎么做，最后的表现肯定软件有多个线程，再根据线程的参数配给相应的计算能力，这就圆满了，Real 的编码器是支持多CPU机子的优化的，Xvid 的 nic/Centic driud 编译版本不知道支不支持，当然我说了一堆肯定会惹来人笑，例如那些签名一签就好几台P4P5银河深蓝的人，和那个躲在某xx所拿大型机玩传奇的人，我承认我玩不起高科技，但我相信实验技术的民用化相对与民用设备的败家化肯定是王道……lady@2005-01-30 02:31
如果是单纯按CPU的主频来比较的话曾半仙@2005-01-30 02:50
哀，还没回过来郁闷劲呢，楼上的贴跟的太残忍了，偶的机器就素那被打败的P4 2.4啊……66666@2005-01-30 09:04
引用最初由 lady 发布
如果是单纯按CPU的主频来比较的话
1.6G的AMDXP,要比2.4G的一般P4快
不论压DIVX还是WMV9的都一样
原来也不相信,不过,事实最终打败了我
bosch@2005-01-30 11:20
引用最初由 66666 发布
RV10除外:p
skywalker@2005-01-30 11:53
最近读了一篇关于IBM的cell处理器的文章, 觉得cell拿来压片真是太合适了.........66666@2005-01-30 12:17
现在X86也在向多核心发展，其实我觉得影响压片速度的因素很多，编码器的优化程度也是很重要的，如果对SSE2充分优化的话，K7和K8都不是P4的对手風之殤@2005-01-30 12:59
目前如果時脈(包括AMD的 +後的時脈)在2.8G之前的 AMD應該是勝出(單工而言)曾半仙@2005-01-30 13:12
现有的Xvid+VDM的2pass压片模式也是可以用一种原始的分布方式,虽然原始但是有效,做一些辅助的软件就可以收到较好的效果,将一台机作为中枢机,供片源,和提供客户端操作命令,然后压片机上都装上客户端,按照服务端的传来的脚本用VDM载入,Vdm的脚本里面可以实现选择相应的帧数范围,和1st pass参数等基本一切平时手工操作的,这时候的帧数分配可以是均分,然后几台压片机将1pass分块走完以后,得到的stat文件传回服务端,服务端将1pass的stat文件合并起来进行统计,然后再次根据编码难度,以场景转换等会出现关键帧的地方为最小分割单位,将任务分成几大陀,并且根据指定的2pass参数,微调每段的码率,写入脚本,和重新拆分的stat文件一起传过去,然后各压片机开工压制并,将压得的片子传回服务端,服务端用vdm脚本对片子进行合并,加音频,并上传到分流FTP,打开QQ和MSN向分流的同志们广播.skywalker@2005-01-30 13:20
其实对我来说, 拖慢速度的主要是filter..........adamhj@2005-01-30 19:48
引用最初由 曾半仙 发布
现有的Xvid+VDM的2pass压片模式也是可以用一种原始的分布方式,虽然原始但是有效,做一些辅助的软件就可以收到较好的效果,将一台机作为中枢机,供片源,和提供客户端操作命令,然后压片机上都装上客户端,按照服务端的传来的脚本用VDM载入,Vdm的脚本里面可以实现选择相应的帧数范围,和1st pass参数等基本一切平时手工操作的,这时候的帧数分配可以是均分,然后几台压片机将1pass分块走完以后,得到的stat文件传回服务端,服务端将1pass的stat文件合并起来进行统计,然后再次根据编码难度,以场景转换等会出现关键帧的地方为最小分割单位,将任务分成几大陀,并且根据指定的2pass参数,微调每段的码率,写入脚本,和重新拆分的stat文件一起传过去,然后各压片机开工压制并,将压得的片子传回服务端,服务端用vdm脚本对片子进行合并,加音频,并上传到分流FTP,打开QQ和MSN向分流的同志们广播.
这个土分布方案,应该可以有效地利用网吧,学校机房等廉价资源吧....
曾半仙@2005-01-30 20:58
你看一下开头说的部分,这不要手工设置的啊,vdm压的时候只要服务端传给他计算出参数的脚本就行,hellghost@2005-01-30 22:42
支持AMD，但压起来应该事P4快。MeteorRain@2005-01-31 16:58
引用最初由 曾半仙 发布
现有的Xvid+VDM的2pass压片模式也是可以用一种原始的分布方式....