Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#3730 closed defect (worksforme)

libx265 ignores threads option.

Reported by: Danixu Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (10)

comment:1 Changed 4 years ago by cehoyos

  • Resolution set to worksforme
  • Status changed from new to closed

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

comment:2 Changed 4 years ago by Timothy_Gu

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

comment:3 Changed 4 years ago by Danixu

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 4 years ago by cehoyos

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

comment:5 Changed 4 years ago by Danixu

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

comment:6 Changed 4 years ago by cehoyos

  • Resolution set to worksforme
  • Status changed from reopened to closed

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.

comment:7 Changed 4 years ago by Danixu

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)....

comment:8 Changed 4 years ago by cehoyos

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.

comment:9 Changed 4 years ago by Danixu

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

Greetings and sorry for the inconvenience.

comment:10 Changed 4 years ago by 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.)

Last edited 4 years ago by david_joffe (previous) (diff)
Note: See TracTickets for help on using tickets.