『漫游』酷论坛>『影音数码技术学习交流』>i5 750为啥压制CPU占用 ..

ssnake@2010-02-24 01:41

不必須要AviSynth的話，不如用dshow2raw(direct264)或者mencoder，都能掛字幕。

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

a4840639@2010-02-24 02:05

测试环境：win7 x64，x264 x86 svn1442，使用avs直接输入
压一个MPEG2 1080i的动画TS处理，只做IVTC和resize
trim出5000帧，在x264参数完全相同的情况下（大概就是preset slower），resize成704x480速度大约是resize成1280x720的三倍，并且相比而言CPU没有用的那么满

所以我强烈怀疑LZ的做法在什么地方有瓶颈。就算真是用不满，也可以靠同时开多个任务来解决
引用

squallatf@2010-02-24 09:16

引用
最初由 roozhou 发布
lavf/ffms判断fps错误关系不大，顶多就是码率可能出错。如果用crf那就没有影响了

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

ssnake@2010-02-24 11:26

引用
最初由 squall617 发布

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

roozhou@2010-02-24 17:45

ffmpeg本来就没法判断cfr还是vfr，不过这些东西都可以编码完了再改的
引用

翡璃月@2010-02-24 18:02

應該說
浮點運算的 b adapt2 + b frames
速度當然慢 且CPU佔用不大 ....
等有朝一日 b adapt2 + b frames 能夠改用GPU運算....
速度就快了 且佔CPU了....

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

風之殤@2010-02-24 18:52

樓上用A0的CPU不是等爆漿嗎.....


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

minime@2010-02-24 21:34

我贴一下参数。

源文件是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"
引用

roozhou@2010-02-24 23:19

引用
最初由 翡璃月 发布
應該說
浮點運算的 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_init 7.679%
x264_pixel_sad_x4_8x8_mmxext 6.342%
x264_me_search_ref 6.004%
x264_me_refine_bidir_satd 5.422%
x264_pixel_avg_weight_w8_mmxext 4.090%
x264_mc_copy_w8_mmx 3.124%
x264_pixel_sad_8x8_mmxext 2.969%
x264_pixel_satd_8x8_mmxext 2.934%
另外解码部分大概占了接近5%

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

翡璃月@2010-02-25 00:44

引用
最初由 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_init 7.679%
x264_pixel_sad_x4_8x8_mmxext 6.342%
x264_me_search_ref 6.004%
x264_me_refine_bidir_satd 5.422%
x264_pixel_avg_weight_w8_mmxext 4.090%
x264_mc_copy_w8_mmx 3.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
引用

翡璃月@2010-02-25 00:45

引用
最初由 風之殤 发布
樓上用A0的CPU不是等爆漿嗎.....


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


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

roozhou@2010-02-25 10:00

引用
最初由 翡璃月 发布

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

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

翡璃月@2010-02-25 21:30

引用
最初由 roozhou 发布

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


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

ssnake@2010-02-25 21:43

引用
最初由 翡璃月 发布


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

ljwing@2010-02-25 21:53

额,这楼真够专业向,并行度不提高n核都没有用
引用

«123»共3页

| TOP