A 1 vCPU VPS may run a straightforward FFmpeg relay without re-encoding, provided the source streams are compatible with the output and the host can keep reading and sending them continuously. With stream copy, FFmpeg passes encoded audio and video through instead of doing the main decode-and-encode work, but that does not guarantee a particular VPS will cope.
The practical answer depends on more than the CPU count: check the actual playlist inputs, output format, source availability and sustained network capacity. If you need to resize, apply filters, mix audio or convert a codec, FFmpeg must transcode, and the CPU question changes.
What stream copy does to CPU workload
When FFmpeg transcodes video, it decodes the incoming frames and encodes new ones. Encoding is computationally expensive compared with passing already-encoded packets through, and it can also introduce quality loss. With stream copy, FFmpeg copies selected encoded streams rather than recreating them. The command option commonly used for this is -c copy; it can be applied to selected streams as -c:v copy and -c:a copy.
That distinction explains why one vCPU can be plausible for a simple relay. If your job is to read a compatible source, send its packets to the destination and maintain the connection, the VPS is not also being asked to encode every frame. FFmpeg still has work to do, and the operating system, network activity and other processes still use resources. Pass-through is therefore a way to avoid the largest video-processing workload, not a promise that every one-vCPU host will run every stream.
It also helps to separate three questions. Can FFmpeg read the source reliably? Can it place the selected streams in the chosen output format and send them to the intended ingest? Can the VPS sustain the outgoing traffic? Stream copy mainly addresses the CPU cost of changing the media. It does not answer the other two questions.
FFmpeg’s documentation on stream copy and transcoding describes the distinction and explains why copying is preferable when conversion is not needed. The same manual notes that streams are transcoded by default unless you request copying. For a more complete deployment context, the guide to running a YouTube livestream with FFmpeg on an Ubuntu VPS in India is a useful companion; this article focuses on whether the copying part avoids enough CPU work for a small VPS.
Check whether playlist inputs can be copied
“Playlist” can mean several different things. You might have a local list of files that you want to broadcast in sequence, a single local file that you loop, or an online playlist whose entries are fetched from somewhere else. Those are not interchangeable input arrangements. Before testing CPU use, write down what FFmpeg will actually read and how it will move from one item to the next.
For each item, identify the video and audio codecs, their container, and whether the stream is complete and readable. A file extension is not enough to establish what is inside. Inspect the media with a tool such as ffprobe, then confirm the actual FFmpeg command selects the intended streams. A playlist may contain items with different codecs, missing audio, different time bases or other variations. Even if the first item copies successfully, later entries may fail or behave differently.
A command pattern for a compatible input might include explicit mapping and copy options, for example:
ffmpeg -re -i input.mp4 -map 0:v:0 -map 0:a:0 -c:v copy -c:a copy \
-f flv "$YOUTUBE_INGEST_URL/$STREAM_KEY"
Treat this as a pattern to adapt and test, not a universally working recipe. The input name, stream selection, output container and ingest details must fit the actual media and destination. If there is no audio stream, for example, a mapping that requires audio will not match the source. If an input is segmented or comes from a remote playlist, its reader and reconnection behaviour also matter. Do not assume that putting a YouTube playlist URL after -i makes it a supported direct pass-through source; the exact source format, access method and current platform rules need to be checked independently.
The -re option asks FFmpeg to read input at its native rate rather than consume a local file as quickly as possible. FFmpeg’s complete documentation includes real-time-paced input in HLS examples. That establishes it as a building block, not proof that every playlist, segment format or codec combination will work. A local playlist and a remote, segmented playlist have different failure points, so test the exact path you plan to leave running.
Verify muxer and protocol compatibility
A stream can be readable and still be unsuitable for the chosen output. The container or muxer must accept the codecs and stream layout you are trying to copy. The output protocol must also work with the selected muxer and the destination’s ingest method. Stream copy does not convert a codec, repair damaged media or make an unsupported combination acceptable.
Start with the simplest output that matches your intended workflow. Map only the tracks you need, then request copying for those tracks. If FFmpeg reports that a codec cannot be used with the output format, or that a stream cannot be written in the chosen muxer, stop and investigate that incompatibility. Removing an unnecessary subtitle or data stream may help if it was included inadvertently; changing to a compatible output arrangement may also be possible. Neither adjustment should be assumed until you test it with the real inputs.
The format flag in an FFmpeg command matters because it selects a muxer; it is not a cosmetic label. Likewise, a stream key is a credential for the destination rather than a media-conversion setting. Keep it private and avoid publishing it in shell history, screenshots or logs you share. For a broader look at file preparation before starting a prerecorded broadcast, see how to start a 24/7 prerecorded YouTube live channel in India.
A pass-through setup can be a good fit where the original encoding is already suitable for the output and you do not need to change the picture or sound. If it is not, a successful input probe alone is not enough: verify the entire path from source through muxer to ingest. Current ingest expectations can change, so check the official destination guidance for the account and workflow you are using instead of treating an old command copied from a forum as definitive.
Confirm the input remains continuously readable
An always-on relay is only as continuous as its source. A local file may be stable, but a sequence can reach its end, pause between entries or fail when the next path is missing. A remote source may expire, require credentials, change its playlist manifest or become unreachable. None of those problems is solved by having a lightly loaded CPU.
Test a full transition between items rather than only starting the first file. Watch the FFmpeg output for read errors, timestamp warnings, reconnect loops and unexpected exits. Check whether the output actually continues through the transition, not merely whether the process remains visible. If you are looping a single file, confirm that the loop boundary produces the intended result and that FFmpeg does not stop when it reaches the end.
For a remote input, consider what happens if a segment is slow or unavailable. A reader can wait, retry, skip or terminate depending on the source and the command; do not assume it will recover in the way your channel needs. A local playlist avoids some remote-access risks but introduces file-management concerns: paths must remain valid, storage must be available, and updates should not leave the list pointing to a missing or half-written file.
Keep the source workflow distinct from the YouTube destination. If you are trying to ingest an existing online YouTube playlist, do not presume that the video page or playlist address is a supported, stable FFmpeg input. Availability and rights are separate questions from codec compatibility. The article on streaming podcast episodes on YouTube without copyright problems covers a different but related planning issue: being able to play media technically does not establish that you have the rights to broadcast it.
Check outgoing bitrate against VPS capacity
A low CPU reading does not mean the host can send the stream. In a pass-through relay, the output bitrate is largely inherited from the encoded input, with some additional network and protocol overhead. If several sources or tracks are combined, the traffic profile may differ. Compare the observed outgoing rate with the VPS provider’s sustained egress capacity and any transfer allowance or fair-use terms.
Do not use a generic “one vCPU supports this bitrate” rule. No universal benchmark establishes a safe resolution or bitrate for every one-vCPU VPS. Providers differ in CPU allocation policy, network contention, region and traffic limits; even the same provider can offer different conditions across plans. A short speed test is not a guarantee that the connection will sustain the stream overnight.
Measure your own job over a representative period and inspect both the sending rate and errors. If the source bitrate varies, include the higher-rate portions. Allow headroom for protocol overhead and ordinary variation rather than planning exactly at the advertised ceiling. If the stream goes out through a shared or throttled connection, confirm what the provider means by its bandwidth description and whether transfer caps apply. These are capacity checks, not claims about a particular plan.
The FFmpeg protocol documentation describes protocol-specific controls, including bandwidth-related settings for SRT, but that is not a statement of YouTube ingest requirements. Use the current official instructions for your actual destination to confirm its accepted workflow, then compare the measured egress demand with your provider’s terms. If the capacity is uncertain, test the same source and command from the target host before depending on it for a 24/7 channel.
Recognise when filters or mixing require transcoding
Stream copy cannot change the picture or sound. If you need to resize video, deinterlace it, burn in graphics, apply a visual filter or alter frames, FFmpeg has to decode the relevant media and produce a new encoded stream. Similarly, mixing audio tracks or resampling audio requires processing rather than a simple copy. A codec that the output cannot accept may also require conversion if no compatible source or output arrangement is available.
This is where a one-vCPU assumption becomes especially risky. The host must encode at a pace that keeps up with live playback; if it falls behind, delay can grow or delivery can break. Google’s VP9 live-encoding guidance states that a live encoder needs to sustain at least real-time speed. That is a general requirement for a live encoding workflow, not a benchmark for a particular VPS, codec, resolution or bitrate.
If a filter is optional, decide whether you can prepare the media before the live relay. Pre-encoding files elsewhere can keep the VPS workload closer to copying, provided all prepared files have compatible streams and transitions. If the channel needs live overlays, changing layouts or a mix that varies during broadcast, you need to test the encode workload on the actual host. A low-resolution test clip may not represent the demand of the real content.
Also distinguish a deliberate conversion from an accidental default. FFmpeg transcodes selected streams unless stream copy is requested; adding a filter can make copying impossible for that stream. Do not leave -c copy in a command and assume it has converted anything. Inspect FFmpeg’s output and confirm which streams are copied and which are encoded. If you cannot meet the live pace on the VPS, reduce processing, prepare media in advance or choose a host with more suitable CPU capacity.
Test the relay on the target VPS
A useful test is not just “the command started”. Use the same VPS plan, source type, FFmpeg build, output format and destination path that the live channel will use. Keep the test long enough to include playlist transitions and ordinary source variation. A local short file proves little about a remote playlist that refreshes, or a loop whose boundary fails after the first pass.
Record a simple baseline before the test: CPU use, memory pressure, network send rate, FFmpeg status and any provider traffic counters available to you. Then observe them while the stream runs. The goal is to identify a bottleneck, not to reach a magic CPU figure. If CPU stays modest but the output stalls, investigate the source and network. If the stream remains readable but errors appear at each file transition, inspect the playlist and stream mappings. If CPU rises sharply, check whether the command is encoding or filtering when you expected copying.
Review logs for repeated reconnects, dropped packets, timestamp issues and process exits. Avoid storing a visible stream key in shared logs. Confirm recovery behaviour deliberately: a process that exits once and stays down is different from one that restarts but never regains a readable source. A restart mechanism can help after a transient failure, but repeated restarts are not a substitute for diagnosing the underlying incompatibility or unavailable input.
Run the test at a time when you can inspect it, then check what happens after you stop watching. For a service that needs no local computer left on and where restarting a dropped broadcast is the specific operational burden, StreamNeo removes that machine-side task by taking an uploaded video and running it as a YouTube live stream. That does not change the need to confirm your media, account and rights are appropriate for your channel.
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
Can a 1 vCPU VPS run FFmpeg with -c copy?
It may, when the source streams are compatible with the output and the VPS can continuously read and send them. Stream copy avoids video re-encoding, but it does not establish a universal CPU, bitrate or reliability limit. Test the exact source and command on the host you intend to use.
Does -c copy make any playlist compatible with YouTube?
No. It requests copying of encoded streams; it does not convert unsupported codecs or make a muxer accept a stream layout. Verify the input, mappings, output format and current destination guidance together.
What if I need a logo or resized video?
Those changes require processing the video and ordinarily mean decoding and re-encoding that stream. Measure the workload on the target VPS and confirm it can sustain live pace; the result depends on the actual codec, settings and host, not the vCPU label alone.
Is an online YouTube playlist a reliable FFmpeg input?
Do not assume so from the playlist URL alone. Input access, segmentation, availability and permissions are separate from the relay’s output compatibility; verify the exact source method and use media you are entitled to broadcast.