A repeated picture on a YouTube 24/7 stream does not, by itself, show that FFmpeg is restarting its playlist. First establish whether FFmpeg is repeating an input, reaching the end of a list, restarting as a process, or continuing normally while YouTube preview stalls.
There is no defensible single cause without the command, playlist, FFmpeg version, logs and any timestamped Live Control Room messages. Work from local playback evidence first, then investigate ingest and network symptoms separately. A concat playlist reads its entries in sequence; it does not inherently repeat the first file.
Confirm what “restarting the playlist” means
Use a specific observation rather than the word “restart”. Note the time of the apparent repeat and identify the clip playing immediately before and after it. Then check whether later entries appear at all. These distinctions point to different parts of the system and prevent an unnecessary change to the loop settings.
There are at least three separate behaviours to distinguish:
| What you observe | What it could mean | Evidence to check |
|---|---|---|
| The same first clip returns before later clips appear | The input, list contents or option placement may not match your intention | Local output, exact command and playlist text |
| The whole list plays and then starts again | The input sequence may be configured to repeat, or a supervisor may launch a fresh run | End-of-list log lines and process ID |
| The picture freezes or stream disconnects, while FFmpeg keeps running | Output, ingest or network trouble may be separate from input sequencing | FFmpeg output and timestamped YouTube health status |
Record whether the FFmpeg process is still alive at the moment you notice the problem. If you can check the process ID, note whether it changes between runs. A new process suggests a service manager, shell loop, container policy or scheduler may be involved; a stable process that keeps emitting frames suggests a different line of investigation. Neither observation alone proves the cause.
For a useful test, play a short sequence locally or capture the local output around the transition. Keep the order and filenames visible in your notes. A two-minute excerpt spanning the moment of the repeat is more useful than a general description such as “it restarted overnight”.
Check whether the command loops a single file
Read the command from left to right and mark each -i input. FFmpeg options are associated with inputs or outputs according to where they appear, so an option intended for one source may affect another if it is placed differently than you expect. In particular, check that -stream_loop is before the -i for the input you intend to loop. Consult the manual for the FFmpeg version actually installed: the FFmpeg documentation is the primary reference, and its online version may not exactly match an older build.
A single-file loop and a multi-entry playlist are different arrangements. If the command names one MP4 as its input and loops that input, FFmpeg is not being asked to advance through a separate playlist. If it names a concat script, inspect whether the loop option applies to that script input and whether the script contains the intended entries. Do not paste a replacement command into a live broadcast until you have tested it with a private or unlisted stream.
Also look beyond FFmpeg’s own arguments. A service unit, process supervisor, shell while loop, container restart policy or scheduled task can start the same command again after it exits. This can look like a playlist loop from the viewer’s side, even though each process simply begins at the first input. Compare process start times and IDs with FFmpeg’s log timestamps to see whether the input is repeating inside one run or a fresh run begins.
If you ask someone to help diagnose it, share a redacted command and remove the YouTube stream key. Never post that key in a public forum, screenshot or log excerpt. The FFmpeg single-file streaming guide can help you check the basic shape of a command, but your own input order and options still need to be verified.
Verify which input options apply to each -i
Make a small map of the command rather than trying to infer its behaviour from a long line of text. For example, write down “input one: concat script”, “input two: background audio”, then note which input options appear immediately before each -i. Separately note output options, which usually follow the inputs and precede the output destination. This is a reading aid, not a substitute for the syntax documented for your installed build.
For each input, answer three questions: what file or source does this -i name; which options immediately precede it; and does the input itself represent one file, a concat script, or another playlist format? A command with several inputs can make a misplaced option easy to miss. If the same media appears more than once in the command, distinguish the intended looped input from other uses of that file.
Check for duplicated or contradictory-looking loop instructions too. A shell loop that reruns FFmpeg and an FFmpeg input loop are separate mechanisms. Combining them may cause the process to restart at the beginning after an exit while also looping within a run, which makes the observed pattern harder to interpret. For diagnosis, temporarily simplify the setup in a private test rather than changing multiple options on the live channel at once.
Capture ffmpeg -version and the complete command, with secrets removed. Note the operating system and how the command is launched if a supervisor or scheduler is involved. The installed version matters because the rolling online manual and the behaviour available in a packaged build may differ.
Inspect playlist entries and format
Open the exact file passed to FFmpeg and check its contents, not just its filename. Confirm that all expected clips are present, in the intended order, and that no entry is duplicated. Look for paths that point to an older copy of a file, empty lines or malformed entries, and verify that the process can read every path from its own working directory. A playlist that is valid on your desktop may not resolve the same relative paths when launched by a service.
Do not assume that a file ending in .m3u or .m3u8 is equivalent to an FFmpeg concat script. Extensions do not establish format or playback semantics. Confirm which demuxer FFmpeg is using and whether the file contents follow that format. If you have more than one playlist file, record the full path of the one named by the command so you do not inspect a similarly named but unused copy.
A useful evidence bundle includes the playlist text, the command, the FFmpeg version and a short log excerpt from just before and after the unexpected transition. Redact credentials, including the stream key, and avoid posting private media paths if they expose personal information. If the list is long, include the first entries, the entry you expect next, and enough surrounding lines to show whether the sequence is complete.
If local output advances as expected but YouTube does not, keep the playlist evidence unchanged while checking the separate output path. The article on reducing buffering on a 24/7 mantra stream is relevant when the symptom is buffering, but buffering alone does not tell you whether the source sequence has repeated.
Understand what the concat demuxer does
FFmpeg’s concat demuxer presents files one after another as a virtual input. In ordinary use, it follows the listed sequence; it does not mean “repeat the first file”. If the first clip appears again unexpectedly, inspect the actual input, list contents, option placement and process management before attributing that behaviour to concat itself. The FFmpeg concat documentation explains the demuxer and its requirements.
The demuxer is intended for files whose streams are compatible. FFmpeg states that files must have the same streams, codecs and time base. If source clips differ, stream-copy concatenation may not be suitable; a concat filter with re-encoding can be used when streams need normalising. That has a practical cost: re-encoding uses processing capacity and requires you to make deliberate choices about output format and settings. Do not switch approaches just because a join looks wrong; first establish whether the files and metadata are compatible.
Duration metadata also matters at joins. Incorrect durations can lead to gaps or artifacts even when the list order is right. Compare the transition locally and inspect the relevant log output before concluding that a visual glitch means the first file has restarted. A momentary jump, frozen frame or audio discontinuity is not the same as a repeated input sequence.
The right choice depends on the files. If every clip has compatible streams and timing, the demuxer can avoid a re-encode. If clips differ in format or stream layout and you need them normalised, a filter and re-encode may be the more appropriate path. Test a representative short sequence before changing the production playlist, and keep the original files and command so you can revert.
Compare local playback with YouTube preview
Treat local output and YouTube preview as two different observation points. First establish whether FFmpeg is still running and producing the expected frames and audio locally. Then compare the same timestamp with the YouTube preview and Live Control Room. If the local sequence is correct while preview freezes or disconnects, changing playlist order or loop behaviour is unlikely to address the first thing you have observed.
In Live Control Room, note the time and wording of any stream-health error. YouTube can report problems concerning container or codec, missing or multiple streams, bitrate, audio or video settings, and keyframe frequency. Those messages are evidence about delivery and ingest; capture them rather than paraphrasing them as “YouTube restarted the playlist”. Check the current YouTube live encoder settings guidance because recommended settings depend on codec, resolution and frame rate and can change.
YouTube’s current guidance recommends a keyframe interval of 2 seconds and says not to exceed 4 seconds. These are encoder recommendations, not proof of why a clip repeated, and they do not guarantee that a stream will remain connected. Check the settings for the selected codec and output profile instead of applying a number in isolation.
Test changes privately or as an unlisted broadcast before altering a public channel. Change one thing at a time and compare the local transition, FFmpeg logs and YouTube health message at matching timestamps. The YouTube guide to streaming with an encoder is another official reference for checking the platform-side workflow.
Check stream health and outbound network separately
A stream that disconnects after a while may be experiencing an outbound connection problem even if the playlist is behaving as intended. Check whether FFmpeg reports output errors, whether the process remains alive, and whether the network link is stable at the corresponding time. A brief interruption can break delivery without changing which file the input is reading. YouTube’s streaming tips recommend enough upload capacity and a reliable connection; their guidance includes a 20% upload headroom recommendation. Treat that as a margin to plan for, not a promise that any particular connection will work.
Compare your measured upload capacity with the stream’s configured bitrate, allowing for other devices and traffic sharing the same connection. If the available upload fluctuates, a bitrate that fits at a quiet time may not fit reliably later. Check the current official bitrate table for your codec and resolution rather than relying on a generic bitrate copied from an unrelated setup. Record the times of any network drop, FFmpeg output error and Live Control Room warning so you can see whether they coincide.
FFmpeg’s fifo pseudo-muxer can optionally attempt recovery after output failures. That is a separate output-recovery layer: it may help with an output failure, but it cannot fix a playlist with the wrong entries, an option attached to the wrong input, or a process manager that relaunches the command. Add recovery only after identifying an output-side problem and checking the documentation for your installed version.
If the computer or connection cannot be kept available, remote hosting may reduce dependence on a home machine, but it will not correct a command or playlist error. The trade-off between running your own setup and a hosted approach is set out in YouTube 24/7 streaming software versus cloud streaming. StreamNeo can remove the specific burden of keeping your own computer running by taking an uploaded video and running it as a YouTube live stream, but you still need to provide a valid file and channel setup.
Build a diagnosis from evidence
Before changing the live setup, assemble a compact record that another person could use to reproduce the reasoning. Include the redacted command, ffmpeg -version, the playlist text, a log excerpt spanning the transition, whether the process ID changes, and the corresponding timestamped Live Control Room message if one exists. Add what you saw locally and in preview at that time. Do not include the stream key.
This evidence separates the main possibilities. A stable process reading a list with duplicate entries calls for checking the input and playlist. A changed process ID calls for checking how the process is supervised. Correct local output paired with an ingest warning points towards output settings or delivery. These are investigation paths rather than diagnoses: none can be confirmed without the actual evidence.
Keep the first test small. Use a short private or unlisted broadcast with the same input sequence and output settings, then change only the part implicated by the evidence. If you revise a playlist, verify its order locally. If you revise encoder settings, compare them with current YouTube guidance. If you revise process supervision, confirm that a genuine crash is not being mistaken for normal end-of-list behaviour.
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 the concat demuxer repeat the first file by itself?
No. It reads the listed files in sequence and does not inherently repeat the first entry. Check the actual playlist, input options and any process restart mechanism before deciding what is repeating.
Why does the first clip appear again after the full list?
That observation is consistent with a sequence being run again, but it does not identify which layer caused it. Check whether FFmpeg loops the list, a supervisor starts a new process, or the playlist is being regenerated with the same order.
Should I change my bitrate when the playlist repeats?
Not on that evidence alone. First compare local output with YouTube preview and inspect timestamped health messages; bitrate and network changes belong to an output or ingest investigation, not a proven playlist fix.
What should I share when asking for help?
Share the command with the stream key removed, FFmpeg version, playlist text, a short transition log, whether the process ID changes and any matching Live Control Room message. Never publish your stream key, and test changes privately or unlisted before changing a public broadcast.