FFmpeg’s concat demuxer has no documented option to silently skip a file that is missing from its list. The dependable fix is to check the paths before launch and create a playlist containing only files that are present; if files can disappear during a broadcast, an external supervisor can rebuild the list and restart FFmpeg, with a possible interruption.
That distinction matters: YouTube is the destination, but this error happens when FFmpeg opens or reads a local input. You cannot fix it with a YouTube Live setting, and playlist regeneration followed by a restart is not seamless. This guide shows how to preflight a list, handle changing files, and test recovery before relying on it overnight.
Why a missing entry can stop FFmpeg
The concat demuxer reads a script that names input files and processes them in sequence. When FFmpeg reaches a listed path that it cannot open, it encounters an input error. The demuxer is not documented as a fault-tolerant playlist player that silently discards unavailable entries and carries on.
The failure may happen before the stream begins if the missing file is near the start of the list. If the file is later in the sequence, FFmpeg may begin output and fail when it reaches that entry. The exact point and error text depend on the command, file, and FFmpeg build, but the operational lesson is the same: do not assume an absent entry will be skipped.
You may see advice to add an onfail option. Do not treat that as a concat-demuxer missing-input setting. FFmpeg documents similarly named behaviour for other contexts, including output handling, but that does not make it a remedy for opening a missing local input. Check the documentation for the specific component and option before using a command copied from a different example.
The source of the error also helps narrow troubleshooting. If FFmpeg reports that it cannot open a path, first inspect the file list, working directory, permissions, and mount or drive availability. Changing YouTube stream settings is unlikely to resolve an input path that FFmpeg cannot read.
What the concat demuxer expects
A concat script is a text file with directives. A simple version looks like this:
ffconcat version 1.0
file 'video-01.mp4'
file 'video-02.mp4'
The ffconcat version 1.0 line must be the first line, with no leading space or byte-order mark, for automatic format recognition. Each file line names an input. Paths with spaces or special characters must be quoted or escaped correctly. The FFmpeg concat demuxer documentation describes the script and its options.
By default, the demuxer’s safe setting rejects paths it considers unsafe. Setting -safe 0 permits broader file names, but it relaxes a restriction rather than making files available or validating a playlist for you. Use it only with a playlist you control and trust. Keep the list generator responsible for producing the intended paths; do not accept arbitrary text as a trusted concat script.
The demuxer also has compatibility requirements. FFmpeg says that all files must have the same streams, including the same codecs and time base. If one file has a different stream layout or incompatible parameters, it may fail or produce problems even when every path exists. Duration information matters too: inaccurate or truncated-file durations can create timestamp artefacts or gaps.
If your videos do not share a compatible structure, the concat demuxer may not be the right tool. FFmpeg’s FAQ on concatenating media distinguishes the demuxer approach, which can avoid re-encoding compatible inputs, from the concat filter approach when re-encoding is needed. The filter can help you standardise differing material, but adds processing and encoding work. It is not a switch that makes a missing path harmless.
Check listed paths before starting
A preflight is a small check run before FFmpeg. Read the intended playlist, resolve each path in the same way FFmpeg will, and test that the file exists and is readable. Then either stop with a clear error or generate a second, filtered playlist containing only available entries. For a recurring channel, filtering is often more useful than stopping when an optional clip is absent.
Be precise about what “exists” means in your setup. A relative path is resolved from a working directory, which may differ when a scheduled task or service launches the command. A removable disk or network mount can be unavailable even though the directory name is correct. A file can also exist but be unreadable by the account running FFmpeg. Test from that same account and launch context, not only from an interactive terminal where you have different permissions.
A robust check should also reject an empty result. If every listed clip is absent, writing a header-only playlist may leave FFmpeg with nothing useful to play. Choose an explicit policy: do not start and alert you, retain a known-good fallback file, or wait and retry later. The right choice depends on whether silence, a fallback loop, or a stopped stream is least disruptive for your channel.
For a planned rotation, compare the generated list with the schedule before launch. The article on scheduling rotating video blocks is useful context if ordering and repeat patterns matter as much as file presence. Keep the missing-file check separate from editorial choices: a path check cannot tell whether a surviving clip is suitable for the current time or audience.
A basic preflight can be described without relying on a particular shell: take each candidate path, test readability, and write a file directive only for the paths that pass. Log the rejected paths with a reason, such as “not found” or “not readable”. This gives you something actionable when a scheduled item is unexpectedly skipped, rather than a stream failure that surfaces only after launch.
Generate a playlist from files that exist
There are two practical ways to build the filtered list. If the playlist is maintained by hand, put a validation step between that list and FFmpeg. If the source is a directory, enumerate files that match your naming and media rules, check each one, and write a new concat script in the intended playback order. Do not simply include every file in a folder if temporary, partial, or unrelated files can appear there.
Write the output to a temporary filename first, validate it, and then replace the active playlist. This reduces the chance that FFmpeg or another process reads a half-written script. It does not make changes to a currently running FFmpeg process take effect: the demuxer reads the list for that invocation. To use a newly generated list, you must start FFmpeg with it, which leads to the restart trade-offs below.
Keep a known-good copy or a deliberate fallback policy. If the latest generation produces no valid entries, do not overwrite a usable playlist with an empty one unless that is the intended response. A useful log records when the list was built, which paths were included, and which were omitted. Avoid logging secrets such as a stream key alongside these details.
Before launch, inspect the inputs as well as their paths. Confirm that selected files have the expected streams and compatible codecs and time bases. Use explicit -map options when appropriate so the output takes the intended audio and video streams; mapping does not resolve missing files or incompatible inputs, but it can make stream selection less ambiguous. If source files vary in resolution, audio layout, or encoding, decide whether to standardise them in advance or use a filter-and-re-encode workflow.
This is one place to keep the operational plan simple. A laptop-based stream also depends on the machine remaining on and the connection remaining available; the 24/7 stream cost calculator can help you think through that separate trade-off. It does not replace input validation, but it may help you decide whether your current arrangement is suitable for unattended running.
Handle files that change during a stream
A preflight catches problems that exist when the playlist is built. It cannot guarantee that a file will remain available until FFmpeg reaches it. Someone could rename or delete a clip, a drive could disconnect, or a storage location could become inaccessible while the process is running. For an unattended channel, decide who or what notices that change and what happens next.
If the video files are stable, a straightforward approach is to avoid changing them during a broadcast. Build the list, check it, and leave its inputs in place until the process ends. This is often easier to reason about than trying to update a live sequence. If updates are necessary, publish new files under new names and switch the playlist only at a planned restart rather than replacing a file that FFmpeg may currently be reading.
For files that may disappear unpredictably, use an external supervisor. That might be a script or process-management arrangement you operate outside FFmpeg. It can watch FFmpeg’s exit status and relevant logs, determine whether the input list needs rebuilding, create a fresh filtered playlist, and launch a new FFmpeg process. That is a recovery design you build and test; it is not a built-in concat-demuxer skip feature.
A supervisor needs clear rules. Decide which failures merit a restart, how it distinguishes a missing input from an authentication or network problem, whether it should retry, and when it should stop and alert you rather than repeat a bad command. Keep logs for both the supervisor and FFmpeg. If the process is restarted repeatedly without fixing the cause, the result can be recurring interruptions rather than recovery.
The stream output may break while FFmpeg exits and a replacement process starts. YouTube may show a reconnect or interruption, and viewers may need to wait for the broadcast to resume. The exact result depends on the output protocol and encoder configuration. YouTube’s HLS ingestion guidance discusses HLS-specific playlist and segment behaviour, including unique segment names across encoder restarts; do not apply those HLS details to an RTMP workflow without checking the corresponding current guidance. Neither protocol changes how FFmpeg handles a missing local concat entry.
If you choose an unattended workflow because you cannot keep a computer available, StreamNeo removes the specific burden of leaving your own machine running for a file-based 24/7 YouTube broadcast, but it does not change FFmpeg’s local missing-input behaviour or validate an incompatible playlist. It is YouTube-only, so it is not a fit if you need to send the same broadcast to other destinations. For local FFmpeg, keep the preflight and recovery logic in the setup you operate.
Choose a recovery approach that fits the inputs
The central choice is whether your files are already suitable for the concat demuxer and how likely they are to change. These approaches solve different problems; none makes an absent file silently playable.
| Approach | Use it when | Trade-off |
|---|---|---|
| Concat demuxer with preflight | Inputs are present and have compatible streams, and avoiding re-encoding matters | You must filter absent paths before FFmpeg starts and keep durations and stream layouts suitable. |
| Concat filter and re-encode | Inputs need processing or standardisation | Adds filtering and encoding work; it still needs valid inputs. |
| External supervisor and regenerated playlist | Files can go missing during operation and you want an automated recovery attempt | A new list requires a new FFmpeg process, so output may be interrupted; recovery logic needs testing. |
For a fixed collection of compatible clips, preflight plus the demuxer is usually the least complicated route. For mixed sources, normalise them before the broadcast or consider a filter workflow that can produce consistent output. If you need runtime recovery, add supervision only after the basic command and filtered playlist behave correctly on their own.
Do not confuse changing the encoder with changing the inputs. A 720p versus 1080p connection guide can help you choose an output workload for a constrained connection, but resolution choice will not cause FFmpeg to skip a missing file. Keep the input-list problem, media compatibility, and YouTube ingest configuration as separate checks.
Test recovery before broadcast
Test the exact launch path you intend to use: same account, working directory, playlist generator, FFmpeg command, and output settings. Start with a private or otherwise non-public test destination where possible, and do not use a live audience as the first test of a failure policy. Confirm that the generated script begins with the correct header, that paths are quoted as intended, and that FFmpeg can open every included file.
Then test the failure cases deliberately. Remove or rename one listed file before preflight and check that it is omitted or produces the chosen alert. Test an unreadable file and an empty candidate set. If you use a supervisor, test what it does when FFmpeg exits, whether it rebuilds a valid list, and whether it avoids an endless rapid restart loop. These are practical checks, not claims that recovery will always succeed.
Watch the output after a restart. Confirm that the new process reaches YouTube, that audio and video are present, and that the stream behaves as expected for your selected ingestion protocol. For RTMP, consult current YouTube guidance for that protocol rather than borrowing HLS-specific rules. Keep the stream key private and avoid copying command lines that expose it into shared logs.
Finally, test the ordinary overnight conditions that could make a correct path unavailable: the machine’s sleep settings, storage mounts, account permissions, scheduled-task environment, and network reconnection. A workflow that works only while you are logged in at a desktop is not yet an unattended workflow. The article on updating FFmpeg without interrupting a stream covers a different operational change, but the same principle applies: rehearse a process change before depending on it during a broadcast.
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
How do I get FFmpeg to skip a missing file in a concat playlist?
There is no documented concat-demuxer option that silently skips a missing listed input. Check paths before launch and write a new playlist that omits absent files, or stop with an alert if a missing item should block the broadcast.
Why does my YouTube live stream stop when one video is missing?
FFmpeg reads local inputs before sending their output to YouTube. If it cannot open a file in the concat script, the input process can fail; a YouTube setting does not repair that local path.
Can FFmpeg continue to the next video after a concat input error?
Do not rely on the concat demuxer to continue past a missing entry. An external supervisor can detect a failure, create a valid list, and relaunch FFmpeg, but the restart may interrupt the broadcast.
Should I use the concat demuxer or concat filter?
Use the demuxer when the files have compatible streams and you want to avoid re-encoding. Consider the concat filter when your workflow needs filtering or re-encoding to standardise inputs, and make sure every referenced input is still available.