If FFmpeg stops sending a YouTube stream when a local playlist reaches its last item, the likely cause is ordinary end-of-input. To replay that finite input, put -stream_loop -1 before the matching -i option.
That fix is not for every playlist. A live HLS input should refresh as segments arrive, while HLS output to YouTube has its own ingestion requirements; neither problem is fixed by blindly adding an input loop or a reconnect flag.
Determine what kind of playlist is ending
Start by identifying what the -i in your command actually reads. “Playlist” can mean a local text file that names media files, a concat-style input, an HLS URL that changes over time, or an HLS playlist that FFmpeg is publishing to YouTube. Those inputs have different endings and different failure modes.
A finite local playlist has a known last item. For example, a bhajan channel might send FFmpeg a list of recordings to play in order. Once the final recording finishes, FFmpeg has consumed everything it was given. Unless you tell it to repeat the input, reaching the end is expected.
A live HLS URL is different. It normally points to a media playlist that is refreshed as new segments become available. If this source stops changing or FFmpeg cannot fetch its segments, looping the entire input is unlikely to restore the live feed.
A third case is publishing HLS to YouTube. In that workflow, the playlist is part of the output sent to the platform. The question is not simply whether a local source should repeat, but whether the outgoing HLS playlist follows YouTube’s current ingestion requirements.
The distinction matters more than the word “playlist” in the error report. Write down whether the source is a file, a finite list, or a live URL, and whether FFmpeg is producing FLV/RTMP output or HLS output. If you run a concat list for a continuous devotional channel, the FFmpeg concat-file workflow is a useful companion reference, but first confirm that it describes the input you actually use.
Why a finite input stops normally
FFmpeg processes media until an input ends or an error prevents further reading. A finite file has an end timestamp; a playlist of finite files has a final item. Once that material is read, FFmpeg can close the input and exit normally. YouTube does not instruct FFmpeg to replay the source merely because the broadcast is intended to stay live.
This can look like a YouTube problem because the visible live stream ends at the same point as the source. Check the local process before changing channel settings. If FFmpeg exits cleanly after the same media has played through, that is consistent with natural completion. If it stops at irregular points and logs HTTP failures, missing segments, or connection errors, investigate transport and input refresh instead.
A continuous stream therefore needs two separate things: a source that remains available and a process that continues publishing it. Looping a finite source addresses the first condition by making the input repeat; it does not repair a broken network path, an invalid stream key, incompatible output settings, or a YouTube-side event state.
The official FFmpeg documentation for -stream_loop defines zero as no looping and -1 as infinite looping. This is an input option, not an instruction to keep the output connection alive after every possible failure. Treat the option as a source-repeat setting and diagnose output interruptions separately.
Place -stream_loop -1 before the input
For a finite input that should replay, place the option immediately before the corresponding -i. In this illustrative form, the option applies to playlist.txt:
ffmpeg -stream_loop -1 -re -i playlist.txt \\
-c:v libx264 -c:a aac -f flv "$YOUTUBE_INGEST_URL"
This is a pattern to adapt, not a tested or universal command. playlist.txt must be an input format your FFmpeg build accepts. Your actual command may need different codecs, stream mapping, input options, output protocol, or container. Use the private ingest URL and stream key provided in your YouTube Live setup, and do not paste them into public logs or forum posts.
Option placement is the important part here. FFmpeg options can apply to inputs or outputs, and -stream_loop is an input option. Putting it before the relevant -i tells FFmpeg to repeat that input. Putting it after the input may not apply the setting where intended. If a command has several inputs and more than one should repeat, place a separate -stream_loop -1 before each relevant -i; do not assume one occurrence loops every input.
The -re in the example asks FFmpeg to read at approximately the input’s native rate, which is commonly useful when sending file media as a live feed. It is included only as an illustrative choice, not a requirement for every workflow. Confirm the behaviour you need for your source and build rather than copying every option unchanged.
Looping may also expose practical differences between the end and start of the material. A playlist can repeat, yet still have a pause, a hard cut, or an abrupt change in sound at the join. If the audience hears an unexpected silence, look at the media and playlist transition as well as the command. The loop option controls repetition; it does not make separate recordings blend seamlessly.
Adapt the sample to your source and output
Before running an adapted command for a long broadcast, check each part of it. The input name must resolve from the directory where FFmpeg runs, and any paths inside a list must be valid in that context. A process started by a scheduled task or service may have a different working directory from your interactive terminal.
Next, confirm which streams are present and what you intend to send. A video-only ambience file does not need an audio mapping that assumes a soundtrack. A playlist with changing video or audio properties may need a consistent output configuration. The sample’s -c:v libx264 and -c:a aac are examples only; they do not establish that those encoders are available in your build or that these settings suit your content and ingest path.
Then check the output format and protocol. The sample uses FLV as an illustrative output container and a placeholder variable for the ingest URL; your YouTube workflow may use a different supported configuration. Do not substitute a public watch-page URL for an ingest address. Keep stream credentials private, including when sharing command output for help.
If you already have a working command, change only the input-loop placement first. This makes the result easier to interpret. If you rewrite the command, change one category at a time: source repetition, stream selection, encoding, then output. A command that both loops and changes codecs can fail for reasons unrelated to looping.
If FFmpeg reports that the option is unknown or behaves differently than expected, check the version and its help output on the machine that runs the stream. Builds and input formats vary. The documented option is a sound starting point, but the exact invocation still depends on the actual input and FFmpeg build.
Separate local looping from live HLS input
A live HLS input should provide a changing media playlist. If FFmpeg stops reading it, look at whether the playlist URL still updates and whether the referenced media segments can be retrieved. A static snapshot, expired URL, access restriction, or failed segment request can leave the process without new media even though the original command included a network input.
FFmpeg’s HLS demuxer documentation describes controls related to playlist reloads and segment retrieval. These controls are for a live HLS input’s refresh and fetch behaviour. They are not substitutes for repeating a finite local list, and they should be considered only after you verify that the source really is HLS and that its playlist should still be changing.
For a live source, compare the time of the last playlist update with the time FFmpeg stopped progressing. Review the process output for request failures and identify whether the playlist itself or an individual segment is unavailable. If you can access the source in a browser or a separate diagnostic tool, confirm that the URL is still valid and that it is returning a current media playlist, not an old copy. Do not expose signed URLs or credentials when sharing diagnostics.
If instead FFmpeg publishes HLS to YouTube, inspect the output path and the actual ingestion mode. YouTube’s HLS ingestion guide says its ingest accepts media playlists and ignores master playlists, and describes playlist and segment constraints. Those requirements concern what the publisher sends to YouTube. They do not turn -stream_loop -1 into an HLS publishing fix.
One useful comparison is to ask three questions: does the input naturally reach EOF, should the input playlist be changing, and is FFmpeg sending HLS or another output protocol? The answers point to different work. For local finite files, consider looping. For live HLS input, check refresh and retrieval. For HLS output, verify the current ingestion requirements. If you want background on keeping an always-on broadcast process dependable, see how to build a resilient live streaming workflow.
Check output and reconnect behaviour
Reconnect options can be relevant when a network connection drops, but they do not mean “replay this finite playlist.” FFmpeg documents reconnect_at_eof in its protocol options as treating end-of-file as an error and reconnecting, a behaviour intended for network sources that may resume. A local list reaching its last item has no remote source to reconnect to; use input looping when you intend to replay it.
Likewise, an HLS output option such as hls_flags omit_endlist changes whether an end-list tag appears in the generated HLS playlist. It does not repeat the media fed into that output. A playlist marker and the lifetime of the input are separate concerns, so do not use an output-list setting as a general response to finite source completion.
Read FFmpeg’s final messages rather than relying only on the YouTube player. A clean exit at the same point on repeated runs suggests the input finished. Repeated connection errors, HTTP status errors, or messages about missing segments point towards transport or retrieval. Encoder errors and invalid stream selection point to a different class of problem. The exact wording depends on the build, so use the message as evidence rather than matching it to a single expected phrase.
Also distinguish an FFmpeg process that is still running from one that has actually exited. If the process remains alive but the YouTube stream appears stalled, inspect whether frames and packets are still being read and written. Then check ingest connectivity and the live event’s state. If the process has ended, determine whether it ended at input EOF or failed earlier. A restart policy can relaunch a process after a crash, but it will simply repeat the same finite input and end again unless the input itself is set to loop.
Test the repeat workflow before relying on it
Test the exact input and adapted command for a short period before leaving it unattended. Confirm that FFmpeg starts, reads the expected streams, and sends the intended output. Then observe the transition at the point where the playlist would ordinarily finish. The useful result is not merely that the process stays open; check that the next pass begins and that audio and video continue as intended.
For a list of several recordings, inspect the order and the last-to-first join. If the first item is a short station ident and the last is a long programme, the repeated sequence may be technically continuous but editorially awkward. If a recording has silence at its end, looping faithfully reproduces that silence on every cycle. The source material and sequence determine the listening experience.
Keep a known-good copy of the original command before editing. Record the input path, FFmpeg version, output type, and the relevant final log lines if a test fails. Remove or redact ingest credentials before sharing anything. This makes it possible to isolate whether a change to looping helped without accidentally exposing the channel key.
For an always-on channel, the host running FFmpeg also matters: it must remain powered, connected, and able to run the process. A command-line loop prevents a finite source from ending the job, but it does not monitor every other failure or guarantee that a computer or network stays available overnight. The 24/7 playlist streaming guide covers the broader workflow around sending a sequence of videos.
If managing a local process and keeping a computer on are the part that repeatedly interrupts your channel, StreamNeo removes that specific operational burden: you upload a video once and it runs as a YouTube live stream without keeping your own computer switched on. It is YouTube-only, so it is not a replacement for a workflow that needs another platform or requires direct FFmpeg control over a live HLS input.
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
Why does FFmpeg stop when my playlist finishes?
A finite file or list eventually runs out of media, and FFmpeg can exit normally at that point. If you want the same input to repeat, put -stream_loop -1 before its -i option. If it stops at varying times with network errors, investigate those errors instead of treating the end as normal completion.
Does -stream_loop -1 go before or after -i?
Put it before the -i for the input you want to repeat, because it is an input option. With multiple inputs, place it before each input that independently needs looping. Check your FFmpeg build and input format if the option is unavailable or does not behave as expected.
Should I use a reconnect flag for a finite playlist?
No, not as the fix for a finite input reaching its natural end. Reconnection is for network recovery; looping tells FFmpeg to replay the source. For a live HLS URL that stops updating, investigate playlist refresh and segment retrieval instead.
Is omit_endlist enough to keep a YouTube stream running?
No. It affects an HLS output playlist marker and does not loop the source media. If you publish HLS to YouTube, check the current YouTube ingestion guidance; if the input is finite and should repeat, configure repetition at the input.