How to Use FFmpeg -threads to Speed Up Encoding

The -threads parameter in FFmpeg controls the number of processing threads allocated to decoding, filtering, and encoding tasks. By properly configuring this parameter, you can maximize CPU utilization for faster video conversions, prevent FFmpeg from overwhelming system resources, or optimize batch processing workflows. This guide covers how -threads functions, its optimal syntax, and best practices for balancing speed and hardware efficiency.

Understanding the Default Behavior

By default, FFmpeg sets -threads to 0. When set to 0, FFmpeg automatically detects the number of logical CPU cores available and selects an optimal thread count based on the codec being used (typically 1.5 times the core count for libraries like libx264).

In most everyday scenarios, the default setting provides the fastest single-file encoding performance without requiring manual intervention.

Basic Syntax and Placement

The placement of the -threads flag in your command determines whether it applies to decoding, encoding, or both:

For Encoding (Output): Place the flag after the input file to control the encoder threads.
```
ffmpeg -i input.mp4 -c:v libx264 -threads 8 output.mp4
```
For Decoding (Input): Place the flag before the input file to limit decoding threads.
```
ffmpeg -threads 4 -i input.mp4 -c:v libx264 output.mp4
```
Stream-Specific Threading: Target a specific stream by appending a stream specifier:
```
ffmpeg -i input.mp4 -c:v libx264 -threads:v 4 -c:a aac output.mp4
```

Strategies for Optimizing Encoding Speed

1. Maximize Single-File Encoding

If your goal is to finish a single conversion as quickly as possible on a dedicated machine, leave -threads 0 or omit the flag entirely. FFmpeg will saturate all available cores:

ffmpeg -i input.mov -c:v libx264 -preset medium -threads 0 output.mp4

2. Prevent Diminishing Returns on High-Core CPUs

Video codecs experience diminishing returns when thread counts exceed 16. Extremely high thread counts increase memory bandwidth overhead and slightly reduce compression efficiency. On high-core systems (e.g., 32 or 64 cores), manually capping threads between 8 and 16 per process often yields the best trade-off between speed and output quality:

ffmpeg -i input.mov -c:v libx265 -threads 16 output.mp4

3. Parallel Batch Processing

If you have multiple files to encode, running several FFmpeg processes in parallel with restricted thread counts is significantly faster than processing files sequentially with maximum threads.

For example, on a 16-core system, encode four videos simultaneously, assigning four threads to each instance:

ffmpeg -i video1.mp4 -c:v libx264 -threads 4 out1.mp4 &
ffmpeg -i video2.mp4 -c:v libx264 -threads 4 out2.mp4 &
ffmpeg -i video3.mp4 -c:v libx264 -threads 4 out3.mp4 &
ffmpeg -i video4.mp4 -c:v libx264 -threads 4 out4.mp4 &

4. Reserving System Resources

When encoding in the background while using your computer for other tasks, set -threads to a value lower than your total core count to avoid system lag:

# On an 8-core CPU, leaving 2 cores free for other applications
ffmpeg -i input.mkv -c:v libx264 -threads 6 output.mp4

Advanced Codec-Specific Thread Options

For encoders like libx264 and libx265, multithreading is divided into two methods: frame-threading (encoding multiple frames simultaneously) and slice-threading (encoding parts of a single frame simultaneously).

You can pass codec-specific controls using -x264-params or -x265-params:

libx264:

ffmpeg -i input.mp4 -c:v libx264 -x264-params threads=8:sliced-threads=0 output.mp4

libx265:

ffmpeg -i input.mp4 -c:v libx265 -x265-params pools=8:frame-threads=4 output.mp4

Frame-threading provides better speed and compression efficiency, while slice-threading provides lower latency, which is preferable for real-time live streaming.