following questions on and discussions about the impact iDCT has on the conversion speed, i decided to test all available iDCTs in rebuilder (pro):
i converted Van Helsing once more:
126 min main movie + 35 min extras
using an athlon64 @ 3500, 1gb ram with cce 270 in OPV (one pass variable bitrate) mode
all conversion were done via batch-processing and of course the pc wasnt touched at all
the times are ENCODING ONLY because rebuilding for example has absolutely nothing to do with idct and that's what i wanted to test
it is no wonder that the most precise modes (64bit) take longest but ~1/3 speed difference is quite a lot and i guess and wont ever use them until i got myself a dual-core 6ghz machine
xvid idct being the winner is no surprise either - it is considered very fast but not as good/precise
according to rockas the default settings is:
jdobbs on: 32 bit ssemmx idct (skal):
this one is runner-up in terms of speed; the quality of which i cannot comment on as i wont spend time on something that will have to be made by means of image-comparison software and thus cannot be detected by the human eye
i'm a little bit puzzled as to my encoding time using DEFAULT as it does not match ANY other time - according to what i cited above default equals sse/mmx and thus it should have been 67 min not 66 but anyway
a little more surprising to me is the fact that sse2/mmx is NOT faster than mmx//sse/mmx which some people say it outperforms
taking into account that the default setting is #3 out of 8 when talking speed, i should think i will stay with this setting - it has provided good results before and it is not horribly slow compared to other settings
old dog, new tricks you know
of course results may differ with different cpus so in case anyone wants to test a couple of the idct, please to so and report back
i converted Van Helsing once more:
126 min main movie + 35 min extras
using an athlon64 @ 3500, 1gb ram with cce 270 in OPV (one pass variable bitrate) mode
all conversion were done via batch-processing and of course the pc wasnt touched at all
the times are ENCODING ONLY because rebuilding for example has absolutely nothing to do with idct and that's what i wanted to test
Code:
idct decoder default 66 min 32 bit mmx 67 min 32 bit sse/mmx 67 min 64 bit floating point 81 min 64 bit IEEE-1180 reference 83 min 32 bit sse2/mmx 67 min 32 bit ssemmx idct (skal) 64 min 32 bit simple mmx (xvid) 61 min
it is no wonder that the most precise modes (64bit) take longest but ~1/3 speed difference is quite a lot and i guess and wont ever use them until i got myself a dual-core 6ghz machine
xvid idct being the winner is no surprise either - it is considered very fast but not as good/precise
according to rockas the default settings is:
... the default value is SSE/MMX not SSE2/MMX... anyway...
SSE2/MMX is compatible with Pentium IV and AMD64...
SSE/MMX is compatible with those two plus Pentium III and Amd ATHLON.
SSE2/MMX is compatible with Pentium IV and AMD64...
SSE/MMX is compatible with those two plus Pentium III and Amd ATHLON.
The two SSE/MMX versions are just different algorithms that use the same precision levels, one was designed by SKAL.
this one is runner-up in terms of speed; the quality of which i cannot comment on as i wont spend time on something that will have to be made by means of image-comparison software and thus cannot be detected by the human eye
i'm a little bit puzzled as to my encoding time using DEFAULT as it does not match ANY other time - according to what i cited above default equals sse/mmx and thus it should have been 67 min not 66 but anyway
a little more surprising to me is the fact that sse2/mmx is NOT faster than mmx//sse/mmx which some people say it outperforms
taking into account that the default setting is #3 out of 8 when talking speed, i should think i will stay with this setting - it has provided good results before and it is not horribly slow compared to other settings
old dog, new tricks you know
of course results may differ with different cpus so in case anyone wants to test a couple of the idct, please to so and report back
Comment