Before trying to reduce CPU usage while looping videos to YouTube Live from a VPS, check whether FFmpeg is re-encoding the video. If your source is already compatible with YouTube and the output needs no changes, stream copy may avoid the video-encoding work; it cannot filter or convert an incompatible stream.
Start by observing the running command, its CPU use and the input file’s streams. Then decide whether to copy, re-encode or use another approach. A command change that looks simpler can still fail at the output, or leave an unnecessary encoder running.
Find out whether FFmpeg is re-encoding
Look at the complete FFmpeg command before editing it. An output option such as -c:v libx264 explicitly selects a software video encoder. A filter such as scale, fps or drawtext also means the video must be decoded and processed before it can be sent onward. Those are signs that the process is doing more than passing the original encoded video through.
If the command has no obvious encoder choice, inspect FFmpeg’s startup and status output as well as the process list. The output should identify input streams and the selected output streams. If an encoder is named for the output video, that is a useful clue; if the output says the video is being copied, it is not being video-encoded by that FFmpeg output. Do not infer the workload from CPU percentage alone: other processes on the VPS, audio encoding, filters, and resource limits can all affect what you see.
Record a baseline while the stream is running normally: the FFmpeg command, process CPU use over time, input and output codecs, and YouTube’s stream-health status. A single reading can mislead if the stream has only just started or is reconnecting. Check the VPS provider’s process monitor or a standard system monitor, and make sure you are looking at the FFmpeg process rather than total host activity where other workloads share the machine.
The distinction matters because -re and looping options do not turn encoding off. FFmpeg’s -stream_loop -1 repeats an input indefinitely, while -re reads a file at its native rate to pace delivery. They control input behaviour, not whether the output is re-encoded. If your current command loops and paces the file but still selects libx264, it continues to encode video.
Keep the stream key private while investigating. It may appear in a command line, shell history, a process listing or a screenshot if it is included directly in the destination URL. Redact it before sharing logs, and use a method that does not expose the key in material you publish. If the stream is not arriving despite a running FFmpeg process, the checks in troubleshooting an RTMP connection refused on a VPS in India address a different part of the problem: whether the connection reaches YouTube.
Understand why encoding uses CPU
Re-encoding takes the compressed video apart into frames, applies any requested processing, then compresses it again. FFmpeg describes this as transcoding: decoding and then encoding a stream. Encoding is computationally expensive compared with passing through an already encoded stream, although the load in any particular case depends on the codec, resolution, frame rate, encoder settings, VPS allocation and any filters.
For a prerecorded loop, the source file is not changing from one pass to the next. If the source already has a suitable video codec and the output container accepts it, re-encoding solely to send it onward may be unnecessary. FFmpeg’s documentation recommends stream copy when transcoding is not needed, partly because it avoids computational work and avoids another lossy encoding generation. Read the FFmpeg documentation on stream copy and transcoding for the option semantics and caveats.
A busy CPU is not proof that video encoding is the cause. FFmpeg could be encoding audio, applying a filter, or handling several streams; another service on the VPS might also be consuming compute. Conversely, low average CPU does not establish that an encoding setup is safe under every load. Watch the process across a representative period and note whether it is the encoder, another process or a network issue that needs attention.
Pacing is also easy to misread as an optimisation. -re is useful when file input should be read at its native frame rate rather than sent as quickly as possible; FFmpeg’s documentation describes this behaviour via -readrate 1. It does not reduce the work required by a selected video encoder. Use it for timing where appropriate, and judge CPU changes by comparing the same workload before and after a change.
Check whether the source is compatible with stream copy
Before trying -c copy, identify the input container and each stream’s codec, dimensions, frame rate and audio format. Tools such as ffprobe can report this information without requiring you to guess from the filename. A file ending in .mp4 is not enough: the extension describes a container, not the codecs inside it. Inspect the actual file that the VPS reads, not a different copy on your laptop.
Then compare the source with what your planned YouTube output needs. YouTube’s current live encoder settings list RTMP/RTMPS ingest and support H.264, H.265/HEVC and AV1, with up to 60 fps. YouTube also specifies constant bitrate (CBR) and recommends a two-second keyframe interval that should not exceed four seconds. These are output and ingest considerations, not evidence that every file using one of those codecs can be copied into every muxer or protocol unchanged.
Container and stream compatibility both matter. The selected output muxer must be able to carry the codecs in the input, and the ingest path must accept the resulting stream. A source may contain video that is suitable for copy but audio that needs conversion, or a codec that YouTube can ingest but that the chosen output container cannot carry. A successful probe of the input does not test the full path to YouTube.
Make a small, controlled trial before replacing a working broadcast. Use the same input and destination configuration, change only the video handling, and confirm that FFmpeg starts, produces output packets and remains connected. Then check YouTube’s preview and health indicators for both picture and sound. If the output fails to initialise, shows no data or has missing audio, return to the last known working command and inspect the specific stream and muxer rather than adding random flags.
For a channel that needs captions, overlays or repeated edits to its picture, the source may not be a copy candidate even if its codec is accepted. A devotional channel that needs a static title card burned into the video, for instance, needs a filter to alter the frames. The useful question is not just “does YouTube accept this codec?” but “can this exact file be sent to this output unchanged while meeting the channel’s requirements?”
Use -c copy only when no transformation is needed
In FFmpeg, -c copy tells the output to copy encoded streams rather than re-encode them. For a compatible source and output, that can remove the video encoder workload. It does not promise a particular CPU reduction, and it does not imply that CPU use becomes zero: FFmpeg still handles input, timing, muxing and network output, and other processes may be active.
A conceptual command shape for an indefinitely looped file is:
ffmpeg -re -stream_loop -1 -i input.mp4 -c copy -f flv rtmp[s]://destination/stream-key
Treat this as an illustration, not a tested command for your VPS. Input options such as -re and -stream_loop -1 belong before the corresponding -i; -stream_loop -1 means infinite looping, while -re paces file reading at its native rate. The example’s container and destination may not suit your source or chosen ingest method. Confirm the correct muxer, protocol, stream selection and key handling for your setup, and do not paste a real key into public logs or documentation.
You may need to specify streams individually if only one can be copied. For example, where the video is acceptable but the audio is not, a possible approach is to copy video while encoding audio to a compatible format. That is still a choice to validate: check the input and output codec support, command mapping and resulting sound before leaving it unattended. A change that fixes CPU use but drops the audio is not a successful change.
With a no-filter copy output, resizing, frame-rate conversion, text overlays and other frame transformations are not available. If your existing command uses a video filter, removing the encoder while retaining the filter does not make the requested transformation possible through stream copy. Decide whether the transformation is genuinely required; if it is, keep an appropriate encoding path rather than stripping out the feature without checking what viewers will see.
Know when stream copy will not work
Stream copy cannot change a codec, resolution, frame rate or picture content. If the input uses a codec the output path will not accept, or a container cannot carry one of its streams, copy may fail or produce an output YouTube cannot use. The remedy is not a more forceful copy flag; it is to choose a compatible source, change the output requirements, or transcode the stream that needs changing.
Filters require decoding and processing. A scale filter to reduce resolution, a frame-rate filter, an overlay for a schedule, or a text burn-in all alter the video. These operations require a video-encoding stage after the frames have been changed. The same applies to a format conversion: copying the old encoded bitstream cannot turn it into a different codec.
Audio can create a partial incompatibility. You might copy the video and encode only audio if the video stream is already suitable but the audio stream needs a different format. If both need conversion, both need appropriate encoding. Check output stream mapping explicitly; implicit selection may choose an unexpected stream when a file contains multiple audio tracks or other media streams.
Some incompatibilities only appear during a real output test. An input can be readable yet fail when looped, muxed or sent to the chosen ingest endpoint. Inspect FFmpeg’s error messages and YouTube’s stream-health feedback. If you see a rejected codec or missing data, distinguish the failure from a CPU problem: a stream that cannot be ingested is not improved by lowering CPU load.
For a prerecorded programme where the content itself needs no alteration, guidance on streaming pre-recorded videos on YouTube Live can help with the broader workflow. It does not replace checking current YouTube requirements for the exact stream you send. Keep technical compatibility and the channel’s content rights and platform policies as separate checks; confirm current rules on YouTube’s official pages rather than treating a working FFmpeg command as approval.
Inspect CPU use and stream health after changes
Change one thing at a time and compare the result with your baseline. If you switch video from encoding to copy, watch the FFmpeg process and the VPS’s available CPU while the same file is playing. Check long enough to see ordinary operation, not just the first seconds of startup. This is a local comparison, not a universal benchmark: a different source, VPS allocation or background workload can produce a different result.
At the same time, verify what reaches YouTube. YouTube recommends testing before going live and monitoring stream health and audio/video; its live streaming tips also recommend leaving upload-bandwidth headroom, giving 20% as a recommendation. That is network headroom, not a CPU target. A process can have spare CPU and still suffer from insufficient outbound capacity or a broken connection.
Check that the stream continues after the file loops, not only during the first pass. Look for FFmpeg exits, reconnects, timestamp warnings, frozen video, audio gaps and changes in YouTube’s health status. If you use a monitoring view, make sure it shows both the process and the broadcast state; a running process alone does not confirm a healthy picture at the destination. For symptoms such as YouTube showing no data while FFmpeg appears to send RTMP, use the separate no-data troubleshooting steps for FFmpeg.
A useful test record is short and practical: input file name and stream details, command version, CPU observation, whether the output uses copy or encoding, and the health result. Keep secrets out of the record. This lets you roll back intelligently if the stream later changes, and prevents a successful test with one file from being mistaken for proof that every future playlist item is compatible.
Choose a fallback for incompatible sources
If you need transformations or the input cannot be copied, decide what has to change and encode deliberately. Software encoding on the VPS gives you control over conversion, resizing, frame rate and overlays, but it consumes CPU. Its load depends on the encoder, settings and source; measure on your own VPS rather than expecting a fixed saving from a particular preset or resolution.
A lower resolution or frame rate may reduce the amount of work, but it changes the viewer experience and may not fit the source. Choose settings against the content: a static ambience image may tolerate a different output than a fast-moving lesson. YouTube’s bitrate guidance varies by codec, resolution and frame rate. For H.264, its published guidance lists 1080p30 at 5 Mbps minimum and 14 Mbps recommended, and 720p30 at 3 Mbps minimum and 8 Mbps recommended. Those are YouTube ingest recommendations, not CPU measurements or guarantees of quality. Check the current YouTube encoder settings before setting a broadcast profile.
Hardware encoding can move some encoding work from the CPU to supported hardware, but only if your VPS exposes a suitable device and the installed FFmpeg build supports it. YouTube lists NVIDIA NVENC as a hardware-based encoding option; that does not establish that a rented VPS has an available GPU, or that your codec and software configuration can use it. Check the provider’s actual offering and test the output before relying on it.
A managed continuous-stream service is another route if you would rather not maintain an FFmpeg process, but verify that it supports your exact prerecorded-loop workflow, YouTube destination and current operating needs. YouTube’s own tools list includes services for continuous prerecorded streams; that listing is a starting point for checking fit, not a recommendation or endorsement. Compare the practical trade-offs: copy keeps a compatible VPS workflow simple, encoding supports transformations but uses compute, and a managed option may reduce process administration while adding a separate service and cost to assess.
If the VPS process itself is the recurring burden, moving the upload-and-loop task off your own machine can remove the need to keep that FFmpeg session running on your VPS. StreamNeo turns an uploaded video into a YouTube live stream that can continue with your computer switched off, which addresses the particular hassle of keeping a local or VPS process attended; it is YouTube-only, so check that the workflow matches your channel before choosing it.
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 reduce CPU usage?
No. It tells FFmpeg to loop the input indefinitely, but does not disable an encoder or reduce the work of filters. Check the output codec options to see whether video is still being re-encoded.
Does -re make a stream use less CPU?
Not by itself. It paces file reading at the input’s native frame rate, which can be useful for live delivery, but a selected software encoder still has to encode the video. Treat pacing and encoding as separate settings.
Can I always use -c copy for YouTube Live?
No. The source streams and output container must be compatible, and copy cannot convert codecs or apply transformations. Test the actual file and check YouTube’s preview and stream-health feedback before relying on it.
What should I do if copying fails?
Read the FFmpeg error and identify which stream or output requirement is incompatible. If conversion or filtering is needed, encode the affected stream, then monitor CPU and broadcast health under the intended workload.