A 4K playlist can be streamed to YouTube from a VPS with FFmpeg, but the first question is whether your files and host can sustain the chosen output profile. Inspect the media, test real-time encoding and upload capacity, then build the loop and send it to YouTube using the current settings for your codec and frame rate.
For SDR H.264, YouTube's published recommendations are 30 Mbps at 2160p30 and 35 Mbps at 2160p60. Those are platform recommendations, not a promise that a particular VPS, connection or source file will work reliably at that rate.
Decide whether 4K is viable on your VPS
A VPS needs enough sustained compute to prepare the video and enough upload capacity to carry the outgoing stream. If you use streamcopy with already-compatible files, FFmpeg can avoid video re-encoding; if you need to resize, change frame rate, or convert codecs, encoding adds continuing CPU work. Neither the “4K” label on a host plan nor a brief successful test proves the workload will hold up through a long broadcast.
Begin by identifying the intended output: 3840 × 2160, a specific frame rate, SDR or HDR, and a codec accepted by the chosen YouTube ingest mode. This article focuses on SDR H.264 over RTMPS, a conventional FFmpeg push workflow. YouTube lists other codec options, but their settings differ; do not borrow a bitrate from another codec's table and apply it to H.264.
Check the VPS while it is doing the actual work, not only when it is idle. For a re-encoded stream, watch CPU use and dropped or late frames over a representative section. For streamcopy, watch network throughput and FFmpeg's progress instead. Also check the host's available outbound bandwidth: the video rate is not the whole connection requirement, and a shared or variable connection may not behave like a short speed test.
If the host cannot keep pace, you have three practical choices: pre-encode compatible files to reduce live work, select a lower output profile, or use a host with more suitable sustained capacity. A lower-resolution stream that stays stable is more useful than a 4K setting that repeatedly falls behind. The VPS selection trade-offs for continuous YouTube streaming are worth reviewing before you pay for a host; there is no universal VPS size that can be recommended for every source and encoder.
Inspect and prepare the files
A concat playlist is easiest to use when each item has matching stream properties. Inspect every file for its video and audio streams, resolution, frame rate, codec, pixel format, and audio layout. ffprobe can report these properties; record them in a small inventory so you can see where clips differ before starting a long run.
If files already have a compatible codec, dimensions, frame rate, and audio structure, streamcopy may be appropriate. It avoids re-encoding and its CPU cost, but it cannot correct a mismatched resolution, add a missing audio stream, or apply a filter. When clips vary, normalise them before the live run or use a filter-and-encode workflow that produces a consistent output. That extra preparation takes time and compute, but makes the output profile explicit rather than leaving FFmpeg to pass incompatible changes downstream.
Do not assume that files with the same extension are equivalent. A 4K clip at one frame rate followed by a 4K clip at another can cause timing or transition problems, and audio layouts can differ too. Make a short test containing a transition between representative files. Listen across the join and inspect the image and timing before assembling the full schedule.
Keep the source files and playlist in paths that the FFmpeg process can read after you disconnect from the VPS. If the playlist uses paths outside concat's safe defaults, FFmpeg's -safe 0 can permit them; use that only with a playlist you control. It removes a path restriction, not the need to trust the contents of the file.
For a channel with many clips, file organisation matters as much as the command. A predictable naming and ordering scheme makes it easier to spot omissions and update the programme without accidentally changing the wrong item. The guide to organising video files for a 24/7 VPS stream covers that housekeeping in more detail.
Build a concat playlist and choose the loop
FFmpeg's concat demuxer reads a text playlist with one file entry per media item. A simple playlist might look like this:
file '/media/show/part-01.mp4'
file '/media/show/part-02.mp4'
file '/media/show/part-03.mp4'
Use the syntax documented for the FFmpeg build installed on the VPS, and verify that each path resolves from the process's working environment. Paths containing unusual characters deserve particular attention. Keep playlist files and media under an account and directory that other users cannot casually alter, especially if the stream runs unattended.
The concat demuxer is for compatible inputs, not a general-purpose repair tool. If you have incompatible files, use a preparation pass to produce matching outputs or create a filter-based concatenation workflow and re-encode as needed. Streamcopy (-c copy) can save processing capacity, but it cannot filter or convert the inputs to match a target. The FFmpeg concat documentation explains the demuxer and its input requirements; check it against the version you have installed.
To repeat a playlist indefinitely, FFmpeg provides -stream_loop -1 for an input. To read media at its native pace for real-time output, use -re. These are input options, so put them before the corresponding -i; FFmpeg options are position-sensitive. If the broadcast is meant to end after one run, omit the infinite loop rather than relying on a process timeout to stop it.
A representative input shape is:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \
... output and encoder options ...
This is a workflow illustration, not a complete tested command. In particular, -safe 0 is only suitable for a playlist you control, and the output settings must match your media, encoder and chosen YouTube profile. Test the loop locally or with a private test stream before making it the channel's ongoing programme.
Set up YouTube Live ingest and protect the key
In YouTube Live Control Room, create or select the broadcast and obtain the ingest URL and stream key shown for it. YouTube accepts RTMP and RTMPS ingest and recommends RTMPS. Use the endpoint and protocol that the control room provides for the selected workflow, then check that the encoder's output container and codecs are accepted. YouTube's live encoder settings and ingest guidance is the primary reference for current requirements.
Treat the stream key like a password. Do not paste the real value into a public script, shared terminal session, tutorial, support screenshot or log that other people can read. A command entered directly into a shell can also be exposed through shell history or process inspection, depending on the environment. Prefer a restricted configuration or environment mechanism available on your host, limit access to it, and avoid printing it during troubleshooting. If you think it has been exposed, replace it in Live Control Room and update the running configuration.
Keep a placeholder in notes and examples rather than the live credential. For instance, the command can refer to an environment variable or a protected configuration value, while the actual key remains outside the text you share. Check your chosen mechanism carefully: environment variables are not automatically secret from every account or process on a machine. The goal is to avoid accidental disclosure and restrict access, not to imply that one storage method is secure in all VPS setups.
The normal FFmpeg push path for this workflow is RTMPS. YouTube also documents HLS ingest for particular workflows, but HLS has its own segment and playlist requirements and may involve different latency and encoder support. Do not switch to HLS simply because it appears in a menu; use it only when your workflow requires it and you can meet the documented format requirements.
If you are still deciding where a stream should go, first settle the destination rather than building around an assumed protocol. The guide to choosing streaming destinations can help frame that decision; for this article's YouTube workflow, use the current YouTube ingest instructions and the URL shown for your stream.
Choose frame rate and bitrate from YouTube's guidance
For SDR H.264, use the row that matches the intended output frame rate. YouTube's current live encoder guidance lists these recommended values:
| Output mode | H.264 live bitrate recommendation | Keyframe guidance |
|---|---|---|
| 2160p30 | 30 Mbps | Two-second interval recommended; do not exceed four seconds |
| 2160p60 | 35 Mbps | Two-second interval recommended; do not exceed four seconds |
These are YouTube's recommendations for the stated H.264 modes, not guarantees for an arbitrary source or VPS. The same guidance recommends constant bitrate (CBR). At 30 fps, a two-second keyframe interval corresponds to 60 frames; at 60 fps it corresponds to 120 frames. Configure and verify the encoder's actual behaviour rather than assuming a GOP option has exactly the intended effect in every build.
A representative 2160p30 H.264 profile might set a 30 Mbps target, CBR-style rate controls, 30 fps output, and a two-second GOP. In FFmpeg, options such as -b:v, -maxrate, -bufsize, -r, and -g are part of how an encoder configuration is expressed, but their exact meaning and interaction depend on the selected encoder. Test the incoming stream's reported rate and frame rate in YouTube Studio. A command template should not be copied without checking the encoder documentation and source media.
For 2160p60 H.264, use the matching 35 Mbps recommendation and 60 fps output only if the source and host can sustain it. Upsampling a 30 fps source to 60 fps does not create additional motion detail, and encoding more frames increases workload. If the source is genuinely 30 fps, keeping the output at 30 fps is usually the more direct path unless another production requirement calls for conversion.
The settings table for HEVC and AV1 is separate from H.264. YouTube lists ranges for those codecs, but they are not interchangeable with the H.264 recommendations above. Use another codec only after confirming that your installed FFmpeg encoder supports it and that YouTube accepts that configuration for your ingest route. YouTube's codec-specific settings should be checked before changing the profile.
For audio, YouTube's RTMP/RTMPS guidance lists AAC or MP3. AAC is a conventional choice for a mixed video playlist, but check that every source has usable audio and that the output remains continuous at clip joins. A stream with a stable video rate can still be a poor broadcast if it drops audio at transitions. For practical transition checks, see how to remove audio gaps when looping videos.
Monitor compute, upload and stream health
A successful start only confirms that the stream began. Watch the VPS and YouTube's stream-health information during a representative test: CPU use, output frame rate, encoder progress, upload throughput, incoming bitrate, audio continuity, and any dropped-frame or connection warnings. Keep the monitoring view open long enough to see the playlist change files, since a stream can appear healthy on a static opening frame and fail at a later transition.
For an encode that falls behind, check whether the CPU is saturated and whether the chosen preset is too demanding for the host. You can pre-encode files, use a less costly encoder setting after testing quality, or reduce the output target. For streamcopy, investigate compatibility and the network path rather than expecting a preset change to help. Avoid raising the bitrate to solve a problem that is actually a file transition or ingest configuration issue.
For upload trouble, compare actual sustained outgoing throughput with the stream's target and observe variation over time. Leave headroom for normal connection fluctuation and other traffic on the VPS; a momentary speed-test result is not a substitute for monitoring the live push. YouTube advises choosing a quality that is reliable on the available connection and testing with representative movement and audio. Its live streaming troubleshooting guidance is useful when Studio reports a specific ingest issue.
Record the profile and test observations: file set, FFmpeg version, encoder, frame rate, target rate, and when any warning appeared. Do not include the stream key in those notes. This gives you a way to distinguish a repeatable file problem from a host or connection limitation after a restart. Continuous operation still needs a plan for process exits, host maintenance and credential updates; a running FFmpeg process is not, by itself, a complete operations plan.
Test playback, transitions and archive expectations
Before making the stream public, use a private or unlisted test and inspect it from the viewer side. Confirm that YouTube receives the expected resolution, frame rate and approximate bitrate, then watch and listen through transitions between different files. Check for black frames, frozen pictures, missing audio, audio-level changes, or a visible discontinuity in timing. YouTube specifically recommends testing before going live, including with representative audio and movement.
Do not assume that an input file's resolution guarantees the same viewer experience. The outgoing encoder profile and YouTube's processing determine what reaches playback, and viewers may see different playback quality options. Verify the actual incoming signal in Live Control Room and test playback on a separate device or connection if the channel's audience uses one that differs from your VPS environment.
Treat archive and replay behaviour as a separate setting to verify in YouTube Studio. Do not infer that every stream length, configuration or account will produce the archive you want. Check the current YouTube guidance and the controls shown for the specific broadcast, then confirm the replay is available and usable after the test ends if keeping a replay matters to you. Save source files separately; a platform replay should not be your only copy of the programme.
If a loop has a long duration, also decide whether repetition is acceptable to viewers and whether the programme should run continuously or stop at a planned point. For devotional music, study ambience or a local information loop, predictable ordering can matter as much as resolution. If your source contains music, visuals or other material you did not create, review the relevant rights and YouTube policies yourself; a technical test does not determine whether a broadcast may remain available.
When managing FFmpeg on a VPS becomes the fragile part of the plan—particularly keeping a local machine on and recovering a stopped broadcast—StreamNeo can take an uploaded video and run it as a YouTube live stream while your computer is off. It is YouTube-only, so it does not replace a VPS workflow if you need custom FFmpeg processing or another destination.
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 I loop a video playlist indefinitely with FFmpeg?
Yes. FFmpeg's -stream_loop -1 sets an input to repeat indefinitely, and -re reads at real-time pace. Put input options before the relevant -i, and test the playlist joins before using it for a long broadcast.
What bitrate should I use for a 4K YouTube Live stream?
For SDR H.264, YouTube's current recommendation is 30 Mbps at 2160p30 and 35 Mbps at 2160p60. Those figures describe platform guidance for those modes, not a rate that every source or VPS can sustain; test the actual encode and upload path.
Can streamcopy handle a playlist with mixed resolutions or frame rates?
Streamcopy avoids re-encoding but cannot resize, change frame rate or filter incompatible media. Normalise the files first or use a filter-and-encode approach, then test transitions and account for the extra compute.
How do I keep my YouTube stream key private?
Do not publish it in a script, screenshot, shared shell history or log. Use a restricted configuration method appropriate to your VPS, limit access, and replace the key in Live Control Room if it may have been exposed.