Opened 9 years ago
Closed 9 years ago
Last modified 8 years ago
#3730 closed defect (worksforme)
libx265 ignores threads option.
|Reported by:||Daniel||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
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 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 by , 9 years ago
|Status:||new → closed|
comment:2 by , 9 years ago
It is normal for libx265 to take up more CPU than libx264. This does not mean that libx265 is not using multithreading.
comment:3 by , 9 years ago
|Status:||closed → 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.
comment:4 by , 9 years ago
Please test the same commands as I did to prove that
-threads has no effect for you.
comment:5 by , 9 years ago
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.
comment:6 by , 9 years ago
|Status:||reopened → 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 by , 9 years ago
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 by , 9 years ago
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.
-vcodec libx265 behaves differently for different threads-values, then I don't see what could be fixed in FFmpeg.
comment:9 by , 9 years ago
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 by , 8 years ago
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:
"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.)
Works fine here, I suggest you compile yourself or ask in the Zeranoe forum.