If FFmpeg is using too much CPU on your VPS, first find which part of the command is doing the work and which video encoder is active. Then test an encoder-specific thread setting while checking whether the stream still processes frames in real time.
A thread setting can reduce parallel encoding work, but it is not a universal CPU percentage limit for FFmpeg. Filters, audio processing, input handling and other processes can still use CPU, and the right setting depends on the encoder, video and VPS.
Find what is using CPU during the stream
Start with the command that is actually running, not the command you intended to run. A VPS may be running an older process in a terminal session, a service, a container, or a script with different options from the ones you are editing.
During a representative stream, inspect the process list and note the FFmpeg command line. On a Linux VPS, tools such as top or htop can show the total CPU use and the individual process. They can also help you see whether another process is competing with FFmpeg. Do not assume that the largest FFmpeg process is the only source of load if your command uses several inputs, filters or helper processes.
Look at the workload while the stream contains the material that normally causes the most work. A mostly still devotional image and a fast-moving music video do not put the same demand on an encoder. If your channel alternates between a static prayer card, animated text and video footage, observe more than one of those scenes.
Write down the conditions of the test:
- input resolution and frame rate
- video encoder and preset
- output resolution and frame rate
- whether filters are being used
- whether the source is being read from a file or is already live
- audio codec and any audio filters
- CPU use and whether the output remains continuous
This gives you a baseline. Without one, a lower CPU reading may simply mean that the test clip was easier to encode, or that the stream was no longer keeping up.
If the VPS is also responsible for downloading files, generating graphics, running a playlist, or handling another channel, record that as part of the baseline. You are trying to leave useful headroom for the whole machine, not merely make the FFmpeg number look smaller.
For a broader view of failure signs, see this guide to monitoring an FFmpeg YouTube stream on a VPS. CPU use is only one part of the check. A stream can show modest process usage and still have trouble if frames are delayed, the connection is unstable, or YouTube reports an encoding problem.
Identify the active video encoder
The option you need belongs to the video encoder, so identify that encoder before changing anything. In a typical command, look for the video codec option after -c:v or -vcodec, such as libx264, libx265, libaom-av1, or a hardware-specific encoder. If the command does not specify one, inspect the complete command and FFmpeg output rather than guessing from the file extension.
The encoder name matters because FFmpeg does not expose identical controls for every encoder. A setting that is accepted by one encoder may be ignored, rejected, or have a different effect with another. The installed FFmpeg build also matters because available encoders and options can vary.
You can ask the local build for its encoder help. For example:
ffmpeg -h encoder=libx264
Replace libx264 with the encoder shown in your command. The FFmpeg documentation describes encoder options and multithreading, but the help output from the build on your VPS is the practical reference for the syntax available there.
Do not confuse the input codec with the active output encoder. A source file may already contain H.264 video, while your command decodes it, scales it, applies a filter, and encodes it again. In that case, the source codec does not tell you what is consuming CPU during the output stage.
Also check whether you are transcoding at all. If the source is already encoded in a form YouTube accepts and no video transformation is required, stream copying may avoid video encoding. A command using -c:v copy does not perform a new video encode, but it is only suitable when the source format, timing and stream requirements work for your complete live workflow. It is not a general solution for files that need resizing, overlays, frame-rate changes or other processing.
A simple way to reason about the command is to separate its stages: read the input, decode it, apply filters, encode the video, encode the audio, and send the output. Limiting the video encoder's threads primarily addresses the encoding stage. It does not automatically limit decoding, filtering, audio encoding, network activity or other FFmpeg work.
Inspect encoder-specific thread options
Once you know the encoder, inspect its help for threads, frame or slice threading, and any encoder-specific controls that affect speed. The exact names and behaviour differ. Some encoders expose a general thread count, while others have additional modes or rely on options such as a preset to change the amount of work.
A common FFmpeg form for a video stream is:
-threads:v 2
The :v stream specifier means that the option is directed at the video stream. Treat this as a starting experiment, not a promise that FFmpeg will use only two CPU cores or remain below a particular percentage. The encoder may use threads differently, and other stages of the command can continue using CPU.
Check the local help before adding the option to a production command. If the encoder does not list the option or your build reports an error, do not force the syntax because it appeared in an example for another encoder. Some options are global, some are codec-specific, and option placement can affect how FFmpeg applies them.
Threading can also be organised in different ways. Frame-based work can process separate frames in parallel, while slice-based work divides parts of a frame. These modes can have different effects on throughput, latency and quality. You do not need to change every threading option just because you want less CPU use. Change one meaningful variable at a time so that you can tell what caused the result.
Do not use -cpucount as a production CPU limiter. FFmpeg documents it as an override for the detected CPU count and describes it as intended for testing. It is not documented as an operating-system quota, and it does not establish a hard ceiling for every FFmpeg operation. The FFmpeg command-line documentation should be checked if you are considering it, but a test-oriented CPU-count override is not a substitute for resource control.
Change the thread count as a measured experiment
Make a copy of the working command and change only the video encoder thread setting. Keep the input, resolution, frame rate, preset, bitrate mode, keyframe settings, audio and destination the same. That makes the comparison useful.
Do not begin by selecting an arbitrary value because it sounds conservative. The question is not “How many threads should FFmpeg use?” in isolation. The question is whether a particular encoder, at a particular output size and frame rate, can maintain the required pace with fewer parallel workers on this VPS.
A practical test sequence is:
- Record the baseline while the normal command runs.
- Confirm the active encoder with the command line and local encoder help.
- Add an encoder-supported video thread setting.
- Run the same representative material and observe CPU use, output timing and stream messages.
- If the output remains healthy, test the next lower setting.
- Stop when real-time performance becomes unreliable, then return to the last workable configuration.
The change may reduce CPU use, but it may also reduce encoding speed. A lower thread count can cause FFmpeg to fall behind even when the stream still appears connected. It can also alter how much work the encoder can complete for a given preset and output size. Treat a lower CPU reading as useful only if the stream continues to produce the expected output.
Compare the tests in a table or log rather than relying on memory. For example:
| Test | Video thread setting | CPU and VPS headroom | Real-time pace | Picture quality | YouTube health |
|---|---|---|---|---|---|
| Baseline | Existing setting | Record observation | No growing delay | Reference image | Record messages |
| Trial A | Lower supported value | Record observation | Check during motion | Compare same scene | Check again |
| Trial B | Lower supported value | Record observation | Stop if it falls behind | Compare same scene | Check again |
There is no universal thread value that suits every VPS. A shared VPS with competing workloads may need a different balance from a dedicated machine, and the same setting can behave differently when the output changes from a static 720p scene to moving 1080p video.
Use a short controlled test before changing an overnight channel. If possible, make the test representative in duration and content, and include the audio and upload path used by the real stream. A setting that looks fine during a quiet menu screen may fail when a full-motion segment begins.
Check whether FFmpeg keeps pace in real time
A live stream must produce and deliver frames at least as quickly as the output timeline requires. CPU use alone cannot tell you whether that is happening. Watch FFmpeg's progress output for signs that processing is falling behind, and look for a growing delay rather than a single temporary fluctuation.
When a file is being used as the live source, FFmpeg's -re option reads the input at its native frame rate. The FFmpeg documentation notes its usefulness when feeding a file as a live source. It is often appropriate for a recorded file being sent as live output, but do not add it reflexively to an input that is already live and arriving in real time.
If you use benchmarking or progress reporting, keep the interpretation simple. Timing information can help show whether the encode is keeping up, but it does not replace watching the actual output and YouTube's stream health messages. Test the same command shape that you will leave running.
A falling-behind encoder can create several practical symptoms: the output may develop increasing delay, the process may remain busy without producing timely frames, or the broadcast may eventually stop meeting the intended cadence. The exact symptom depends on the input and output pipeline. If the stream is important, do not wait for an overnight failure to discover that a lower thread count was too aggressive.
YouTube recommends testing with representative audio and motion and monitoring stream health and messages during the event. Its current live encoder settings, bitrates and resolutions guidance should be your reference for the output requirements, including the applicable codec, bitrate guidance and frame rate choices.
Keep the upload path in the test as well. A VPS can encode successfully while the connection to YouTube is the part that fails. For operators streaming from India, connection behaviour can vary by provider and route, so this guide to keeping an FFmpeg YouTube stream running on a JioFiber connection is useful when the stream is sent from that type of connection. The same principle applies on a VPS: distinguish encoding delay from delivery trouble.
Balance CPU workload against output quality
If lowering the thread count makes the encoder fall behind, reduce the workload rather than continuing to remove threads. The main choices are output resolution, frame rate, encoder preset and, where technically suitable, stream copy. Each changes the result in a different way.
A lower resolution reduces the number of pixels processed per frame. A lower frame rate reduces how many frames must be produced over time. Either may ease CPU demand, but both change what viewers receive. A less demanding encoder preset may produce frames more quickly, while changing the balance between encoding effort and image quality. Test the same moving and detailed scenes that matter to your channel.
Do not change YouTube's delivery settings solely because the VPS is busy. YouTube's guidance recommends CBR, a two-second keyframe interval and no more than four seconds between keyframes, along with codecs and bitrate ranges appropriate to the chosen resolution and frame rate. Check the current official table rather than copying a value from an old tutorial.
A channel showing a static temple image may tolerate a different workload from a local news loop with scrolling text, or a nature stream with moving water. A bhajan channel with album artwork may be light on video encoding but still include audio processing and image overlays. Test the material your viewers actually see.
When comparing a change, assess four things together:
- CPU load and the headroom left for the VPS
- whether the encoder remains at least real time without growing delay
- visual quality at the selected resolution and frame rate
- YouTube stream health and upload stability
If the source is already compatible and you do not need to transform it, stream copy may be worth testing. It avoids a new video encode, but it does not fix unsuitable timestamps, unsupported parameters, unwanted dimensions, or a workflow that needs overlays. Validate the complete broadcast before relying on it.
For a recorded channel, you may also find that the problem is not the encoder alone. Repeatedly decoding and filtering large files, creating transitions, or mixing several audio sources can keep CPU use high even after you limit video threads. The right remedy may be simplifying the filter chain or preparing compatible files in advance rather than forcing a thread limit.
Know when an FFmpeg option is not enough
An encoder thread setting is useful when you want to reduce parallel work while preserving the current command. It is not a hard boundary for the complete FFmpeg process. If you need a firm ceiling or stronger isolation, look for a resource-control feature provided by the operating system, container environment or VPS platform and verify its current documentation.
That type of control is separate from FFmpeg's encoder options. It can constrain a process at a broader level, but it may also make the stream fail to keep up if the ceiling is below the workload. Before applying one, confirm how it treats all relevant processes and whether the VPS provider permits the feature.
Do not solve a capacity problem by repeatedly lowering threads until the output becomes unreliable. If the tested workload needs more CPU than the VPS can provide, your choices are to reduce the output workload, move other work elsewhere, choose a machine with more suitable capacity, or use a managed workflow that removes the need to keep your own computer or VPS running.
For a channel where the operational problem is keeping a file streaming continuously rather than controlling a particular FFmpeg process, StreamNeo removes the need to keep a local FFmpeg command and VPS running: you upload the video, provide the YouTube stream key, and the broadcast runs with automatic monitoring and restart. It is YouTube-only, so confirm that it matches your publishing requirement before treating it as a replacement for a configurable VPS pipeline.
If your channel has several recorded programmes, playlist gaps and restart behaviour may matter as much as CPU. This guide to streaming different videos in a YouTube Live playlist without a gap covers a separate part of that operational problem. Keep it separate from encoder tuning: a reliable playlist does not make an overloaded encoder reliable.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does -threads:v N cap FFmpeg at a fixed CPU percentage?
No. It directs a thread setting at the video stream when the selected encoder and build support it, but it does not cap all FFmpeg work at a fixed percentage. Filters, decoding, audio, output handling and other processes can still use CPU.
How many threads should FFmpeg use on my VPS?
There is no setting that can be guaranteed from the VPS size alone. Start with the active encoder's local help, test a lower supported value with representative content, and keep it only if the output remains real time and the stream stays healthy.
Should I use -cpucount to limit CPU in production?
No. FFmpeg documents -cpucount as a detected-CPU-count override intended for testing, not as an operating-system CPU quota. Use an encoder-specific experiment for FFmpeg-level tuning, or investigate a verified VPS or operating-system resource-control feature when you need a broader ceiling.
What should I change if the stream falls behind after lowering threads?
Return to the last setting that kept pace, then reduce the workload by testing a suitable resolution, frame rate or less demanding preset. Check the picture, timing, audio, upload stability and YouTube stream health together before leaving the revised command running.