Argthtjtr

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

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.

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

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

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.

assuming you have threading enabled, it assigned 1.5x number of cores.

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 2600X system were maxed without any -thread argument.