x.265 on AMD Threadripper is very, very slow

Michael Lackner

I’m just commenting as a user (who’s built a benchmark using x265), but I think this might be helpful for other people finding this “issue”.

What I can tell you is this: x265 has a pretty hard time with parallelization. And your resolution is really low, which makes things much, much worse.

This calls for some parameter tuning to better utilize this many cores.

First, make sure all parallelization options are enabled, like --pme, --pmode and --wpp. Then, keep --merange low, because a large motion estimation range hurts parallelism.

Furthermore, you might try to go a little "non-standard" by pushing down your CTU/TU size from 64×64 to 16×16, so that there'll be more, finer-grain blocks to parallelize. Like this maybe: --allow-non-conformance --ctu 16 --max-tu-size 16.

Please note that this comes with a bitrate increase though, but I just don’t know how high that could be for frames this small. For a video the size of 2560×1600 an increase of up to ~28% was measured when going from 64×64 to 16×16, but like I said, that might be very different for small frames.

On top of that, you could also try and play around with frame threads, frame slices and lookahead slices to see whether it helps increasing their values: --frame-threads <0..16> --slices <integer> --lookahead-slices <0..16>. Note that for frame threads, "0" means auto-detect, for frame slices, "1" is the default and lowest value, and for lookahead slices, 0 and 1 both disable them, so start with 2 if you wanna try using them.

Source for the bitrate increase claim: http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Performance.pdf

2019-07-10T09:04:16+00:00

Comments (1)

Michael Lackner
I’m just commenting as a user (who’s built a benchmark using x265), but I think this might be helpful for other people finding this “issue”.

What I can tell you is this: x265 has a pretty hard time with parallelization. And your resolution is really low, which makes things much, much worse.

This calls for some parameter tuning to better utilize this many cores.

First, make sure all parallelization options are enabled, like --pme, --pmode and --wpp. Then, keep --merange low, because a large motion estimation range hurts parallelism.

Furthermore, you might try to go a little "non-standard" by pushing down your CTU/TU size from 64×64 to 16×16, so that there'll be more, finer-grain blocks to parallelize. Like this maybe: --allow-non-conformance --ctu 16 --max-tu-size 16.

Please note that this comes with a bitrate increase though, but I just don’t know how high that could be for frames this small. For a video the size of 2560×1600 an increase of up to ~28% was measured when going from 64×64 to 16×16, but like I said, that might be very different for small frames.

On top of that, you could also try and play around with frame threads, frame slices and lookahead slices to see whether it helps increasing their values: --frame-threads <0..16> --slices <integer> --lookahead-slices <0..16>. Note that for frame threads, "0" means auto-detect, for frame slices, "1" is the default and lowest value, and for lookahead slices, 0 and 1 both disable them, so start with 2 if you wanna try using them.

Source for the bitrate increase claim: http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Performance.pdf
- 2019-07-10T09:04:16+00:00
Log in to comment