FFmpeg’s concat demuxer can read a sequence of video files, but its documentation does not promise that a running process will reload a playlist when you edit the list. If you need to change what plays without restarting the publisher, separate source selection from the process that maintains the live output, then test that arrangement with your actual FFmpeg build and destination.
The practical distinction is between changing the next input and keeping the outgoing stream connected. Editing a text file may change what a later process reads; it is not a documented hot-switch control for a process that already has the file open. Your safest approach depends on what your current command reads and whether a short interruption is acceptable.
Can a running FFmpeg process reload a playlist?
Not on the basis of the concat demuxer documentation alone. The documentation describes a demuxer that reads a script of files and processes them in order. It does not specify that changes made to that script after startup are detected, or that the running process will switch to newly added entries.
That means a successful test on one machine should not be treated as a general guarantee. Operating system file behaviour, the way the file is opened, the FFmpeg build, and the exact input arrangement can all affect what you observe. Even if a particular setup appears to notice an edit, there is no documented live-reload contract to rely on for an unattended channel.
First identify what is actually feeding the process. Your command may use a concat script, loop one file, declare several -i inputs, or receive a source from a playlist service. Each is a different control path. Without the command and the destination, there is no responsible universal replacement command to provide.
If you can accept a stream interruption, the simple operational option is to stop and start the process with the revised source list. That is explicit and easier to reason about, though it may interrupt the YouTube broadcast session or leave a gap while it reconnects. If the output must remain continuous, design source changes separately from the publishing connection rather than relying on an edit to an open list.
For a broader view of process supervision, the guide to running FFmpeg as a background service covers keeping a process managed; supervision can restart a failed process, but it does not itself choose the next video.
How the concat demuxer reads its list
The concat demuxer takes a text script containing file entries and directives, then presents the listed files as a sequence. The FFmpeg formats documentation describes this as reading files one after another as though their packets had been muxed together. In a basic script, the lines name files in playback order, so the list is an input description, not a documented live control panel.
That distinction matters when you plan an update. A process started with a script has already begun consuming its input. The documentation explains the script syntax and how the demuxer handles the listed media; it does not define when or whether a running process revisits the script file. Treat the initial list as the input for that run unless your own tested application layer explicitly supplies updates.
The demuxer also builds a combined timeline. FFmpeg uses each file’s duration to position the next file. The documentation notes that inaccurate duration information can cause artefacts, while streams with different lengths can create gaps. A list that is syntactically valid can therefore still yield an awkward transition if its media timing is inconsistent.
Do not confuse an output playlist with an input playlist. Segmenting an encoded output creates chunks and a playlist describing those chunks; it does not establish that an input concat script can be edited to change the current source. Similarly, FIFO is an output-side mechanism for queueing and recovering from certain muxing failures, not a way to select a different video. The FFmpeg FIFO muxer documentation is relevant if your problem is output recovery, but it is not a playlist scheduler.
Check file compatibility before concatenating
The concat demuxer is most straightforward when every file presents matching stream layouts. FFmpeg’s documentation says files must have the same streams, codecs and time base. In practice, check that each video has the expected video and audio streams, codec parameters, dimensions, frame characteristics and audio layout before putting it into a sequence. Mixing a silent clip, a stereo clip, and a file with a different video format may produce errors or an unexpected result.
Use a probe or a reliable media inspection tool to make a small inventory of the files. Record which have audio, their stream codecs, frame rates, dimensions, time bases and durations. You do not need to make every source visually identical, but you do need to know which differences your concat method can handle and which need to be normalised first.
A preparatory transcode can make a set of clips more consistent, but it adds processing time, storage and a generation of encoding. It is not automatically necessary for every workflow. If you prepare files in advance, use a target format and stream layout appropriate to the command that publishes them, then test representative files together rather than testing each in isolation.
Pay particular attention to durations and stream endings. If an audio stream ends before the video, or one file reports a duration that does not match its actual packet timeline, the next file may not begin where you expect. Listen across the transition and inspect the output timestamps. A black frame, brief silence, repeated frame or abrupt audio cut can be a timing issue even when FFmpeg reports no fatal error.
If the channel depends on clean cuts, keep a known-good set of prepared files and add new media only after it passes the same checks. The playlist schedule test guide is useful for planning a change window and rehearsing the sequence before it goes live.
Why editing the open list is not a reliable live switch
There are several different operations people call “editing the playlist”: appending a new line, changing the file name in place, replacing the script atomically, or changing a symlink the script points to. They are not equivalent at the filesystem level, and none should be described as a guaranteed live reload unless the relevant application explicitly supports that behaviour and you have validated it.
For example, replacing a file with a new file at the same path may affect what a new process opens, but it does not establish that an already-running demuxer will discard its current state and parse the replacement. Appending a line has its own uncertainty: the reader may have already consumed the relevant script content. The central problem is not finding a clever shell command; it is the absence of a documented promise that the running demuxer polls for new entries.
There is also a continuity question. Even if an input change were accepted, the new media would need to enter the existing output timeline with compatible streams and appropriate timestamps. A selection change and an uninterrupted encoded output are separate requirements. Updating a filename alone does not explain how to handle the current file’s end, timestamp continuity, audio state, or the publisher connection.
For a simple channel with a tolerated maintenance break, a planned restart is often easier to observe and roll back than a speculative hot edit. For a channel where retaining the live output matters, use a scheduler or playout layer that controls the next source while the output process remains stable. The exact method depends on whether that layer feeds decoded media, an input protocol, or another supported interface into the publisher.
Keep output stable with a scheduler or playout layer
A robust design separates two jobs: deciding which video plays next and maintaining the connection to YouTube. The scheduler or playout component owns the order and timing of sources. A stable output process owns encoding and publishing. When the source changes, the scheduler supplies the next compatible media without asking the publisher to rebuild its entire output session.
This is an architectural pattern, not a one-command FFmpeg feature. How you connect the components depends on the source format and the interface your chosen playout layer offers. Some systems can feed a continuous media source to an encoder; others manage the encoding and destination themselves. Confirm that the selected design can preserve timestamps, audio continuity and the destination’s expected input before adopting it.
A scheduler is useful when you routinely change a devotional sequence, update a local news loop, or add new study material while a channel is live. It lets you prepare a revised queue and choose when it takes effect. It also gives you a place to reject an unavailable file, avoid duplicate entries, or fall back to a known-good item. Those controls need to be designed and tested; they do not appear just because a playlist exists.
The trade-off is complexity. You now have another component whose state, media access and failure behaviour need attention. Decide what happens if the next file is missing, if a clip runs longer than expected, or if the source feeder stops. A playout layer should have a defined fallback, and you should know whether its failure affects only source selection or also the publishing connection.
If you instead use output segmentation, understand what that changes. FFmpeg’s segment muxer writes separate output segments, and its documentation explains that cuts are tied to suitable keyframes; it works best with a single constant frame rate video. Segmentation can be useful for packaging or downstream playback, but it is not equivalent to dynamically replacing an input list. See the segment muxer documentation before treating it as a switching mechanism.
For a small channel that does not need custom orchestration, an uploaded-file workflow can remove the burden of keeping your own computer running and managing source changes during the night. StreamNeo turns an uploaded video into a YouTube live stream, so you can prepare the file and channel without relying on your desktop to remain on; it does not change the fact that playlist behaviour must be planned around the workflow you choose.
Validate transitions on your setup
Test with the same FFmpeg binary, operating environment, source files and destination you intend to use. The FFmpeg documentation site says its online documentation is regenerated nightly and corresponds to the newest revision. Your installed version or build may not match that page, so check the local version and relevant options rather than assuming a current web page describes your exact executable.
Begin with a non-public test output or a controlled maintenance window. Exercise the transitions that matter: a normal video to another normal video, a file with audio to one without it if your library has both, and a source near the longest or shortest expected duration. Watch and listen through the whole boundary. Review FFmpeg logs and output timestamps for warnings, gaps or discontinuities rather than judging only by a preview image.
If your design claims to keep the output connection open while changing sources, test that claim directly. Observe whether the destination sees one continuous broadcast session, whether the outgoing audio and video remain valid, and what happens if the next item is missing. A stream that reconnects quickly may look acceptable in a brief test but still be a different operational behaviour from an uninterrupted output.
Keep the test modest and repeatable. Use a short sequence that includes known-good media and one representative new file. Record the exact command, build information and result so that a later change to FFmpeg, the playlist layer or the media does not silently invalidate the test. Avoid inferring that a method works for all destinations from success with one destination.
If you are still deciding where the persistent process should run, the Raspberry Pi loop guide and Windows cloud PC guide discuss different operating contexts. Neither changes concat’s documented reload behaviour; they help you assess where your chosen source and publishing workflow will be managed.
Choose a safe update and rollback process
Write down the update procedure before changing a live channel. Keep the current playlist, media files and known-good command unchanged until the replacement has passed a test. Prepare new files in a separate location, inspect their streams and durations, and only then make them available to the scheduler or the next process start. That keeps an incomplete upload or transcode from becoming the live source by accident.
Choose an activation point that suits the channel. If a restart is acceptable, announce or schedule a maintenance break, stop the old process cleanly, start the revised one and confirm the destination is receiving the expected output. If you use a playout layer, stage the revised queue and switch at a tested boundary. Do not make an unverified file replacement while assuming the existing FFmpeg process will interpret it as a live command.
Keep a rollback path that does not depend on reconstructing the old state under pressure. Preserve the previous list and source files, note the known-good command or configuration, and define who or what can restore it. If the new sequence produces no audio, timestamp errors or a missing-file failure, revert to the known-good sequence and diagnose outside the live change window.
Recovery features should be assigned to the problem they actually solve. A process supervisor may restart a process after it exits. FIFO may help isolate certain output errors. Neither one selects the next input video. Keeping these responsibilities distinct makes it easier to understand whether a failure is in media selection, encoding, publishing or destination handling.
For channels that run unattended, include a simple check after a planned update: confirm the live output is present, the expected item is playing, audio is audible where applicable, and logs do not show repeated errors. This is operational verification, not a promise that a particular setup will never fail. The value is that a change has a known test and a known way back.
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
Can I append a file name to the concat list while FFmpeg is running?
You can edit a text file, but FFmpeg’s concat documentation does not promise that a running process will reload appended entries. Treat the list as input for a process run unless your own tested layer explicitly supports live updates.
Will replacing the playlist file at the same path make the current video switch?
Do not rely on that as a general live-switch method. A replacement may be read by a process started afterwards, but the documentation does not define dynamic re-reading by a process that already opened the script.
Does the FIFO muxer let me change the next video?
No. FIFO concerns output-side queueing and recovery from certain muxing failures. It does not choose a new input file or make a concat list a live scheduler.
What is the safest way to change videos without restarting the publisher?
Use a scheduler or playout layer designed to feed the next source into a stable output process, then test transitions with your installed FFmpeg build and actual destination. If you do not have such a layer, a planned restart may be more predictable than relying on undocumented list-file behaviour.