FFmpeg can use a full CPU allocation while looping a video if it decodes, filters, scales or re-encodes the frames on every pass. The loop itself repeats the input; it does not tell you how much work the output path performs.
Without your command, source file, output destination and process measurements, there is no single confirmed cause. Start by checking whether the load is sustained, then trace the command from input to output before changing settings.
Check whether CPU use is sustained
A brief rise in CPU when a process starts, opens a file or establishes a connection is different from a process that holds the instance near its available capacity throughout playback. Watch the load while the stream is behaving normally, including after the initial start-up. If it rises only at transitions or when a file is opened, that points to a different investigation from continuous high use.
Compare two views: the FFmpeg process’s own CPU use and the CPU metric for the Vultr instance. A process-level tool such as top or htop can show whether FFmpeg is the main consumer and whether more than one FFmpeg process is running. Vultr’s Compute Cloud documentation describes CPU usage monitoring for its instances; consult the current Vultr interface and documentation for the metric available to you.
Check how many vCPUs your instance has and whether other jobs share the workload. A process showing high use on one core does not necessarily mean the whole instance is saturated; tools can display CPU percentages differently. Likewise, several individually moderate FFmpeg jobs may compete for the same available capacity. Do not infer a particular instance limitation from the word “Vultr”: the instance size and workload are not specified here.
If FFmpeg is not the process consuming the CPU, investigate the other process before changing video settings. If the instance metric and FFmpeg process both show sustained pressure, move on to the command. This distinction keeps you from tuning an encoder when the actual work is elsewhere.
Inspect the command and input loop
Get the full command as it was launched, including options before and after the input. The relevant options are easy to miss if you inspect only a wrapper script or the final output line. Look for -stream_loop -1, which FFmpeg documents as an infinite input loop, but also note every -i, codec option, filter, output destination and any additional FFmpeg process.
Option position matters in FFmpeg. Some options apply to an input, others to an output, and -stream_loop is an input option. Record which options precede each -i and which follow it. If the process is launched by a script, service manager or panel, inspect the command that actually reaches the running process, not just the settings screen that generated it.
A file input might be read at normal speed for a live output using -re before the input. FFmpeg describes -re as reading at the native frame rate, equivalent to -readrate 1. It controls how quickly file input is consumed; it does not turn encoding off or make a costly filter chain cheap. Keep it when the workflow needs real-time pacing, rather than treating it as a CPU reduction switch.
The FFmpeg documentation defines these options and their placement. Documentation changes over time, and installed builds can differ, so check the help output and version on the machine as well. The Vultr guide to installing an FFmpeg build is relevant if you need to establish which build is installed; it does not diagnose this CPU symptom by itself.
If the goal is a YouTube broadcast rather than simply looping a local file, the destination and live-stream requirements also constrain the command. For a separate example of keeping source material in a continuous playlist, see how to loop a playlist in XSplit Broadcaster. That workflow is not interchangeable with every FFmpeg command, but it makes clear that repeating content and processing it for output are separate choices.
Separate repetition from frame processing
The input loop says, in effect, “read this input again”. It does not mean FFmpeg can repeat compressed data without examining it in the way your output needs. Depending on the command, FFmpeg may decode each video frame to raw image data, apply transformations, then encode new compressed frames. Those stages repeat as the loop cycles.
A useful first reading of a command is to follow one stream through it: input file, any decoding needed, filters or frame-rate changes, output codec, then muxing and delivery. If the input and required output formats are compatible, the command may be able to copy compressed streams instead of decoding and encoding them. If the desired output differs in resolution, frame rate, codec or visual content, processing may be necessary.
This distinction is also why a loop can be light in one workflow and demanding in another. Repeating packets that are already suitable for the destination is not equivalent to decoding and encoding every frame in software. Yet “looping” alone does not establish that either path is occurring; the command and output requirements do.
For a YouTube live workflow, the source file may need to be converted or configured for the output, and you should verify that the resulting stream behaves correctly. The practical question is not simply “can I loop it?” but “what must happen to each frame before the destination can use it?” If you are weighing source format conversion, the article on whether YouTube Live can handle HEVC through OBS covers a related compatibility decision, though its OBS workflow is not a substitute for checking your own FFmpeg output.
Look for filters and scaling
Search for -vf and -filter_complex. These options can introduce one or more operations on video frames: resizing, cropping, overlays, frame-rate conversion, colour adjustments or other transformations. A filter may be needed to produce the output you want, but it means the stream is being processed rather than simply passed through unchanged.
Scaling is a particularly useful clue because it requires work on image frames. A command that resizes a source to a different output resolution must process frames, even if the loop option itself adds no complicated transformation. Frame-rate conversion also changes the sequence of frames delivered; depending on the method, frames may be dropped, duplicated or otherwise handled to meet the target rate.
Do not remove a filter just because it appears in the command. First decide what it does and whether the output depends on it. An overlay may carry essential information, such as programme or episode details; a scale may be required by the destination workflow. If you remove or simplify a filter for a test, compare the resulting picture and stream behaviour as well as CPU.
Audio has its own path. Check for audio filters and audio encoder settings separately from video options. A command can copy video while still processing audio, or vice versa. If you use chapters or on-screen labels to orient viewers in a long-running programme, the article on showing podcast episode chapters during an always-on stream is a reminder that presentation features can involve changes to the output, not merely repetition of the source.
Identify stream copy versus re-encoding
Look for -c:v copy or a broader -c copy in the output options. Stream copy asks FFmpeg to pass through the compressed stream rather than decode, filter and re-encode that copied stream. By contrast, an encoder option such as -c:v libx264 indicates video re-encoding with that encoder. Another named video encoder has the same basic implication: frames are encoded for output rather than copied as-is.
| Output path | What FFmpeg generally does | Main trade-off |
|---|---|---|
Video stream copy (-c:v copy) |
Passes through compressed video packets without video decode, filtering or re-encoding | Lowers processing work for video, but preserves source parameters and cannot apply video filters to copied frames |
Software re-encoding (for example, -c:v libx264) |
Encodes video frames for the chosen output | Allows output changes and filters, at the cost of processing work and a need to check quality and settings |
| Mixed audio and video settings | May copy one stream while processing the other | Diagnose audio and video separately; one copied stream does not mean the whole command is copy-only |
If the destination supports the source codecs and container or protocol, a temporary copy test can be informative. Try explicit stream copy only when it is valid for that workflow, then confirm that the resulting output plays correctly and is accepted by the destination. If CPU falls substantially during an otherwise comparable test, re-encoding was likely a significant contributor. If it does not, investigate the remaining work rather than concluding the loop itself must be expensive.
Copy is not a universal replacement for encoding. A copied stream cannot be resized, overlaid or converted to a different codec in the same path. It may also retain frame rate, resolution or codec parameters that do not fit the destination. If you need those changes, you need an appropriate processing path and should tune it with output quality in view. The related guide to setting CBR bitrate in OBS for a playlist stream discusses a different tool, but the wider point applies: output requirements shape the choices you can make.
Review process-level measurements
Once you know the command, collect measurements during a normal period of playback. Note the FFmpeg process, whether its CPU use is steady or fluctuating, the number of active FFmpeg jobs and the instance-level CPU reading. If multiple streams run at once, test whether the pressure follows one stream or the combined workload. Avoid treating a single screenshot as proof of the cause.
If the command uses stream copy and CPU remains high, look beyond video encoding. Check for filters on audio or video, other processes, multiple FFmpeg instances, and how the output is being muxed and sent. The available evidence does not identify one default alternative cause, so use measurements to narrow the possibilities instead of assuming network delivery or Vultr itself is responsible.
FFmpeg’s thread settings can affect how work is scheduled, but they are not a general CPU-saving fix. The documentation describes filter-pipeline thread controls, with defaults based on available CPUs. Reducing a thread count may limit concurrency or alter resource use, but can also slow the job; test it only when measurements suggest it is relevant. Do not copy a setting from an unrelated multi-stream example and assume it fits your workload.
Hardware acceleration is similarly conditional. Verify that the virtual instance exposes a suitable accelerator and that the installed FFmpeg build supports the required hardware path. Hardware processing can involve transfers between device and system memory, and FFmpeg’s documentation notes that some approaches may perform worse than software decoding on modern CPUs. Confirm the actual supported path and compare it under your own output settings before relying on it.
Change one workload setting and retest
Keep a record of the original command and output behaviour. Then change one variable at a time and run a comparable test long enough to see the normal workload, rather than changing resolution, encoder preset and concurrency together. A single-change test helps you determine whether an observed CPU change came from that setting or from a different workload.
If re-encoding is required, possible test variables include output resolution, frame rate, encoder preset or the number of simultaneous jobs. Lowering resolution or frame rate can reduce the amount of video work, but changes what viewers receive. An encoder preset can trade encoding speed against compression efficiency and output size; its exact effects depend on the encoder and configuration. Choose the result that meets your viewing and delivery needs, not a setting that merely produces a lower CPU reading.
For each test, compare CPU use with the same input, destination, duration and number of concurrent jobs where practical. Also check that the stream remains stable, audio stays in sync, and the picture is acceptable. If -re is needed to send a file at real-time pace, retain it while testing the encoder or filter settings; it is not a substitute for reducing the amount of encoding work.
When the file is suitable but maintaining an always-on broadcast also means keeping a computer running and recovering after a dropped process, StreamNeo can remove that particular need to keep your own computer on: it turns an uploaded video into a YouTube live stream that is monitored and restarted if it drops. It is YouTube-only, so it does not replace diagnosing an FFmpeg workflow for another destination or resolving an output-format requirement.
Make changes only after you know what the current command is doing, and keep a copy of any working configuration.
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 -stream_loop -1 itself use 100% CPU?
Not necessarily. It repeats the input indefinitely, while the output path determines whether FFmpeg copies compressed streams or decodes, filters and encodes frames. Inspect the complete command and measure the FFmpeg process before attributing sustained CPU use to looping.
Will adding -re lower CPU use?
-re paces file input at its native frame rate, which can be useful when sending a file as a live stream. It does not disable filters or encoding, so it should not be treated as an encoder optimisation. Keep it when real-time pacing is required and investigate processing work separately.
Should I change libx264 to -c copy?
Only if the destination accepts the source stream’s codec and parameters and you do not need transformations such as scaling or overlays. Copying can avoid video re-encoding, but it cannot perform those changes. Test the output for compatibility and playback before adopting the command.
Is the Vultr instance the problem?
The title alone does not reveal the instance size, vCPU allocation, other processes or exact FFmpeg workload. Compare process-level CPU with the instance metric and count concurrent jobs, then use the command to identify processing stages. Check current Vultr documentation rather than inferring a provider-side cause from high CPU alone.