98

I see that there's a -threads <count> command line option in ffmpeg. What is the default value of this option?

6 Answers 6

48

it depends on codec used, ffmpeg version and your CPU core count. Sometimes it's simply one thread per core. Sometimes it's more complex like:

With libx264 it is cores x 1.5 for frame threads and cores x 1 for slice threads.

3
  • 3
    Thanks. Do you have a reference to the defaults for some standard codecs supported by ffmpeg? Commented Jun 22, 2010 at 9:26
  • 9
    Don't rely on it. My ffmpeg 0.7.8 on Linux uses 1 thread by default no matter what. Commented Dec 22, 2011 at 19:30
  • What value can be used to get the better result? PS I am using FFMpeg in Android framework. Commented Aug 1, 2018 at 11:05
62

As of 2014, it uses an optimal number.

You can verify this on a multi-core computer by examining CPU load (Linux: top, Windows: task manager) with different options to ffmpeg:

  • -threads 0 (optimal);

  • -threads 1 (single-threaded);

  • -threads 2 (2 threads for e.g. an Intel Core 2 Duo);

  • none (the default, also optimal).

2015 edit: on a 12-core CPU, some ffmpeg commands have Linux top showing at most 200% cpu (only 2 cores), no matter what number is given to -threads. So the default may still be optimal in the sense of "as good as this ffmpeg binary can get", but not optimal in the sense of "fully exploiting my leet CPU."

1
  • 3
    Note that this only seems to be true for encoding, not general processing. If it is not actually producing output frames then it won't parallelize. e.g. if you're de-shaking from 02:00 onwards then you will only get parallelism from 02:00 onwards, but everything up to 02:00 will still need to be processed serially.
    – user541686
    Commented Aug 19, 2018 at 3:14
18

Some of these answers are a bit old, and I'd just like to add that with my ffmpeg 4.1, encoding with libx264, all 6 cores/12 threads of my Ryzen 5 2600X system were maxed without any -thread argument.

4
  • 2
    I have the 1800X and I am observing not quite 20% utilization spread across its 16 threads, but I am using a few optional arguments as well: -vcodec libx264 -profile:v high444 -refs 14 -preset ultrafast -crf 18 -tune fastdecode so that's a few variables to isolate. Adding on -threads 12 had no effect. Commented Oct 3, 2019 at 23:20
  • 1
    32-core 3970X, my utilization stays between 51%-65% using -c:v libx264 -preset fast -crf 16 for 4K to 4K or -c:v libx264 -preset fast -crf 16 -vf scale=3840:-2:flags=lanczos for 8K to 4K. 64 logical cores seem to get touched, 10 seem to stay below 20% utilized, 10 stay close to 100% utilized, and the rest bounce between ~50% and higher utilization. I am encoding from a Samsung 980 to a RAMdisk to attempt to remove any IO bottleneck. My conclusion: Specifying the number of threads is unnecessary for libx264. The default setting will use as much CPU as it's able to.
    – Amorphous
    Commented Feb 27, 2021 at 0:15
  • @Amorphous Nice comment about I/O bottlenecking. Reading and writing on separate disk drives would seem to be indicated in general and perhaps writing to the faster RAM disk in particular. Commented Mar 27, 2021 at 6:52
  • Exactly what I wanted to know, thank you. Commented Jul 7, 2021 at 16:44
10

In 2015 on Ubuntu 14.04 with ffmpeg 0.8.10-6, it used 1 core on a 4 core system. htop showed this; only one core was used, and I got 16 fps conversion rate for a FullHD video.

Using -threads 4 made all my CPU cores go to 100% and I got a conversion rate of 47 fps.

I used the following command:

$ ffmpeg -i foo.mp4 -y -target pal-dvd -aspect 16:9 dvd-out.mpg
0
10

I was playing with converting in a CentOS 6.5 VM (Ryzen 1700 8c/16t - vm assigned 12 of 16 cores). Experiments with 480p movies netted the following:

Thread option/Conversion Rate (fps @ 60 secs)

(none/default)/130fps
-threads 1/70fps
-threads 2/120fps
-threads 4/185fps
-threads 6/228fps
-threads 8/204fps
-threads 10/181fps

The interesting part was the CPU loading (using htop to watch it).
Using no -threads option wound up at the 130fps range with load spread out across all cores at a low-load level.
Using 1 thread did exactly that, loaded one core at 100%. Using anything else resulted in another spread-load situation.

As you can see, there's also a point of diminishing returns, so you'd have to adjust the -threads option for your particular machine. For my setup specifically, using the -threads 6 (on a 12 core machine) resulted in the best FPS when converting the video (from h264 to x264 at a different bitrate to force a conversion) and returns actually diminished the more threads I threw into it.

It could have been a memory issue too - it only had 1GB assigned to the VM. I may tweak that and see if that changes anything. Still - it does show that using the -threads option can increase performance so run some tests on your particular machine at different levels to find your setups sweet spot.

3
  • 1
    Could you please add what do you mean by "converting"? Ideally, the exact command. Commented Nov 14, 2018 at 2:40
  • 4.1.3 on Ubuntu 18.04 and very similar result. Default was "low load on all cores". Commented Jun 6, 2019 at 3:54
  • I guess the reason why you got optimal at 6 threads on the "12 core" machine (cpu not specified, different from first one listed) is that 6 may have been the real number of cores, and 12 the number of threads? Commented Jun 6, 2019 at 3:56
2

End of 2023, with and without -threads 4, only one core of my i7 mobile CPU (4 real cores, x2 hyperthreaded) is at 70-95% at a time when transcoding audio from mp3 to opus. Setting the parameter did not improve performance as it did for Ondra in 2018.

09/2023, Anton Khirnov explained internal technical debts at the VDD conference in dublin, and that he and the community have been refactoring ffmpeg since 2021. We may expect changes to multithreading that will improve performance (and code quality).

Once the patchset landed, further performance tests need to be carried out. It is to be expected that ffmpeg then will be able to use as many threads as parallization allows for – which depends on the task given to ffmpeg.

2
  • It's not "-treads", but "-threads"
    – Slavik
    Commented Jan 8 at 0:43
  • Sorry, typo corrected above.
    – nursoda
    Commented Jan 9 at 6:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .