libx265 ignores threads option.

[Daniel]

Summary of the bug:
Ffmpeg ignores the -threads option with libx265. I've tried with libx264 and works fine, it uses about 60% of processor, but with libx265 uses about 95% (full processor).
I'm using Windows 7 SP1 on a Core2Duo 2GHZ CPU (2 threads).

How to reproduce:

% ffmpeg -threads 1 -i salida.mp4 -c:v libx265 -b:v 500k -b:a 128k -preset superfast "salida2.mp4"

and just the same command but with libx264 instead libx265 works fine.

Ffmpeg info:

ffmpeg version N-64088-gcc0057a Copyright (c) 2000-2014 the FFmpeg developers
  built on Jun 20 2014 00:41:14 with gcc 4.8.3 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
e --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-
libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libope
njpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsox
r --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab -
-enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-
libxavs --enable-libxvid --enable-decklink --enable-zlib
  libavutil      52. 89.100 / 52. 89.100
  libavcodec     55. 67.100 / 55. 67.100
  libavformat    55. 44.100 / 55. 44.100
  libavdevice    55. 13.101 / 55. 13.101
  libavfilter     4.  8.100 /  4.  8.100
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 19.100 /  0. 19.100
  libpostproc    52.  3.100 / 52.  3.100

Is the lastest Zeranoe build for Win64.

[Carl Eugen Hoyos]

Works fine here, I suggest you compile yourself or ask in the Zeranoe forum.

$ time ./ffmpeg -benchmark -f lavfi -i testsrc -t 60 -y -threads 1 -pix_fmt yuv420p out.hevc

...

real    0m38.913s

$ time ./ffmpeg -benchmark -f lavfi -i testsrc -t 60 -y -threads 8 -pix_fmt yuv420p out.hevc

...

real    0m21.448s

[Timothy Gu]

It is normal for libx265 to take up more CPU than libx264. This does not mean that libx265 is not using multithreading.

[Daniel]

that's not what i mean, is just the contrary. I want to avoid MT and use only one core.

I've tested making my own ffmpeg build in a clean Debian installation and this script: ​https://github.com/rdp/ffmpeg-windows-build-helpers and got the same problem.

I've done some test with this command line:

% ffmpeg.exe -threads 1 -i in.mp4 -c:v libx264 out.mp4
% ffmpeg.exe -threads 1 -i in.mp4 -c:v libx265 out.mp4

With both builds (Zeranoe and mine) and both commands, i've got the same problem with -threads option: it uses both threads instead only one.

I'll try an older build, because maybe is a problem of lastest build.

Greetings.

[Carl Eugen Hoyos]

Please test the same commands as I did to prove that -threads has no effect for you.

[Daniel]

With your command the program uses less CPU time, but continues using more than one thread (about 70%-85%). With threads 2 or 8 uses the same CPU.

I've tried with MP4 instead hevc to use libx264, and works fine (just 50% and with threads 2 about 95%).

Finally, the x264 problem is command line, because this works:

% ffmpeg.exe -i in.mp4 -threads 1 -c:v libx264 out.mp4

but with x265 still no working.

Greetings

[Carl Eugen Hoyos]

Sorry but your original report is that -vcodec libx265 ignores -threads which is not the case. If you need a slower executable recompile both the library and FFmpeg without thread support.

[Daniel]

My report still talking about libx265 library and -threads but i'm comparing it with other codecs. Like i said in last post with x264 works fine, but x265 ignores -thread option and take full cpu usage, then -threads works fine with other codecs (that mean is not my binary) but not with x265 (like my post title)....

[Carl Eugen Hoyos]

But you do understand that libx264 and libx265 are two independent libraries and both are developed completely independent of FFmpeg? There is no reason to expect that they show the same behaviour, not even with the same options.
If -vcodec libx265 behaves differently for different threads-values, then I don't see what could be fixed in FFmpeg.

[Daniel]

I see... I've compiled the lastest x265 with Visual Studio 2013 and have the same problem.

Greetings and sorry for the inconvenience.

[David Joffe]

It seems to me that the behavior Danixu is looking for can possibly be obtained by combining the "threads" parameter with the "pools" parameter as follows:

ffmpeg -i input.mp4 -threads 1 -c:v libx265 -preset medium -f mp4 -x265-params crf=28:pools=none -c:a aac -strict experimental -b:a 128k output.mp4

On a four-core (Win64) system, this gives me a situation of approximately 25% total CPU usage - that's what I would "intuitively" expect from "-threads 1". (If I don't specify "pools:none" but do specify "threads 1" then I get about 80% to 90% CPU usage, which is counter-intuitive to me - it gives the impression the parameter is being ignored - though it is *not* actually being ignored, as it does make *some* difference on the total thread count and CPU usage, as shown in Task Manager.)

Anyway, on a four-core system I can seemingly also get (very) approximately 40% to 50% 'CPU Usage' by specifying the parameters as follows:

ffmpeg -i input.mp4 -threads 2 -c:v libx265 -preset medium -f mp4 -x265-params crf=28:pools=none -c:a aac -strict experimental -b:a 128k output.mp4

I admittedly found this through a little trial and error, rather than actually completely understanding exactly how all these parameters are interpreted, so perhaps someone with more understanding of these two parameters could weigh in - though I realize this is an issue tracking report thread, not a help forum. I'm just posting this as hopefully the above info might help others who encounter the same thing (as like Danixu, I also thought the parameter was being ignored, and I'm sure other users will). I think some of the confusion might originate in differences between UNIX/Windows "threads", as well as the x265 thread pool stuff - more info here:

​http://x265.readthedocs.org/en/latest/cli.html#performance-options

"x265 creates one or more thread pools per encoder, one pool per NUMA node (typically a CPU socket). --pools specifies the number of pools and the number of threads per pool the encoder will allocate"

*Edit* - Sorry, I think I must correct what I wrote above: Seemingly, "pools=" corresponds to probably what Danixu expected "-threads" to do (e.g. limit cores), while the "threads" parameter seems to correspond to some number of threads to run for each 'core' - as I get the following on 4-core system:

threads=4 pools=2 => ~53% cpu usage [20 actual total process threads]
threads=2 pools=2 => ~52% cpu usage [14 actual total process threads]
threads=1 pools=3 => ~72% cpu usage [10 actual total process threads]
threads=2 pools=3 => ~75% cpu usage [15 actual total process threads]
threads=default pools=1 => ~25% cpu usage [19 actual total process threads]

So I think what Danixu is looking for can probably be achieved by only using "pools=1". (When I tried this latter the other day, it also didn't seem to work at all - I've since upgraded to the latest version - so perhaps some bug has been fixed in the meantime.)