[FFmpeg-trac] #3730(undetermined:closed): libx265 ignores threads option.

[FFmpeg]

#3730: libx265 ignores threads option.
-------------------------------------+-------------------------------------
             Reporter:  Danixu       |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
             Blocking:               |  worksforme
Analyzed by developer:  0            |               Blocked By:
                                     |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

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

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3730#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker