Question / Help x264 & Dual CPU

D

Dasweb

New Member
Hi All,

Just wondering if anyone could shed some light on x264 CPU usage with dual CPUs.

On paper, it looks like I should be able to handle "slower" with my dual Xeon E5-2670. However, I'm having an issue with anything below Medium.

Set up:

Dual E5-2670
8GB RAM @ 1333
HD60 Pro
GT 730 (384 Cuda core, not the lower version)

Capturing at 1080p 60fps, downscale to 720p 60fps.

When attempting to use the slow preset, the second CPU will have almost no load. When setting the affinity manually to physical cores only, the second CPU will have load, but it's quite low and I'll get an encoding warning with extremely choppy playback.

I've tried to do research and have found others have said the same, but I cannot find any hard solutions.
 
Sapiens

Sapiens

Forum Moderator
There are limits to the performance you can get through multithreading, so despite having 32 logical cores x264 probably can't split up the 720p60 video enough to really take advantage of them all. I suspect you'd see greater utilization with larger videos.
 
D

Dasweb

New Member
Sapiens said:
There are limits to the performance you can get through multithreading, so despite having 32 logical cores x264 probably can't split up the 720p60 video enough to really take advantage of them all. I suspect you'd see greater utilization with larger videos.
Click to expand...

Interesting. So possible a 1080p @ 48 FPS then would be better suited?
 
D

Dasweb

New Member
Still doesn't really make sense why it would give encoding high errors but not be utilizing CPU.
 
Sapiens

Sapiens

Forum Moderator
While normally we don't recommend doing this, I've seen a couple of situations where users have a lot of logical cores on their CPUs, x264 seems to spawn too many threads and you have to manually limit them. Try adding the custom param threads=24 to override the default logical cores*1.5 x264 method and see if that helps performance. You can also fiddle with the number of threads higher/lower to see how that affects things.
 
D

Dasweb

New Member
So, changing around the threads didn't seem to have a real effect. Attempting to use "slow" resulted in high encoding still.
 
Suslik V

Suslik V

Active Member
Lower your fps to 30 and see what happen. If helps - you need higher frequency to complete sequential calculations in time. Look for faster CPU.
 
D

Dasweb

New Member
Suslik V said:
Lower your fps to 30 and see what happen. If helps - you need higher frequency to complete sequential calculations in time. Look for faster CPU.
Click to expand...

The issue is that OBS isn't taking advantage of what I even have.

With HT turned off, it's still not spreading the load across all cores. It'll 100% the first 8 cores, but the second CPU is extremely under utilized.
 
Adrian Schofield

Adrian Schofield

Member
I'm not sure if this is helpful but I found this article on doom9, it looks as though x264 is not too great at utilising dual CPUs.

http://forum.doom9.org/showthread.php?t=172180

It might be worth contacting the original poster to see if he got any further. It sort of makes sense to me, in my experience spreading load across CPUs is much harder than spreading it across cores as there are lots of bottlenecks between CPUs which don't exist inside a single CPU.
 
D

Dasweb

New Member
Adrian Schofield said:
I'm not sure if this is helpful but I found this article on doom9, it looks as though x264 is not too great at utilising dual CPUs.

http://forum.doom9.org/showthread.php?t=172180

It might be worth contacting the original poster to see if he got any further. It sort of makes sense to me, in my experience spreading load across CPUs is much harder than spreading it across cores as there are lots of bottlenecks between CPUs which don't exist inside a single CPU.
Click to expand...

Thanks for the link, I'll try to find contact information for that person and see if they've made any headway.
 
Adrian Schofield

Adrian Schofield

Member
I'm guessing that this is an x264 problem at heart and so not really much we can do about it here.

On my proc, 5820k, there are effectively 12 threads, I did an encoding test on slow and was able to get OBS (actually x264) to max out all 12 threads, obviously the encode failed which is expected. What that tells me is that x264 can scale above eight threads given the correct circumstances.

I also had a very brief (and frankly inexperienced) look at the x264 code. It uses a couple of low level Windows functions to get the processor data and it's possible that it is ignoring your second processor on purpose. Like I say I am not a low level programmer and the code is complex so I may well be mistaken but this also makes me think that the issue is with x264 and not OBS. I did write a small amount of test code, just a copy and paste from x264, to see what the results are but of course I don't have a dual cpu machine to do a comparison with.
 
D

Dasweb

New Member
From my personal research I found that x264 loses performance after 22-24 threads. I actually tested with Xsplit and it DID utilize the second CPU, even when HT was turned on. This leads me to believe it's an OBS issue first, and an x264 second.
 
O

Osiris

Active Member
Dasweb said:
From my personal research I found that x264 loses performance after 22-24 threads. I actually tested with Xsplit and it DID utilize the second CPU, even when HT was turned on. This leads me to believe it's an OBS issue first, and an x264 second.
Click to expand...

I doubt that, they both use the exact same encoder.
 
D

Dasweb

New Member
Osiris said:
I doubt that, they both use the exact same encoder.
Click to expand...

That's sort of my point though. There shouldn't be a difference when there is. Perhaps the CPU utilization isn't x264 and it's just Xsplit overhead.

Adrian Schofield said:
@Dasweb could you post a log of an attempt to stream or record as I can't see one in the thread.
Click to expand...

I will do so once I return home. The interesting thing is it seems I can record @ slow but not stream @ slow.
 
You must log in or register to reply here.
Top