请问AMD压片到底变快变慢啊？

支持AMD，但压起来应该事P4快。
顺便说一下，搂住千万不要买3500＋，根本没那性能

引用

最初由 曾半仙 发布
现有的Xvid+VDM的2pass压片模式也是可以用一种原始的分布方式,虽然原始但是有效,做一些辅助的软件就可以收到较好的效果,将一台机作为中枢机,供片源,和提供客户端操作命令,然后压片机上都装上客户端,按照服务端的传来的脚本用VDM载入,Vdm的脚本里面可以实现选择相应的帧数范围,和1st pass参数等基本一切平时手工操作的,这时候的帧数分配可以是均分,然后几台压片机将1pass分块走完以后,得到的stat文件传回服务端,服务端将1pass的stat文件合并起来进行统计,然后再次根据编码难度,以场景转换等会出现关键帧的地方为最小分割单位,将任务分成几大陀,并且根据指定的2pass参数,微调每段的码率,写入脚本,和重新拆分的stat文件一起传过去,然后各压片机开工压制并,将压得的片子传回服务端,服务端用vdm脚本对片子进行合并,加音频,并上传到分流FTP,打开QQ和MSN向分流的同志们广播.

这个土分布方案,应该可以有效地利用网吧,学校机房等廉价资源吧....

这个你试试看吧，我认为不现实，设置繁琐倒也罢了，但是这码率的掌握怎么弄？用2pass就是为了控制大小和码率分配阿，自己这样弄出来的不怕大小不合格或者质量不平均么…………

现有的Xvid+VDM的2pass压片模式也是可以用一种原始的分布方式,虽然原始但是有效,做一些辅助的软件就可以收到较好的效果,将一台机作为中枢机,供片源,和提供客户端操作命令,然后压片机上都装上客户端,按照服务端的传来的脚本用VDM载入,Vdm的脚本里面可以实现选择相应的帧数范围,和1st pass参数等基本一切平时手工操作的,这时候的帧数分配可以是均分,然后几台压片机将1pass分块走完以后,得到的stat文件传回服务端,服务端将1pass的stat文件合并起来进行统计,然后再次根据编码难度,以场景转换等会出现关键帧的地方为最小分割单位,将任务分成几大陀,并且根据指定的2pass参数,微调每段的码率,写入脚本,和重新拆分的stat文件一起传过去,然后各压片机开工压制并,将压得的片子传回服务端,服务端用vdm脚本对片子进行合并,加音频,并上传到分流FTP,打开QQ和MSN向分流的同志们广播.

这个土分布方案,应该可以有效地利用网吧,学校机房等廉价资源吧....

现在X86也在向多核心发展，其实我觉得影响压片速度的因素很多，编码器的优化程度也是很重要的，如果对SSE2充分优化的话，K7和K8都不是P4的对手

引用

最初由 66666 发布
RV10除外:p

已经有压缩组证明过了：Athlon xp 2000+ 压 rv10 比 P4 2.0 快

哀，还没回过来郁闷劲呢，楼上的贴跟的太残忍了，偶的机器就素那被打败的P4 2.4啊……
走了，睡觉去了

我知道你说的那种，现在还有利用快速网络进行的实时分布，不是基于广域范围的在家计算那种，当然也有人说这不是真正的分布计算，有悖于现有的利用慢速网络的情况，所以不通用，我倒是认为这就是可以解决以前的（受益软件）不通用的情况，虽然他要求的数据传输率高那是建立在不确定的传输量上，如果把数据的传输/广播等做在虚拟机和系统那一层，现在那些虚拟机里面和已安装系统交互都是比较成熟了（设备，共享，驱动等等），把任务细化到进程来看，例如压片更多的是依赖CPU的马力而不是超大内存，每一个进程所存取的内存并不多，发生变化的部分还要少一些，这样让存储端的CPU专门负责压缩和处理数据，每次将进程的单个线程的任务传输给计算端，时间到以后将内存的计算结果和计算现场传回存储端，偶认为只要调度得当，咱们的家用网络也能上阵，就现在的操作系统软件来说，这种降级了的结构只能用于支持多CPU机器的程序，也就是说不必要让软件自身将任务在时间向量上切割为几陀，也不必去关心软件怎么做，最后的表现肯定软件有多个线程，再根据线程的参数配给相应的计算能力，这就圆满了，Real 的编码器是支持多CPU机子的优化的，Xvid 的 nic/Centic driud 编译版本不知道支不支持，当然我说了一堆肯定会惹来人笑，例如那些签名一签就好几台P4P5银河深蓝的人，和那个躲在某xx所拿大型机玩传奇的人，我承认我玩不起高科技，但我相信实验技术的民用化相对与民用设备的败家化肯定是王道……
===============传说中的分割线=================
以上越写越胡言乱语，越写越觉得机子压片慢，人生没有意义，不如跳2楼算了，就当偶不小心吐在论坛上了吧……偶素自带塑料袋的善良的路人～～