Use FFmpeg's concat demuxer to read a text playlist, then place -stream_loop -1 before that input to repeat the playlist indefinitely. Send the resulting stream to YouTube's ingest address with the stream key from Live Control Room, preferably over RTMPS where your FFmpeg build supports it.
This procedure is not a turnkey guarantee. The example command below is illustrative and untested, and your files must be compatible or deliberately re-encoded. Preview the broadcast, watch YouTube's stream health messages, and measure the VPS under the actual workload before leaving it unattended.
What this setup does
A VPS gives FFmpeg a machine that can remain on while your own computer is switched off. FFmpeg reads the files in sequence, produces a live-paced output, and sends that output to YouTube. The VPS provider's bandwidth, CPU allocation, storage and operating limits still matter, so moving the command to a VPS does not remove the need for testing.
The concat demuxer is the part that turns several files into one sequential input. The -stream_loop -1 input option then repeats that input without a planned end. These are separate jobs: concat controls the order of the files, while -stream_loop controls repetition.
A typical workflow is:
- Inspect the media and confirm that you have the rights to broadcast it.
- Create a playlist text file in concat format.
- Create or select a YouTube live stream and protect its key.
- Test the command with representative files.
- Preview the result in Live Control Room.
- Add practical monitoring and a recovery plan before treating the process as operational.
If your aim is a devotional, bhajan, study or ambience channel, the same structure applies. The details that change are the audio and video properties, the desired quality, and how much interruption your viewers will tolerate. For broader planning, the guide to starting a 24/7 Indian music live stream with FFmpeg covers related choices around a long-running broadcast.
Prepare compatible playlist files
Start with the files, not the command. Each item should contain the audio and video streams you expect viewers to receive. Check the resolution, frame rate, pixel format, audio sample rate, channel layout, codecs and timing information with a media inspection tool such as ffprobe.
The concat demuxer sequences packets from one file and then the next. It does not make unrelated files uniform. A playlist made from a 1920×1080 H.264 video with AAC stereo audio may not transition cleanly to a different frame rate, a different time base, missing audio, or an incompatible codec when you use stream copy. Incorrect duration information can also produce timing problems or visible or audible artefacts.
For a reliable first test, use a small set of representative clips rather than the files that happen to be easiest to find. Include the longest clip, the shortest clip, a clip with quiet audio, a clip with normal motion, and any file whose format differs from the others. Watch the transition between every item. A playlist that appears fine in a desktop player may still expose timestamp or stream-structure problems when it is joined by a demuxer and sent as a live feed.
Only use material that you are permitted to broadcast. The technical command does not grant rights to music, devotional recordings, footage, photographs or other content, and it does not determine whether a particular channel qualifies for monetisation or remains within YouTube policy. Check the current official rules for your content and account.
You should also decide whether the files need to be joined exactly as supplied or normalised into a common format first. Stream copy is attractive when the sources already match because it avoids an encoding stage. It is not a general solution for mixed media.
Write the concat demuxer list
Create a plain text file, for example playlist.txt, with one file directive per source. A basic list looks like this:
file '/srv/media/clip-one.mp4'
file '/srv/media/clip-two.mp4'
file '/srv/media/clip-three.mp4'
The paths in this example are illustrative. Use absolute paths while you are testing so that a later change of working directory does not make the playlist fail. Quote paths that contain spaces or special characters according to the concat demuxer's syntax, and keep the list under your control.
The example command later uses -safe 0, which permits paths that the concat demuxer may otherwise reject as unsafe. That option should not be treated as a universal fix. Understand the list, restrict its ownership and permissions, and do not accept arbitrary file names from an untrusted source merely to make a command run.
You can add files by editing the list, but validate every new item before putting it into an unattended process. A single file with a different stream layout can cause the sequence to fail or create a poor transition. If your list is generated by a script, inspect the generated text and make sure a file name cannot escape the intended media directory.
A useful local check is to run the playlist once without publishing it. Output to a local file or a null destination while watching for errors, timestamp warnings and unexpected stream selections. This will not reproduce every network or YouTube condition, but it separates basic playlist problems from ingest problems.
The guide to bitrate settings for a pre-recorded YouTube Live video is useful at this point because the output profile should be chosen after you understand the source media and the available upload capacity, not before.
Obtain the YouTube ingest URL and key
In YouTube Studio, open Live Control Room and create or select the live stream. YouTube provides the server or ingest URL and a stream key. Choose the title, description, visibility and other settings there, then copy the values into your secure operating notes rather than placing the key in a public article, repository or shared screenshot.
YouTube describes stream keys as similar to a password and address for the stream. Treat the key as a credential. Do not publish it in a shell history that other users can read, paste it into a support forum, or write it into a script with broad permissions. If you believe it has been exposed, reset it in Live Control Room and update the process.
Use the exact ingest URL shown for the stream. YouTube recommends RTMPS for encrypted ingest; its instructions are in YouTube's RTMPS guidance. If the displayed address begins with rtmps://, preserve that scheme. Confirm that your FFmpeg build supports the protocol and that the VPS can make the outbound connection.
You can keep the key outside the command itself. For example, a protected environment file or a service manager's secret handling may be preferable to a script readable by every account on the VPS. The precise method depends on how you administer the machine, but the principle is the same: anyone who can read the key may be able to publish to the channel.
Before starting a public broadcast, check whether the stream is set to private or unlisted for your test. This lets you inspect the preview and transitions without immediately directing viewers to a process that you have not yet observed. Change visibility only after you are satisfied with the basic behaviour.
Loop the playlist and pace input in FFmpeg
The following is an illustrative command shape, not a tested command or a claim that these settings fit your files, VPS or account:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \
-c:v libx264 -preset veryfast -b:v 4000k -maxrate 4000k -bufsize 8000k \
-pix_fmt yuv420p -g 60 -c:a aac -b:a 128k \
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
Replace the playlist path, encoding options, ingest address and key with values appropriate to your media and account. The command deliberately shows re-encoding because it is a broadly adaptable illustration when the source files are not already suitable for a common live output. It is not a recommendation to use these exact bitrate, keyframe or preset values without testing.
The placement of -stream_loop -1 matters. It is an input option and belongs before the -i it applies to. In this example, the input is the concat list, so FFmpeg reads the list and repeats that input indefinitely. If you place the option after the input, it may not affect the intended source.
The -re option asks FFmpeg to read the input at its native rate rather than sending a file as quickly as the VPS can process it. That pacing is important when a file-based source is being used to simulate a live feed. It does not repair bad timestamps, incompatible streams or a weak network path.
The output format is flv, which is used for this style of YouTube ingest. The video and audio codec settings in the example create a conventional H.264 and AAC output, but YouTube's current encoder guidance varies with codec, resolution and frame rate. Consult YouTube's encoder settings documentation before settling on a profile.
Watch the terminal while testing. Look for repeated connection failures, encoder errors, timestamp warnings, audio underflow messages and growing delay. A process that remains running is not necessarily delivering a healthy broadcast.
Choose stream copy or normalise the media
There are two main approaches.
| Approach | What FFmpeg does | Main advantage | Main risk or cost |
|---|---|---|---|
| Stream copy | Passes compatible audio and video packets through without encoding them again | Lower CPU demand and no additional generation loss | Sensitive to mismatched codecs, time bases, timestamps, resolutions and stream layouts |
| Re-encode | Decodes the sources and creates a consistent output profile | Can normalise mixed sources into one live format | Uses more CPU or GPU resources and requires suitable bitrate, frame rate and keyframe choices |
Stream copy is appropriate only after you have established that the files are compatible with the concat demuxer and with YouTube's accepted ingest format. A command using -c copy may be efficient for a carefully prepared library, but it does not make an MP4 with one stream layout compatible with a different file. It also does not automatically solve duration or timestamp inaccuracies.
If the files differ, create a deliberate normalisation step. That may mean decoding each source and writing standardised intermediate files, or re-encoding as part of the live FFmpeg process. The first approach can make the live process lighter and easier to diagnose, at the cost of storage and preparation time. The second avoids a separate media library but puts the encoding load on the VPS during the broadcast.
Choose the output resolution and frame rate from the quality you actually need and the sustained upload capacity you can measure. A higher-quality profile increases the data that must be encoded and sent. The VPS may have enough CPU for one low-motion ambience stream but not for a demanding source at a higher frame rate. Do not infer suitability from the provider's advertised plan name; measure the selected workload and review its bandwidth and egress terms.
Keyframes also need attention. YouTube publishes guidance around constant-bitrate encoding and keyframe intervals, with recommendations that vary by the selected output. The -g 60 in the illustration is not universal. Its suitability depends on the frame rate and the current YouTube guidance for your profile.
After normalising, inspect the generated files again and run the concat list locally. Confirm that every item has the expected video and audio streams, that the aspect ratio is correct, and that the hand-off does not introduce silence, a frozen frame or a sudden size change.
Preview and monitor stream health
Start with a private or unlisted test and open the preview in Live Control Room. YouTube recommends testing before starting the live stream; its streaming tips also cover previewing and monitoring. Check the preview rather than assuming that a successful FFmpeg connection means viewers are receiving the intended result.
Let the test cross at least one playlist boundary. Check that the next file starts, that audio remains present, and that the picture does not change unexpectedly in size or shape. Listen for a clipped ending, a long silence or a mismatch between the visible clip and its audio. Repeat the test after replacing a file or changing the output settings.
In Live Control Room, read the stream health messages and watch for connection trouble, dropped frames, encoding warnings and insufficient upload capacity. On the VPS, observe CPU use, memory pressure, disk space, network throughput and the FFmpeg log. The exact commands for those checks vary by operating system and provider, but the checks themselves should be part of your routine rather than something you do only after viewers report a failure.
A simple operating record helps. Note the time the process started, the input list used, the output profile, the last successful playlist transition and any warnings. Keep logs rotated so they do not fill the VPS disk, and avoid logging the stream key. If you use a service manager, configure restart behaviour carefully and make sure an automatic restart cannot create multiple publishing processes at once.
A restart policy is not the same as uninterrupted operation. The process may stop because of a malformed file, a VPS resource limit, a network interruption, a protocol problem or a YouTube-side condition. Decide who or what notices the failure, how the key is supplied after a restart, and whether viewers should see a new session or a temporary interruption.
YouTube's encoder setup documentation says that streams under 12 hours are automatically archived. That is an archive condition, not a promise that an arbitrarily long broadcast will be fully archived or that every session will complete successfully. If a long-running channel needs usable recordings, plan sessions and retention around the current Live Control Room behaviour.
Decide whether a VPS is the right operating model
A VPS is useful when you want your home computer switched off and you are comfortable administering a remote Linux machine. It gives you control over FFmpeg, the playlist and the monitoring process. It also leaves you responsible for updates, credentials, logs, firewall settings, resource checks and recovery.
Transcoding is the main difference between a light and a demanding setup. Stream copy can use fewer encoding resources when all media is already compatible. Re-encoding may be the correct technical choice for a mixed library, but it can require substantially more CPU or an available hardware encoder. The research for this procedure does not establish a universal VPS size, provider or bandwidth requirement, so choose based on measurement rather than a generic plan label.
A hosted workflow that removes VPS administration may be more suitable if your priority is uploading a file once and not maintaining a remote process. StreamNeo removes the need to keep your own computer or VPS process running for this particular YouTube-only workflow: upload the video, provide the stream key, and the broadcast can be monitored and restarted automatically if it drops. You still need suitable content, a valid account setup and a health check before relying on the channel.
Whichever model you choose, retain a local copy of the playlist and source files, keep a record of the output settings, and know how to revoke the stream key. Do not make the first unattended run the first time you have observed the actual files and transitions.
Before you leave the stream unattended
Use this final check:
- The playlist contains only intended, accessible paths.
- Every file has the expected audio and video streams.
- The files are compatible for stream copy, or you have chosen and tested normalisation.
- The ingest URL uses the scheme shown by YouTube, with RTMPS where supported.
- The stream key is protected and can be reset if exposed.
- The output has been paced with
-reand tested through a playlist transition. - The preview shows the correct picture, aspect ratio and audio.
- You have checked YouTube's stream health messages.
- The VPS has enough sustained CPU, memory, storage and upload capacity for the selected workload.
- Logs and alerts will not expose the key or fill the disk.
- You know what happens if FFmpeg exits or the network connection fails.
- You have checked the current YouTube rules for the content and the account.
For a channel watched on variable connections, also test from the audience side. The guide on checking a YouTube 24/7 stream on Indian mobile data can help you think about playback behaviour beyond the VPS itself. If delay matters for your use case, review how to reduce delay on a YouTube Live stream before changing settings blindly.
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
How do I loop a playlist with FFmpeg?
Put the files in a concat demuxer list, pass that list with -f concat, and place -stream_loop -1 before the matching -i. Use -re to pace file input as a live source, then send a tested output to YouTube's ingest URL.
Can I use stream copy for any playlist?
No. Stream copy depends on compatible codecs, stream layouts, timestamps, time bases and other media properties. If the sources differ, normalise or re-encode them rather than assuming -c copy will make the transitions work.
Should I use RTMP or RTMPS?
Use the ingest scheme shown in Live Control Room and prefer RTMPS where your FFmpeg build supports it, because YouTube recommends encrypted ingest. Test the connection and keep the stream key private.
Can a VPS guarantee a continuous YouTube stream?
No. A VPS process can stop because of media errors, resource pressure, network problems or service conditions. Preview the stream, monitor health, measure the workload and maintain a recovery plan rather than treating the command as a guarantee.