How to Limit FFmpeg CPU Usage on Multi-User Servers

This article explains how to configure the thread count in FFmpeg to prevent it from consuming all available CPU resources on a shared or multi-user server. By default, FFmpeg attempts to utilize all available CPU cores to speed up processing, which can quickly lead to server instability or lag for other users. You will learn how to use the -threads option, understand how FFmpeg allocates threads, and discover operating system-level limits to keep your server running smoothly.

Using the FFmpeg -threads Parameter

The primary way to control resource consumption in FFmpeg is by explicitly setting the thread limit using the -threads flag. By default, FFmpeg is set to 0, which automatically spawns a thread count optimized for your system’s total logical CPU cores.

To limit the thread count, place the -threads option before your output file in the command line:

ffmpeg -i input.mp4 -threads 2 output.mp4

In this example, FFmpeg is restricted to using a maximum of 2 threads, ensuring the remaining CPU capacity remains available for other users and processes on the server.

Choosing the Right Thread Count

When managing a multi-user server, you should determine thread allocation based on your server’s total hardware capacity and the expected number of concurrent jobs.

• Low-resource encoding (1–2 threads): Ideal for background tasks, audio conversion, or when many users are running encodes simultaneously.
• Moderate encoding (4 threads): A balanced setting for 1080p video encoding that provides decent speed without locking up a modern multi-core CPU.
• Dynamic allocation: If you run a web application that triggers FFmpeg, write logic in your backend code to scale the -threads value dynamically based on current system load.

Limiting Threads for Specific Codecs and Filters

Some video codecs and filters handle threading independently. If you are using complex filtering or specific codecs like libx264 or libx265, you may need to pass additional parameters to ensure they respect your limits.

Codec-Specific Threading

For the widely used H.264 encoder (libx264), you can pass the -threads parameter directly as a private option:

ffmpeg -i input.mp4 -c:v libx264 -threads 2 output.mp4

Filter Threading

If your command utilizes heavy video filters (like scaling or deinterlacing), these filters can spawn their own threads. You can restrict filter-specific threads using the -filter_threads option:

ffmpeg -i input.mp4 -filter_threads 2 -vf "scale=1280:720" output.mp4

Supplementing FFmpeg Settings with OS-Level Limits

While the -threads parameter is highly effective, users or automated scripts can still bypass these restrictions or run multiple instances of FFmpeg at once. To guarantee server stability, combine FFmpeg configuration with operating system resource controls.

1. Using nice for CPU Scheduling

You can lower the CPU priority of the FFmpeg process using the nice command on Linux. This ensures that when the CPU is busy, other system processes get priority:

nice -n 19 ffmpeg -i input.mp4 -threads 2 output.mp4

A niceness value of 19 represents the lowest priority, meaning FFmpeg will only use CPU cycles that no other process currently needs.

2. Using cpulimit

If you want to restrict the actual CPU percentage of the FFmpeg process regardless of thread count, you can use the cpulimit utility:

cpulimit -l 50 -- ffmpeg -i input.mp4 output.mp4

This command restricts the FFmpeg process to a maximum of 50% of a single CPU core.