To loop multiple prerecorded videos in a YouTube livestream from a VPS, first make an ordered playlist or concat input, then use FFmpeg to read that sequence at real-time speed and send one encoded output to YouTube. -stream_loop -1 repeats an input, but it does not decide how separate files are sequenced; matching formats and testing the joins are part of the job.
The VPS must keep the encoder running and sustain its workload and upload. The steps below cover playlist preparation, FFmpeg option placement, YouTube ingestion, and checks to make before you leave the stream unattended. No one command handles every combination of video and audio files.
Plan the playlist and file order
Write down the order before you touch the encoder. For a devotional channel, that might be an opening slate, a set of bhajans, a short identification card, and then the same programme again. A study stream might put several ambience tracks in a deliberate sequence. The order is a programming choice, not an FFmpeg default: the process will follow the list you give it.
Decide whether the playlist should repeat from the beginning, run once, or end on a particular file. If it should repeat, make that behaviour explicit in the sequencing workflow and test the wrap from the last item to the first. Do not assume that looping each input separately creates a clean programme sequence. It can instead repeat one file or create an order different from the one you intended.
Keep an inventory with filenames, duration, video and audio stream details, and any intended transition. Use filenames that sort predictably, such as 01-opening.mp4 and 02-programme.mp4, or build a playlist whose order is written out explicitly. Avoid relying on directory listing order or on names that are easy to confuse when you later replace a file.
There are two broad approaches. A concat demuxer can read a list of files as one input when the files are sufficiently compatible. A playlist-capable input or a more involved filter graph can be useful where you need transformations or different handling of items. Each has constraints, and the correct choice depends on the actual media. The guide to streaming a playlist on YouTube Live provides another way to think about playlist behaviour, while this VPS workflow focuses on producing one encoder feed.
Prepare the VPS media files
Upload the source files to a stable directory and check that each is complete. A partial upload may still have a familiar filename and may even play for a while before failing. Compare file sizes, inspect the streams with a media probe such as ffprobe, and play the beginning and end of every file. Keep a separate copy of the source material somewhere recoverable; the VPS working directory should not be the only copy.
Inspect the properties that affect joining: container, video and audio codecs, dimensions, frame rate, sample rate, channel layout, and timestamps. Two files both ending in .mp4 can still contain different codecs, frame rates, or audio layouts. Missing audio in one file, or different time bases and timestamp behaviour, can create silence, glitches, warnings, or a failed transition. The extension alone does not establish compatibility.
When inputs are already uniform and meet your output requirements, stream copy may avoid the work of decoding and re-encoding. But copying preserves the streams as they are; it does not repair mismatched media or make YouTube accept any arbitrary combination. Re-encoding gives you more control over a consistent output, but consumes VPS processing capacity. Check the current YouTube encoder settings against your intended resolution, frame rate, and codec before choosing.
For a varied collection, create standardised working copies before building the final sequence. For example, you could convert files to a common frame size, frame rate, video codec, audio codec, and sample rate, then test the converted files together. The exact conversion settings should suit the source and your planned output; do not apply a preset blindly to a collection that includes still images, variable-frame-rate footage, or files without audio. The MP4 file-size guide may help when storage or transfer is a constraint, but reducing size does not itself solve sequencing compatibility.
Build a sequence that can be repeated
For a simple compatible set of files, a concat list can describe their order. A typical list contains one file entry per path, with paths quoted and escaping handled according to FFmpeg's concat demuxer rules. Review the official FFmpeg documentation before using a list: path syntax and concat behaviour matter, and a list is not a universal media converter.
Conceptually, the process is: prepare the ordered list, make FFmpeg read it as one sequence, and then configure repetition of that sequence if required. In contrast, -stream_loop -1 attached to a single -i input repeats that input indefinitely. It does not interpret a folder as a playlist, and applying it to an input that is itself a concat list is a different arrangement that still needs validation with your build and files.
A filter graph is another way to join clips when you need to normalise or transform streams. It can be more flexible, but also requires explicit mapping, timestamp handling, and compatible filter inputs. A playlist application may be easier for some workflows, while a scripted FFmpeg sequence is often easier to reproduce on a headless VPS. For a comparison of approaches, see software for streaming prerecorded videos to YouTube Live.
Do not copy a generic command and assume its -map, codec, or output arguments fit your files. First inspect the streams, then decide whether to map video and audio from the sequence, omit audio intentionally, or provide a separate audio source. Verify the installed FFmpeg version supports the chosen demuxer and options. The research-backed option behaviour is narrow: -stream_loop -1 repeats an input; a sequencing method must first define what that input contains.
Pace files and place input options correctly
Files can be read faster than real time if the machine can decode them quickly. FFmpeg's -re reads an input at its native frame rate, which is useful where output packet timing matters, such as live streaming. It is an input option, so put it before the -i that it applies to. The same placement principle applies to -stream_loop: place input options before the corresponding input declaration, rather than after the output options and expecting them to affect an earlier input.
A conceptual single-file shape is ffmpeg -re -stream_loop -1 -i video.mp4 ... OUTPUT. This shows option scope, not a finished YouTube command. A multi-file setup changes what counts as the input: you might have an ordered concat input, or multiple individual inputs and a filter. Put the pacing and loop options where they apply in that arrangement, then check the actual command against the installed FFmpeg documentation. Do not combine fragments from unrelated examples without tracing which options apply to which -i.
-re is pacing, not a retry mechanism, a playlist manager, or a guarantee that the output will remain live. It cannot restore a dropped network connection or restart a crashed FFmpeg process. Nor does it prove that timestamps across file boundaries are suitable. If the sequence has irregular timestamps, test the output and consider normalising it rather than assuming real-time pacing will smooth the join.
Choose between stream copy and re-encoding after that inspection. Copying can be lighter on the VPS when the streams already align with the target output, but incompatible codec parameters, timestamps, or stream layouts may cause trouble at joins. Re-encoding can make output properties consistent, but the VPS needs to decode and encode in real time. Requirements vary with the media and output, so there is no universal CPU, memory, or bandwidth minimum to quote. If the VPS cannot keep up, reduce the workload or choose a suitable host rather than hoping a longer command will fix it.
Publish to YouTube Live
Check channel eligibility before scheduling work around the stream. YouTube's live-stream eligibility guidance describes account requirements and restrictions; its current page is the place to verify them. YouTube says first-time live access may take up to 24 hours to enable, so do not make the first activation attempt moments before an event.
In YouTube Studio, create or select the live stream in Live Control Room and retrieve the ingest server URL and stream key for that stream. Configure FFmpeg to publish to the intended endpoint using the current key. YouTube's encoder setup instructions explain the connection flow. If operating a scheduled stream, start the encoder, wait for the incoming preview and status, then use the Live Control Room control appropriate to go live.
Treat the stream key as a credential. Do not place it in a public repository, a screenshot, a shared command transcript, or a log that other people can read. Shell history can also retain commands, so use a private configuration method and restrict access to it. If the key is exposed, replace it in YouTube Studio and update the encoder configuration.
YouTube recommends RTMPS, which encrypts data to and through Google's servers. Use a supported endpoint and check the current YouTube settings for codec, bitrate, and keyframe guidance appropriate to your planned output. YouTube's encoder guidance recommends a constant bitrate and a two-second keyframe interval, and says not to exceed four seconds; these are settings guidance, not proof that a particular VPS or connection can sustain your chosen stream. Do not select a bitrate by habit: resolution, frame rate, codec, and network stability all matter.
Test transitions and stream health
Before scheduling a long run, make a short test sequence from the actual files. Include each kind of transition you expect, including the final-to-first wrap. Watch and listen across the boundaries rather than checking only isolated clips. Look for a frozen frame, a black gap, unexpected silence, doubled audio, abrupt loudness changes, or a delay that accumulates after each join.
Check the outgoing stream in YouTube's preview, not only the local FFmpeg log. Confirm that the image and audio arrive, that the stream is using the expected orientation and resolution, and that the Live Control Room reports a healthy incoming connection. A local process can be running while the ingest is stalled or the output is not what viewers receive.
Watch FFmpeg's stderr and exit status during the test. Save logs in a location with sensible retention and access controls, and make sure they do not expose the stream key. Warnings about non-monotonic timestamps or stream parameters deserve investigation at the transitions where they occur. A quiet log is useful evidence, but it does not replace viewing and hearing the result.
Test under the conditions you expect to use: the same VPS, playlist, output settings, and network route. If you plan multiple simultaneous channels, test that actual workload; one successful stream does not establish that a second will fit. Likewise, a brief preview does not show how the sequence behaves over a full loop. The article on an FFmpeg stream stopping on an Indian VPS covers a related failure mode, but your own logs and tests should drive diagnosis.
Run unattended and plan recovery
A VPS removes dependence on your home computer staying switched on, but it does not remove operational failure. The process can exit, the VPS can reboot, storage can fill, or the route to YouTube can fail. Plan who or what will notice a stopped feed, how you will inspect the cause, and how a restart will be checked in Live Control Room.
Use an operating-system process supervisor or service manager if you need the encoder to start after a reboot or restart after an exit. Configure logging and restart behaviour deliberately, and test a planned process stop and VPS reboot before relying on it. A restart policy cannot decide whether the playlist is valid, whether the stream key has changed, or whether YouTube has received the new feed. Monitoring and recovery are separate from FFmpeg's input pacing.
Keep enough free disk space for the media, temporary conversions, and logs. Ensure the media paths persist through reboots and that the service account can read them. Document the playlist location, the output settings, and how to rotate the stream key without putting the key itself in general operating notes. If you change a source file or update FFmpeg, rerun the transition test.
Budget for the VPS according to the actual workload: transcoding, output resolution, concurrent streams, storage, and data transfer all affect the choice. A small setup that stream-copies compatible material may have different needs from one that re-encodes several high-resolution inputs. The monthly cost estimate for a 24/7 YouTube stream can help you identify the cost categories, but no generic VPS size guarantees a stable stream.
Finally, check that you have rights to the videos, music, images, and other material in the playlist. A looping workflow does not establish those rights or guarantee approval, monetisation eligibility, or uninterrupted viewing. YouTube states that live streams must follow its Community Guidelines and Terms of Service; check the current official policies for your situation.
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 loop several videos in order?
No. It repeats an FFmpeg input; it does not define the order of several separate files. Build a playlist or concat input first, then configure and test repetition of that sequence.
Do all MP4 files work in one concat list?
No. The container extension does not tell you whether the codecs, dimensions, frame rates, audio streams, and timestamps align. Inspect the files and test the actual joins; some collections need conversion or a different sequencing method.
Does -re reconnect the stream if the network drops?
No. It paces file reading at the input's native frame rate. Process supervision, network recovery, and checking YouTube's incoming preview need their own plan.
Can I leave the stream running without checking it?
You can automate a process, but neither a VPS nor a looping playlist proves that the feed will remain healthy. Test the sequence, set up monitoring and recovery, and check the channel and content against YouTube's current requirements.