Slow Encoding on Dual CPU

[wthreex]

Hi there, i have a dedicated server, cpu detail is :

2 x Intel-Xeon-Processor-E5-2670

Megui Doesn't use all my cpu :( you can see , i added another worker but it's slow on x265 yet :(:(



https://i1.someimage.com/W9W9PZr.png

[mariush]

Configure x265 to use more threads, if megui templates don't offer you these options, you can always adjust the command or copy it from the queue and modify it and run it outside MeGUI.

MeGUI is just a wrapper around programs, makes it easier by not typing a lot of parameters in the command line but when it doesn't let you play with all you need, you can go outside it.

[trip_let]

Some work depends on other results and it may not all scale perfectly with lots of cores. Here, 2x 8C16T. What kind of source are you dealing with? Resolution etc.?

If you have all the source to start with (and not coming in real time), you can just split up the source into multiple different segments covering different times, encode each segment (encoding more than one simultaneously), and concatenate segments back later. Alternatively, I believe there is the very new (newer than 2.0... you need a build from the last few days) --slices option that partitions the video spatially into horizontal slices so these can be processed in parallel, helping increase CPU utilization if you need it.

http://x265.readthedocs.io/en/latest/cli.html
https://bitbucket.org/multicoreware/x265/commits/all

[microchip8]

make sure to use --pmode (and possible --pme)

[benwaggoner]

What frame size and preset are you using? The higher presets turn off frame threading and lookahead threading, which can limit parallelization of lower resolutions. If that's the case --pmode can definitely help. I've not personally found cases where --pme wound up having a net improvement, but I haven't been looking either. Has anyone found some good cases where it did?

Lastly, there was a recent x265 bug fix for Windows that re-enabled the use of multiple NUMA sockets on a multi-socket system like yours. If you were only getting ~50% utilization, that might be all you need.

Also, if you do wind up having to encode two parallel encodes, I recommend you set one to have --pools "+,-" and the other --pools "-,+", so that each encode gets pinned to its own socket, for less resource contention.