炽地使
发表于 2013-4-23 13:04:07
好贴,谢谢分享
farmer
发表于 2013-4-23 15:04:29
:值得学习的经验啊~~~~发现不容易!~
lijianwen
发表于 2013-4-25 20:43:03
顶一下,他大爷的,这么重要的问题,竟然没有人来测试.
xiaoqing8866
发表于 2013-4-25 21:49:45
长期勾选那个选项,还真是不知道能快呢
伤心的笔
发表于 2013-4-29 14:21:43
下载了顶楼的文件,进行了测试。结果是只差21秒。
MPEG2,720*576,1 pass VBR(平均9200kbps),编码速度-标准,画质优先,直流成分精度9bit。
测试时为了尽量减少误差,在编码前把该程序在前台和后台运行时的任务优先级均设置为高。关闭编码时预览画面。编码时基本无动作。
首先是开启CUDA、开启预读(预读的参数保持默认)
16'28''这么慢……
接着是开启CUDA,关闭预读
16'49''只差21秒……
伤心的笔
发表于 2013-4-29 14:47:52
我用一个36G左右的阿凡达Bd-Remux测试,选取了44秒的片段。改为编码为H.264
这是未开启预读时的:
这是开启之后的:
开启后只差了两秒,在误差范围之内。
不过我注意到一个细节,编码时显示CPU完成100%的工作,CUDA一直没有工作。
伤心的笔
发表于 2013-4-29 15:49:54
再次测试。
只有1秒差距
IsaacZ
发表于 2013-4-30 00:40:09
我也重做测试,结果如下:
测试一:VBR(固定画质)视频9200kb/s,音频192kb/s,画质70
未开启预读 279秒:
已开启预读 210秒:
结果与顶楼相同。也是节省25%时间。
测试二:CBR(固定码率)视频2000kb/s,音频128kb/s
未开启预读4'22''(262秒)
已开启预读 2'43''(163秒)
结论:开启预读后节省99秒,约占38%。
再测试一遍:
未开启预读4'37''(277秒)
已开启预读2'02''(122秒)
结论:开启预读后节省155秒(约占56%)
@lijianwen @伤心的笔
lijianwen
发表于 2013-4-30 01:48:47
IsaacZ 发表于 2013-4-30 00:40 https://www.dianbo.org/static/image/common/back.gif
我也重做测试,结果如下:
测试一:VBR(固定画质)视频9200kb/s,音频192kb/s,画质70
测试二,进行了两遍,为什么差别这么大?
2分2秒,这有点超常发挥了,用小日本4按照这个状况,直接1分40秒以内。
伤心的笔
发表于 2013-4-30 08:45:23
本帖最后由 伤心的笔 于 2013-4-30 08:51 编辑
IsaacZ 发表于 2013-4-30 00:40 static/image/common/back.gif
我也重做测试,结果如下:
测试一:VBR(固定画质)视频9200kb/s,音频192kb/s,画质70
不同电脑上呈现了不同的结果。很令人疑惑。
我本来想猜64位系统与32位系统可能不同,但是看到你的小日本5是通过SysWow64直接运行在32位模式的,也许没什么不同。
测试时是否让小日本5在前台运行和后台运行时是在同一个优先级?这可能会有不小的差距。
或许是电脑不同,结果不同?
至于别的可能的原因,我想不出来了。
贴上我自己的电脑信息(有用的部分):
操作系统 Windows 8 Pro with Media Center Professional x86
中央处理器 Pentium(R) Dual-Core CPU E5400 @ 2.70GHz
主板芯片组 Intel Eaglelake G43/G45/P43/P45
显示适配器 NVIDIA GeForce 310(512 MB)
声音适配器 Intel 82801JB ICH10 - High Definition Audio Controller