ZiNgA BuRgA Wrote:Assassinator Wrote:Actually, would you mind doing this encoding speed test I made?
Download the package » here (341KB)
Comes with x264 r1057, some batch files and an avs file.
There's practically no motion in that sample, so it's not really the best to test with, but at 1.8GHz (9x200): (multi encode seems to stick the CPU at around 45-80% (weirdly, the speed goes down over time, and so does the CPU usage of all the encodes - could be the motherboard automatically slowing down the CPU do to heating))
As for the lack of motion, it's kinda difficult to make motion out of nothing with avisynth alone. I guess I could upload a source file for you to encode, but that's annoying to both upload and download.
As for the speed going down over time, it's probably the avs script. It's more complicated later on. On hindsight, I guess that might not be a very good idea, since some of your cpu power will be spent on avisynth instead of all on the encode. And since avisynth doesn't take advantage of multiple cores, the avisynth portion of the encode will under perform, and that might make the test slightly biased against multi-core computers. But if it were a real video source instead, depending on how it's decoded, the same problem could also exist.
If you want to know if your encode slows down due to your motherboard, just go and kill everything in the avs script except for the 1st and last lines.
ZiNgA BuRgA Wrote:![[Image: clipboard01le3.jpg]](http://img262.imageshack.us/img262/4696/clipboard01le3.jpg)
![[Image: clipboard02et1.jpg]](http://img410.imageshack.us/img410/1958/clipboard02et1.jpg)
![[Image: clipboard03pq8.jpg]](http://img390.imageshack.us/img390/5440/clipboard03pq8.jpg)
^ Like, as you can see, the multi-thread encode averages slower than the single-thread, but I performed it after the single one (and the speed scaled down far more aggressively).
Ok, after looking at your screenshots... I realized how hard I screwed up my command lines. Lol, the multi-thread and single thread batch files I gave you are identical. Both are --threads auto

. Heh, remember to double check the stuff before uploading it. And that's probably why you got similar speeds for both.
Replace the x264 command line with this, and try again.
Code:
x264 --crf 20.0 --threads 1 --progress --output "ColorBars.mp4" "ColorBars.avs"
|
Anyway, here are my speeds.
Multiple threads
Single thread
So the difference in speeds between us is quite a bit less than I expected. (Heh, I expected you to completely donkey rape my speed). But you did underclock your cpu, so I guess it's capable of more than that. It's the core2 laptop by the way. My computer (desktop) is much slower, not just because it's slow, but also because the older cpu doesn't have as many of the more advanced instruction sets that can speed up the encoding. I'll do this on my comp and upload the results sometime tomorrow.
As for the "insane" encode, the speed slowly goes down steadily to something really poo poo. Not just avs script, I think it's partially due to how the fps is calculated. Not an instantaneous amount, some sort of average, and the start is faster because there's not as many frames before, which means less analysis. Since your screenshot is at 0.9% (at that time, the displayed fps is much faster than the average), It's kinda senseless to compare our results.
EDIT: Something extremely weird here....
Look at the x264 info displayed after the encodes, and compare yours with mine. The average quantizer and the metrics all don't match up. Not only that, they are quite very different... and wee're using the same settings and source...
I can imagine that using a different amount of threads might cause a slightly different result, as shown in my 2 screenshots, but the difference is way to large to be accounted for just by that...