x264 and 8 cores processor

[Lele-brz]

HI all,
I'm trying to take advatage of the thread option to improve cpu usage on a Xeon 8 cores, but even if I put threads 8 the cpu is around 30% and the encoding is not that fast,
what can i do to take advatage of all the cores?

thanks

bye

[Manao]

What is your input ? AVS file ( if so, what script ? ) ? YUV file ( if so, are you sure your hard drive isn't the limiting factor ? ) ?

Also, the way x264 is multithreaded, it will encode faster if you use ~3/2 x #cpu threads. So you should try 12 threads.

Finally, it can't efficiently multithread that much threads if your video's resolution is too small ( count at least 32 vertical pixels / threads )

[Sirber]

8) No cross posting. Post your message once, to the appropriate forum and nowhere else or it will be locked or deleted without warning.

[Mutant_Fruit]

Try reading this (http://forum.doom9.org/showthread.php?t=124557)

[Lele-brz]

thanks for the answers and sorry for crossposting.
My input is an avs file that read the source with DirectShowSource, do you think that using mt.dll will improve the encoding time significantly?
Do you suggest to use --thread-input also?

thanks again

[foxyshadis]

Thread-input is automatic when you use threads. You're probably going to be bottlenecked by the decoding unless the encoding is reeeeeeeeeally intense. If it's the first pass, decoder bottlenecks are pretty normal, unfortunately. There's very little you can do about them without finding a decoder that can use many threads effectively.

[bob0r]

Use --threads auto, since this is cores*1.5 you would get 12 threads. The speed difference should be huge.

[burfadel]

Isn't here an 8+ core patch available for x264? They were talking about committing it to the svn. It supposedly works better than the current multi-processor implementation. The code is availalbe on here someone... if you can build a copy of 656 yourself and include the patch...

[bob0r]

x264\common\common.h

#define X264_THREAD_MAX 128

--

r650 | pengvado | 2007-04-12 00:21:15 +0200 (Thu, 12 Apr 2007) | 2 lines

remove the restriction on number of threads as a function of resolution (it was wrong anyway in the presence of B-frames), and raise the max number of threads in general (though more will have to be done before it can really scale to lots of cores).

[morph166955]

I was doing some testing with akupenguin about a month ago with a patch to divide up the threads better over multiple processors. Whats the specs on your system? Im using 2x X5355's in my 8-core xeon setup.

and for the reference to everyone saying its the source, its not. I had raw YUV frames piped out of a custom made ram cache program that I made. It stored the decoded frames in ram and then dumped into x264 as fast as it could. The ram is DDR2-667 FB-DIMM's so thats about as fast as is humanly possible to transfer data into x264. id suggest reading through the thread mutant_fruit posted above. we did numerious tests with numerious different models and couldn't get it to max out until we either were using really large HD content.