First identify what FFmpeg is reading: a single local file, a concat-demuxer text playlist of files, or an HLS .m3u8 input. For a finite local file or concat playlist, -stream_loop -1 before the relevant -i tells FFmpeg to repeat that input; it does not fix HLS behaviour or every reason a broadcast may stop.
That placement matters because -stream_loop is an input option. The examples below show the general pattern, not a tested command for your particular files, FFmpeg build, or YouTube settings. Check your streams, output options, and logs before relying on it overnight.
Identify what kind of input is stopping
The word “playlist” can mean different things in a streaming command. You might be sending one video file, using a local text file that lists several media files, or reading an HLS playlist ending in .m3u8. Those are different inputs and should not be treated as though one loop flag solves all of them.
A single file is the simplest case: the command has an -i followed by a video or audio path. A concat-demuxer playlist is usually a text script with entries such as file 'morning.mp4' and file 'evening.mp4'. FFmpeg reads those files in sequence as one input. By contrast, an HLS playlist is a manifest that refers to media segments and may be refreshed as a live feed continues.
Look at the exact input named after each -i in your command. If it is a local media file or a local concat script, it is finite and can reach end-of-file. If it is an .m3u8 URL, first inspect whether it describes a live, updating feed or a finite VOD playlist. A source feed that has stopped updating is not made live again by asking FFmpeg to replay it indefinitely.
This distinction also helps separate source handling from YouTube ingest. An HLS playlist used as FFmpeg's input is not the same thing as an HLS protocol chosen for sending a stream to YouTube. YouTube's HLS setup guidance describes ingest requirements for HLS; it does not change how FFmpeg loops a finite local file.
If you are building a sequence of audio tracks rather than video clips, the MP3 playlist example for YouTube Live covers a related workflow. Use it for context, but diagnose your own input type and command rather than assuming the same output settings apply.
Apply -stream_loop -1 to a finite input
FFmpeg documents -stream_loop as an input option: 0 means no loop, while -1 means loop indefinitely. Put it before the -i whose input should repeat. This is the key change for a finite local file that should be read again after it reaches its end.
For example, a single-file command has this general shape:
ffmpeg -re -stream_loop -1 -i 'video.mp4' \
-c:v libx264 -c:a aac -f flv \
'rtmp://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
The important part for looping is -stream_loop -1 before -i 'video.mp4'. If you put it after the input, it will not apply to that already-opened input in the intended way. Keep -re only when you want a file read at its native rate for live output: it paces reading, but does not create a loop by itself.
If your command has multiple inputs, such as separate audio and video files, place the option before the particular finite input that needs repeating. Looping the video does not necessarily keep the output alive if a shorter, unlooped audio input ends and an output option or filter causes FFmpeg to stop. Review each -i and the stream mapping together.
The FFmpeg documentation for -stream_loop and read-rate options is the primary reference for the option's meaning and placement. The option addresses repeated reading of an input; it is not a general process supervisor. It will not restart FFmpeg after a crash, restore a lost internet connection, repair a broken source, or guarantee that YouTube continues to accept the broadcast.
A file can also loop successfully while the stream still looks interrupted at the join. Different timestamps, codecs, frame rates, or durations may create a visible or audible discontinuity as the input starts again. Inspect the source and the transition, not just whether the process remains open.
Use a concat playlist to repeat multiple files
For several local files, FFmpeg's concat demuxer reads a text script and presents the listed files in order as an input. A small script might look like this:
file 'clip-one.mp4'
file 'clip-two.mp4'
file 'clip-three.mp4'
Save it as playlist.txt in a location FFmpeg can read, or use paths that resolve correctly from the command's working directory. With the concat demuxer, repeat the playlist input by placing the loop option before its -i:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \
-c:v libx264 -preset veryfast -c:a aac -f flv \
'rtmp://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
This is a general pattern, not a guarantee for every media set. It assumes a usable concat script, readable files, compatible streams, and an output configuration that suits your sources and current YouTube encoder guidance. In particular, the example re-encodes video and audio; you may need to adapt codecs and settings to your media and available encoders.
FFmpeg's concat demuxer documentation says the files should have matching streams, codecs, and time bases. If one clip has a different audio layout or video characteristics, the demuxer may not behave as you expect at transitions. Accurate durations matter as well; a bad duration can create gaps or artifacts when FFmpeg seeks or joins files.
Keep the list explicit and test each path. A typo, a relative path evaluated from a different working directory, or a file that has been moved can make the playlist fail before looping is relevant. If the sequence is intended to change by time of day or by order, decide that in the playlist itself; -stream_loop -1 repeats the whole input sequence, not a scheduling policy.
For a channel built around rotating property clips, the FFmpeg rotation guide is a useful companion. A devotional station with a planned sequence can also compare its scheduling needs with playlist rotation across Indian time zones. Neither changes the compatibility checks required by the concat demuxer.
Review the example command and placeholders
Read a command in groups: input pacing and looping, input format and path, encoding, output format, then destination. This makes it easier to see whether the fix is attached to the input that actually ends, and whether another option later in the command is limiting the output.
| Part of command | What it does | What to check |
|---|---|---|
-re |
Reads a file at its native rate for live output | It paces input; it does not repeat it |
-stream_loop -1 |
Repeats the following finite input indefinitely | Place it before that input's -i |
-f concat -safe 0 |
Selects concat demuxing and relaxes path-safety rules | Use only with a playlist you control and understand |
-i playlist.txt |
Names the input script | Check the path and every listed file |
-c:v and -c:a |
Selects video and audio encoding | Adapt to the source and current YouTube guidance |
-f flv and destination |
Selects an output format and sends to an ingest address | Use the current URL and key shown in Live Control Room |
The table is a reading aid, not a settings prescription. The sample uses libx264, aac, and FLV output as a familiar RTMP-style shape, but the right options depend on whether your files contain audio, the codecs and dimensions they use, your FFmpeg build, and the ingest protocol you selected. Do not copy a video option into an audio-only command without checking what streams exist.
Replace both destination placeholders with the current ingest URL and stream key displayed in YouTube Live Control Room. Do not leave placeholder text in the real command. Do not paste the completed destination into public forums, screenshots, scripts shared with others, or a blog post. The key is a credential that lets a sender transmit to your channel.
If you already use a VPS and want to understand the broader sender setup, the FFmpeg over RTMPS walkthrough is relevant. It is still your responsibility to verify the current ingest details and protect the key. A tutorial cannot tell you whether a particular stream key remains valid or which ingest protocol is selected in your account.
Check matching streams and encoding requirements
Before you blame looping for a stop or bad transition, inspect the files. The concat demuxer expects files with corresponding streams and compatible codecs and time bases. For a playlist of video clips, check that each clip has the expected video stream and that audio is present or absent consistently. Differences need not always prevent reading, but they can complicate decoding, mapping, and the output at a boundary.
Use ffprobe or FFmpeg's input log to examine each file's streams. Confirm whether it has video, audio, or both; note codec and timing information; and check for damaged or truncated files. If a clip plays by itself but fails only in the sequence, compare it with the neighbouring entries. If every file works individually but the concat input fails, verify script syntax and paths first.
The sample re-encodes with H.264 video and AAC audio, but those are not magic values that make every command correct. Check YouTube's current encoder guidance for the selected ingest protocol and match your output's frame size, frame rate, audio properties, and bitrate to the source and channel requirements. Avoid introducing unnecessary conversions: encoding uses local compute, and a machine that cannot keep pace may fall behind or drop frames.
If a transition has a pause or a jump, review the declared durations in the concat script and the actual media lengths. FFmpeg's concat documentation warns that inaccurate duration information can affect transitions. A one-file loop can also have a jump at the end-to-start boundary simply because the final frame and first frame do not form a natural visual or musical transition. No command option can make unrelated content seamless.
A useful small test is to run the input locally through a few transitions and observe both FFmpeg's log and the output file or preview. That can reveal a missing stream or a timestamp issue before you use a live key. It is a diagnostic step, not proof of overnight reliability: network conditions, account settings, and long-running process behaviour remain separate concerns.
Protect the YouTube stream key
Treat the stream key as a password for sending a live broadcast. Keep it out of public terminal screenshots and pastebins, and avoid sharing a full command that includes the completed destination. If a key is exposed, use YouTube's current Live Control Room controls to replace or reset it as appropriate, then update the sender.
For repeatable operation, store secrets in a local configuration that is readable only by the account running FFmpeg, or use a method appropriate to your operating system and workflow. Be careful with shell history, process listings, logs, and automation files: a command that is private in a terminal may be recorded elsewhere. Do not assume that quoting or obscuring the command protects a key if the destination is still visible to other users on the machine.
Check the current YouTube guidance on setting up a live stream for the ingest path and protocol instructions relevant to your setup. The URL and key are account-specific; do not copy them from an old command or another creator's example. A correct loop flag cannot compensate for an incorrect destination or an exposed credential.
Confirm output and diagnose remaining failures
If the command still stops, work through the actual command and log rather than adding flags at random. First verify the finite input is the one that reaches EOF, and confirm -stream_loop -1 sits before its -i. Then check whether another input is shorter, whether stream mapping selects the streams you intended, and whether the process reports a read or decode error at the point it stops.
Look for output limits and termination conditions. Options such as -t or -to can limit output duration, while -shortest can cause output to end when the shortest mapped stream finishes. Filters, scripts, terminal sessions, or external process managers may also be responsible for stopping FFmpeg. The loop option only controls repeated reading of its targeted input; it does not override every output or process condition.
For an HLS .m3u8 input, examine whether the playlist is updating, whether segment requests succeed, and what the FFmpeg log reports. Do not apply the finite-file remedy on the assumption that it fixes a stalled live feed. If you are sending HLS to YouTube, check the current official ingest guidance separately: its playlist and segment requirements concern that output protocol, not the repetition of a local concat input.
A working finite-input loop also does not guarantee an uninterrupted YouTube broadcast. FFmpeg can exit, the computer can sleep, a network path can fail, or YouTube can stop accepting a feed. If your real problem is that a process does not recover after a drop, that is a separate monitoring and restart problem; the automatic FFmpeg restart guide addresses a different part of the workflow.
For readers who do not want their own computer to keep a file-based stream running, StreamNeo can remove the need to leave that computer on by taking an uploaded video and running it as a YouTube live stream; it does not repair an FFmpeg HLS input or make a custom FFmpeg pipeline unnecessary for every use case.
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 repeat one video file forever?
It tells FFmpeg to loop the following input indefinitely when used as an input option before -i. The output can still stop for another reason, and looping does not guarantee a clean transition or uninterrupted delivery to YouTube.
Can I use it with a concat playlist of several files?
For a finite local concat-demuxer script, it can repeat the playlist input when placed before the -i for that script. Make sure the paths work and the files have compatible streams, codecs, and time bases; the example command is not a guarantee for every media set.
Will it fix an HLS .m3u8 input that has stopped updating?
No general claim can be made that this option fixes HLS inputs. Check whether the manifest is live or finite, whether it is refreshing, and what the FFmpeg log says before changing the pipeline.
Why does the stream stop even though I added the loop option?
Check that the option is before the correct -i, then review other inputs, -shortest, -t, -to, and any errors in the log. Also verify the YouTube destination and the health of the sender process and network; repeating a file only addresses that finite input's end.