搜索 社区服务 统计排行 帮助
  • 6713阅读
  • 32回复

i5 750为啥压制CPU占用只有50% ?

楼层直达
级别: 新手上路
注册时间:
2005-06-30
在线时间:
1小时
发帖:
529
只看该作者 15楼 发表于: 2010-02-24
不必須要AviSynth的話,不如用dshow2raw(direct264)或者mencoder,都能掛字幕。

Nehalem系肯定能用滿CPU的,我i7開超線程都能100%占用。所以瓶頸肯定在解碼端或者是你的參數。你不給出avs腳本、x264參數的話,沒法繼續分析。

级别: 新手上路
注册时间:
2007-05-07
在线时间:
1小时
发帖:
447
只看该作者 16楼 发表于: 2010-02-24
测试环境:win7 x64,x264 x86 svn1442,使用avs直接输入
压一个MPEG2 1080i的动画TS处理,只做IVTC和resize
trim出5000帧,在x264参数完全相同的情况下(大概就是preset slower),resize成704x480速度大约是resize成1280x720的三倍,并且相比而言CPU没有用的那么满

所以我强烈怀疑LZ的做法在什么地方有瓶颈。就算真是用不满,也可以靠同时开多个任务来解决
级别: 新手上路
注册时间:
2004-08-01
在线时间:
4小时
发帖:
480
只看该作者 17楼 发表于: 2010-02-24
引用
最初由 roozhou 发布
lavf/ffms判断fps错误关系不大,顶多就是码率可能出错。如果用crf那就没有影响了

其实是错误的吧crf认成vrf了

überm Sternenzelt richtet Gott, wie wir gerichtet.

Girls
Usually
Need
Diamond
And
Money
级别: 新手上路
注册时间:
2005-06-30
在线时间:
1小时
发帖:
529
只看该作者 18楼 发表于: 2010-02-24
引用
最初由 squall617 发布

其实是错误的吧crf认成vrf了
你想说cfr和vfr么。。

级别: 精灵王
注册时间:
2008-04-08
在线时间:
44小时
发帖:
2855
只看该作者 19楼 发表于: 2010-02-24
ffmpeg本来就没法判断cfr还是vfr,不过这些东西都可以编码完了再改的
级别: 新手上路
注册时间:
2007-04-16
在线时间:
0小时
发帖:
69
只看该作者 20楼 发表于: 2010-02-24
應該說
浮點運算的 b adapt2 + b frames
速度當然慢 且CPU佔用不大 ....
等有朝一日 b adapt2 + b frames 能夠改用GPU運算....
速度就快了 且佔CPU了....

1st 居多是處理浮點運算 也就是快速掃描畫面一次過去

级别: 超级版主
注册时间:
2002-08-18
在线时间:
181小时
发帖:
14839
只看该作者 21楼 发表于: 2010-02-24
樓上用A0的CPU不是等爆漿嗎.....


現在都B1了 3月市售版會是B2

FREEWIND台湾,日本商品团购MSN群: group130599@xiaoi.com 欢迎入群讨论!!
贩售台湾正版CD,DVD,漫畫,輕小說,及台灣各種商品,采Door to Door服务有保障!!请大家告诉大家!!
※FREEWIND工作室官方掏宝店铺,请点我!!!※

※漫游FREEWIND工作室招募人才 請點我!※
※漫游FREEWIND工作室作品汇总 請點我!※
※漫游FREEWIND工作室招募分流FTP&P2P分流员 請點我!※

级别: 新手上路
注册时间:
2004-12-22
在线时间:
0小时
发帖:
156
只看该作者 22楼 发表于: 2010-02-24
我贴一下参数。

源文件是MJPG

x264 1376 Jeeb's patch build v2

AVS代码

a=directshowSource("J:\0ff\ff13open1.avi", audio=true)
b=directshowSource("J:\0ff\ep10.avi", audio=true)
c=directshowSource("J:\0ff\ep10ed.avi", audio=true)
d=a+b+c
e=d.TextSub("J:\0fft\ep10t.ass").SelectEven.ConvertToYV12()
audio=e
Return AudioDub(e, audio)

480p的话就加一个.LanczosResize(720, 480)在e那里

x264设置
program --profile high --level 4.1 --pass 2 --bitrate 2500 --stats ".stats" --thread-input --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 9000 --vbv-maxrate 24000 --ratetol 2.5 --qcomp 0.7 --merange 12 --me umh --direct auto --trellis 2 --psy-rd 0.00:0 --output "output" "input"
级别: 精灵王
注册时间:
2008-04-08
在线时间:
44小时
发帖:
2855
只看该作者 23楼 发表于: 2010-02-24
引用
最初由 翡璃月 发布
應該說
浮點運算的 b adapt2 + b frames
速度當然慢 且CPU佔用不大 ....
等有朝一日 b adapt2 + b frames 能夠改用GPU運算....
速度就快了 且佔CPU了....

1st 居多是處理浮點運算 也就是快速掃描畫面一次過去

我用Visual Studio自带的Performance tool,用-o NUL -p1 --b-adapt 2 -b8测试了一下,列出占用CPU时间靠前的几个函数。我的CPU是双核K8,但不会和nehalem的结果有太大区别。

x264_pixel_satd_8x8_internal_mmxext 15.874%
x264_pixel_avg2_w8_mmxext 9.898%
x264_rdo_init7.679%
x264_pixel_sad_x4_8x8_mmxext 6.342%
x264_me_search_ref6.004%
x264_me_refine_bidir_satd5.422%
x264_pixel_avg_weight_w8_mmxext4.090%
x264_mc_copy_w8_mmx3.124%
x264_pixel_sad_8x8_mmxext 2.969%
x264_pixel_satd_8x8_mmxext 2.934%
另外解码部分大概占了接近5%

好吧,这里的所有函数里都是找不到一丁点浮点运算的。不知道你的“1st居多是处理浮点运算”的结论是怎么得出来的。
级别: 新手上路
注册时间:
2007-04-16
在线时间:
0小时
发帖:
69
只看该作者 24楼 发表于: 2010-02-25
引用
最初由 roozhou 发布

我用Visual Studio自带的Performance tool,用-o NUL -p1 --b-adapt 2 -b8测试了一下,列出占用CPU时间靠前的几个函数。我的CPU是双核K8,但不会和nehalem的结果有太大区别。

x264_pixel_satd_8x8_internal_mmxext 15.874%
x264_pixel_avg2_w8_mmxext 9.898%
x264_rdo_init7.679%
x264_pixel_sad_x4_8x8_mmxext 6.342%
x264_me_search_ref6.004%
x264_me_refine_bidir_satd5.422%
x264_pixel_avg_weight_w8_mmxext4.090%
x264_mc_copy_w8_mmx3.124%
x264_pixel_sad_8x8_mmxext 2.969%
x264_pixel_satd_8x8_mmxext 2.934%
另外解码部分大概占了接近5%

好吧,这里的所有函数里都是找不到一丁点浮点运算的。不知道你的“1st居多是处理浮点运算”的结论是怎么得出来的。


我只是從硬體的角度去看
i7-920 浮點運算處理比 i7-980X ES Q3FE 強大一些
因為Uncore效能的關係
920 跑 1st 約是 40fps
980X 跑 1st 約是 35fps

级别: 新手上路
注册时间:
2007-04-16
在线时间:
0小时
发帖:
69
只看该作者 25楼 发表于: 2010-02-25
引用
最初由 風之殤 发布
樓上用A0的CPU不是等爆漿嗎.....


現在都B1了 3月市售版會是B2


A0 完成度其實就很接近 100% 了 [/TX]

级别: 精灵王
注册时间:
2008-04-08
在线时间:
44小时
发帖:
2855
只看该作者 26楼 发表于: 2010-02-25
引用
最初由 翡璃月 发布

我只是從硬體的角度去看
i7-920 浮點運算處理比 i7-980X ES Q3FE 強大一些
因為Uncore效能的關係
920 跑 1st 約是 40fps
980X 跑 1st 約是 35fps

硬件行业有个Amdahl's Law ,就算浮点运算快了100%,x264的速度也不会快1%,广告这种东西你也跟着信?很明显是整数运算性能提高导致的速度变快,当然也有可能是cache之类的影响。
级别: 新手上路
注册时间:
2007-04-16
在线时间:
0小时
发帖:
69
只看该作者 27楼 发表于: 2010-02-25
引用
最初由 roozhou 发布

硬件行业有个Amdahl's Law ,就算浮点运算快了100%,x264的速度也不会快1%,广告这种东西你也跟着信?很明显是整数运算性能提高导致的速度变快,当然也有可能是cache之类的影响。


我從沒說過因為浮點運算變快的緣故而變快...
更何況整數運算再怎說也是核心多的980X比較快...
我只是從硬體方面認為1st時採用浮點運算 既然現在有人能證明不是
那可以解釋何以何以1st於980X反而較慢?

级别: 新手上路
注册时间:
2005-06-30
在线时间:
1小时
发帖:
529
只看该作者 28楼 发表于: 2010-02-25
引用
最初由 翡璃月 发布


我從沒說過因為浮點運算變快的緣故而變快...
更何況整數運算再怎說也是核心多的980X比較快...
我只是從硬體方面認為1st時採用浮點運算 既然現在有人能證明不是
那可以解釋何以何以1st於980X反而較慢?
根据“980X的优势只是核心多,单核效率没有920高”这项猜测,1st pass 980X比920慢的原因,很可能是1st pass时的单线程运算较多。另外,也可能是x264现在的版本尚未对Gulftown做优化。

级别: 风云使者
注册时间:
2009-03-17
在线时间:
552小时
发帖:
1255
只看该作者 29楼 发表于: 2010-02-25
额,这楼真够专业向,并行度不提高n核都没有用
快速回复

限150 字节
上一个 下一个