To make FFmpeg shuffle videos in a continuous YouTube stream, first put your files in a random order in a concat-demuxer list, then loop that list indefinitely. That repeats the same shuffled sequence; FFmpeg’s input-loop option does not create a new random order each time.
YouTube is the destination, not the playlist manager: you supply FFmpeg with the server URL and stream key shown in YouTube Studio. If you want a fresh shuffle after every cycle, you need an additional controller to build and switch to the next order.
Decide whether one shuffled cycle is enough
Start by deciding what viewers should hear and see after the final file in your collection. A single randomized cycle is often a good fit for a devotional channel with a substantial bhajan library, a study station with a fixed set of focus scenes, or a small business showing a rotating set of product films. The clips play in a varied order, then the same order begins again.
That is different from drawing a new order each time around. With one randomized list, the transition from the last item to the first repeats the same pair of files on every cycle. Across a long broadcast, a viewer who stays through several cycles may notice the repeated pattern. A new order each cycle reduces that predictable sequence, but it requires something outside the basic FFmpeg input loop to prepare and activate the next list.
The choice has an operational cost. One list is simpler to inspect, test and recover: if the process restarts, it can begin from that known order. A cycle-by-cycle shuffle requires a clear handover at the boundary, and the controller must deal with failures while preparing or opening the next sequence. If the channel needs to remain on air while you are asleep, simplicity may matter more than making every cycle feel different.
Write down a few practical requirements before building anything: whether a repeated sequence is acceptable, whether a brief transition at the cycle boundary is tolerable, and who can respond if the controller stops. Also consider the content itself. A news loop may need timely material and deliberate ordering, while an ambience station may benefit from variation without requiring strict editorial sequence. For broader playlist planning, see how to stream a Hindi bhajan playlist as a YouTube live loop.
Build a randomized concat-demuxer list
The concat demuxer reads an ordered text file that names the media files to process. It does not shuffle them by itself. To get one shuffled cycle, use a separate shell step or script to enumerate the files, randomize that enumeration, and write the resulting order to an ffconcat list before FFmpeg starts.
A typical list has this shape:
ffconcat version 1.0
file 'clips/early-morning.mp4'
file 'clips/temple-lamps.mp4'
file 'clips/rain-window.mp4'
The order of the file lines is the order FFmpeg reads them. The example is illustrative: use your actual filenames and a shuffle step that produces a different order when you intentionally build a new list. Keep the source folder organised and avoid adding temporary renders, partial downloads or the playlist itself to the set of files being enumerated. Otherwise, a subsequent list-generation run can include items you did not mean to broadcast.
Paths need care. Spaces and apostrophes can make a hand-written list fail unless they are quoted and escaped according to FFmpeg’s concat syntax. The FFmpeg documentation explains concat-file syntax and its safe-path behaviour. Safe mode is enabled by default; with -safe 0, the demuxer accepts paths that the default safety checks might reject. Use that setting only for paths you trust, not as a general fix for an unexplained error. Relative paths with ordinary characters are easier to move and audit.
Before using the list overnight, read through it and check that every entry points to a real file. Try a short test that uses only a few entries so you can confirm the actual order and catch path or decoding errors. When you later change the library, create and validate a new list deliberately rather than assuming an edit to the existing text file will alter a list FFmpeg has already opened.
A useful way to think about the output is as a snapshot: the randomized list defines one pass. Keep a copy of that list with the run notes if you need to reproduce a known sequence after a restart. If you want a new sequence, generate a new list and start or transition the process in a controlled way.
Loop the input indefinitely with FFmpeg
Once the list is ready, FFmpeg can repeat the concat input indefinitely. The key option is -stream_loop -1, which the FFmpeg documentation describes as looping the input indefinitely. It repeats what the input contains; it does not randomize the entries or reread them in a new order for each pass.
A conceptual command looks like this:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i shuffled.ffconcat \
-c:v libx264 -c:a aac -f flv "$YOUTUBE_RTMP_URL/$YOUTUBE_STREAM_KEY"
Treat this as a template, not a tested, universal command. In particular, the server URL and key are placeholders, and encoding choices must suit your files and the ingestion details YouTube Studio provides. The -re option reads input at its native rate, rather than sending a file as fast as the machine can process it. The concat demuxer is selected with -f concat; the input list follows -i. The output options encode video and audio and select a container and destination format.
Keep input and output concepts separate. -stream_loop -1 applies to the input list, so the same ordered sequence repeats. It does not ask YouTube to repeat an uploaded playlist, create a YouTube event, or manage the stream key. The FFmpeg article on running a 24/7 classroom stream with concat covers a related concat workflow; the distinction here is that randomisation happens before the list is read.
The exact command may need changes if your FFmpeg build lacks an encoder, if a source file has unusual streams, or if you choose another YouTube ingestion protocol. Check the build’s available encoders and run a short test before relying on the process. If FFmpeg exits, an input loop cannot restart the process itself. Your operating plan should include logs, a way to notice a stopped process and a deliberate restart procedure.
Connect output using YouTube Studio details
Create or select a live stream in YouTube Studio’s Live Control Room. YouTube’s encoder instructions tell creators to enter the YouTube Live server URL and stream key in their encoder, start the encoder, and check the stream preview or status. In this setup, FFmpeg is the encoder: copy the destination details from Studio into your command or a protected environment configuration, then start FFmpeg.
Do not publish the key in a script you share, a screenshot, a public repository or a support post. Anyone with access to it may be able to send content to your stream. If it is exposed, use YouTube Studio’s current controls to manage or replace it, then update the encoder configuration. Avoid putting a real key directly into examples or shell history where other people using the same account or machine can see it.
Start with an unlisted or otherwise appropriate test workflow if you need to inspect picture and sound before viewers see the broadcast. Watch the preview in Live Control Room: confirm that YouTube is receiving the feed, the audio is present, and the image is not frozen or cropped unexpectedly. FFmpeg reporting that it is sending packets does not, by itself, tell you that the intended stream is visible and healthy in the YouTube interface.
YouTube also distinguishes a live event from the media stream carrying it. The YouTube Live Streaming API guide describes a broadcast as a watchable event and a stream as the audio-video transmission associated with it. That matters if you automate scheduling or event creation: starting a local FFmpeg process and managing the YouTube broadcast are separate jobs. A process that keeps sending media does not necessarily handle every broadcast lifecycle decision for you.
Account for how long the event runs. YouTube Help says streams under 12 hours are automatically archived. A continuous 24/7 channel should not assume that one archive represents an arbitrary-length broadcast or that an encoder loop manages the event lifecycle. Check YouTube’s current guidance for the channel and workflow you use, and plan how you will manage ending, scheduling or continuing the broadcast.
For a different approach where running and watching a computer is the problem, compare cloud streaming options for a 24/7 YouTube channel. The relevant trade-off is who is responsible for keeping the media process going and noticing when it stops, not a promise that any approach removes the need to check the actual YouTube feed.
Validate files, encoding and stream output
Concat works most smoothly when the source files have compatible stream characteristics. If clips differ in resolution, frame rate, codec, audio layout or time base, concatenation can produce errors or uneven transitions. Test the whole intended library or normalise files to a consistent format before the long run. Do not assume that two files both ending in .mp4 are necessarily compatible with the same simple workflow.
Encoding can make different inputs more consistent, but it uses processing capacity and takes care. The example uses H.264 video and AAC audio with FLV output because that is a familiar RTMP-style pattern, not because it is the correct choice for every setup. Choose frame rate, bitrate, keyframe interval, audio settings and encoder according to the actual source media, available processing resources and YouTube’s current requirements for the selected protocol. Test motion-heavy scenes and quieter audio as well as a single representative clip.
YouTube supports more than one ingestion path, and settings are not interchangeable. Its HLS ingestion guide specifies muxed M2TS, H.264 or HEVC video, AAC audio, closed GOP, and up to 60 fps for that workflow. The same guidance notes relatively higher latency for HLS. Those are HLS details, not a reason to apply an HLS example blindly to an RTMP destination. Use the protocol shown for your stream and consult the corresponding official instructions.
A practical preflight can be brief but should cover more than whether FFmpeg starts. Check that each file decodes; that the list includes the intended entries once; that transitions do not leave a long silent gap; that audio levels are reasonable across clips; and that YouTube’s preview receives the expected picture and sound. Observe a transition between files, because a short test of one file will not reveal every concat boundary problem.
Think about monitoring as a separate layer. A useful setup tells you if FFmpeg exits or YouTube stops receiving the feed, and gives you enough logs to identify whether the issue was a missing file, a decoding problem, network loss or a rejected destination. This is especially important for a channel that runs through the night. The guide to YouTube stream key errors on a 24/7 Indian music channel can help distinguish a destination credential issue from a media-playback issue.
Add external control for a new shuffle each cycle
To reshuffle after every complete pass, add a supervisor or playlist controller around FFmpeg. At the end of the current cycle, that controller must prepare a new randomized order and arrange for FFmpeg to move to it, either by a controlled restart or by a playlist source designed for transitions. The appropriate method depends on whether a brief interruption is acceptable and how much control you need over handover.
A simple restart-based design has clear steps: generate a new list from the approved media set, validate it, then start FFmpeg against that list for the next cycle. The difficult part is detecting the actual end of a cycle and handling the boundary safely. If you stop the current process too early, viewers may lose the final clip; if you wait without a reliable signal, the next cycle may not start promptly. Build explicit state and logging around that handover rather than relying on a sleep timer that guesses clip duration.
A more capable controller can coordinate a transition while keeping output active, but it must manage which files are opened, how timing is handled, and what happens if the next list is missing or invalid. That is more work than repeating one known sequence. Test failures as well as the normal path: for example, what happens if a file is removed after the next list is built, or if the controller cannot start the next encoder session.
Do not count on rewriting shuffled.ffconcat while FFmpeg is already processing it to change the active sequence. The documented input loop repeats its input; it does not promise to reread a modified list and reshuffle on each pass. Treat each opened list as fixed for that run unless you use a separately designed mechanism whose behaviour you have verified. Also keep YouTube’s ingest playlist or segment ordering distinct from your source-video order: HLS segments reconstruct a transmitted stream, they are not a source-video shuffler.
For some channels, one shuffle per day or a manually prepared new order between scheduled runs may be a better compromise than cycle-by-cycle automation. Make the decision based on how noticeable repetition is to your viewers and how much operational complexity you are willing to own. More frequent reshuffling is not automatically better if it adds unreliable transitions to a stream that otherwise plays cleanly.
Choose a workflow you can recover
The comparison is less about a universally best command than about what must happen after a failure or at the end of a cycle.
| Approach | What repeats or changes | Operational trade-off |
|---|---|---|
One randomized concat list with -stream_loop -1 |
The same shuffled order repeats | Least moving parts; the cycle boundary repeats predictably |
| New list between planned runs | A newly generated order starts with the next run | Easy to inspect, but requires an intentional restart or schedule |
| External controller at each cycle boundary | A new order is prepared and activated each cycle | More control over variety, with extra transition and failure handling |
For a solo creator, the first approach is often easiest to understand and recover: you know what will play after a restart, and you can test the list on a desktop before committing it to the channel. A small newsroom or a business with scheduled campaigns may prefer deliberate playlist changes between runs, where someone checks the next order. A station whose listeners stay for repeated cycles may decide the added control is worth building, but should test that control before leaving it unattended.
If the real problem is that your personal computer must remain on and you do not want to manage a local process overnight, StreamNeo can take the uploaded-file and computer-off part out of that routine while you still provide your own YouTube stream key. It does not change the editorial question of whether a fixed order is suitable or the need to check YouTube’s broadcast setup.
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 reshuffle my files each time?
No. It repeats the input indefinitely, so a concat list that was randomized once plays in that same order on each pass. To create a new order per cycle, add external control that generates and activates a new list.
Does FFmpeg provide my YouTube server URL and stream key?
No. YouTube Studio provides the connection details for the selected stream, and you enter them as the encoder destination. Keep the key private and confirm receipt in Live Control Room after starting FFmpeg.
Can I edit the concat list while FFmpeg is running?
Do not rely on that to change the active sequence. The documented loop behaviour does not promise that FFmpeg will reload an edited list, so use a planned restart or a controller with a tested transition mechanism.
Can I use the same settings for RTMP and HLS?
Not necessarily. YouTube’s HLS instructions specify their own container and encoding requirements and note higher latency; use the guidance for the ingestion protocol selected in Studio rather than copying settings across protocols.