If you edit a local FFmpeg concat list while FFmpeg is running, do not assume the active process will read the changes. FFmpeg documents ways to join files, but its documentation does not promise that an edited list will be reread as a live queue.
To change upcoming videos without disconnecting from YouTube, use a playback controller that can hand sources to one continuing encoder. If your current setup cannot hand off inputs, plan a controlled restart. Also check what you mean by “playlist”: a local input list, a separate playback queue, and an HLS output playlist are different things.
Why changing the list may not change playback
A concat list is part of the input definition FFmpeg opens for a job. Once the process has started, the fact that the file on disk has changed does not establish that FFmpeg will revisit it and add new entries to its active schedule. The practical answer to “Can I add or replace entries in an FFmpeg concat playlist while it is running?” is therefore: not by relying on an undocumented reread.
This distinction matters most when your channel is expected to run overnight. You might save a new list correctly and see no error, yet the running process continues with the inputs it already has. A successful text-file edit is not proof of a playback change. Do not build a nightly operating procedure around a hot reload unless the specific software controlling playback documents and you have verified that behaviour.
First identify the process that owns the queue. It may be FFmpeg reading a concat file, a separate player feeding FFmpeg, or a broadcaster sending a finished programme. Those arrangements have different control points. The FFmpeg concat playlist guide is useful for understanding a file-based sequence, but a sequence that works at launch is not automatically a live-editable scheduler.
A file-based queue is suitable when the sequence is known in advance and a restart is acceptable. It is less suitable when you need to insert a late announcement, remove a clip after playback begins, or change a devotional programme in response to a schedule. For those cases, decide how the input will change before the channel goes live. A “we can edit the list if needed” plan is not enough.
Understand the concat input methods
FFmpeg’s FAQ describes three concatenation approaches: the concat filter, concat demuxer, and concat protocol. They solve related but different joining problems. None of those names should be read as a promise that a currently running process will monitor a local list file for changes.
The concat demuxer reads a text file describing the files to be joined. It can avoid re-encoding when the media is suitable for this kind of joining, including compatible stream parameters and timestamps. That can be attractive if you want to preserve the existing encodings, but compatibility is a real constraint. A list containing files with different codecs, dimensions, frame rates, audio layouts, or timing characteristics may not behave as one continuous programme without additional processing.
The concat filter is another route and is useful when the media needs to be decoded, combined, and encoded again. FFmpeg’s FAQ says this operation is recommended when re-encoding is needed. Re-encoding gives you a place to normalise sources, but it uses processing capacity and adds configuration choices. It still describes how inputs are joined; it does not make the text file a live queue editor.
The concat protocol is a lower-level option for compatible files that can be joined at the byte level. That is a narrower use case, not a general playlist manager. Before choosing any method, consider whether the job is to concatenate a fixed set of compatible assets or to select future sources while output continues.
| Approach | What it is for | What to expect when the list changes during a run |
|---|---|---|
| Concat demuxer | File-level joining where streams are suitable | Do not assume the active process rereads an edited list |
| Concat filter | Joining after decoding, often when re-encoding is needed | Useful for processing inputs, not a documented live scheduler |
| Concat protocol | Joining compatible files at a lower level | Not a general-purpose changing queue |
| Separate player or controller | Selecting the next source for a running output path | Behaviour depends on that system and must be tested |
The FFmpeg concat documentation helps with choosing a joining method. Read it for the media operation you need, then separately choose how a running channel will receive its next source. If you need a stable encoder connection while content changes, the controller or player—not a changed text file alone—must own that handoff.
For a broader comparison of fixed-file playback setups, see how FFmpeg and OBS differ for looping a playlist. The right choice depends on whether you value a simple, predetermined sequence or need an operator to intervene in the queue while the broadcast is live.
Keep input lists separate from HLS output playlists
The word “playlist” causes confusion here because HLS uses a playlist too. A local concat list tells FFmpeg what media to read as input. An HLS playlist is an output manifest that describes media segments produced for a receiver. They operate at different points in the chain, so changing one does not demonstrate that the other can be changed dynamically.
When FFmpeg is configured to create HLS output, it writes segments and updates an output playlist as part of packaging the stream. FFmpeg’s HLS muxer documentation describes output modes, including a VOD playlist mode. In that mode, the playlist is intended to be complete rather than modified as a live schedule. In neither case does the output manifest turn a local concat input file into a dynamic queue.
YouTube’s HLS ingest requirements are also distinct from the question of input selection. YouTube specifies TS segments, segment durations between 1 and 4 seconds, a rolling playlist with no more than five outstanding segments, HTTPS POST/PUT, and no encryption beyond HTTPS. YouTube also notes that HLS has higher latency than a continuous RTMP stream because it sends segments. These are requirements for an HLS ingest path, not a recipe for hot-editing an FFmpeg input list.
If your channel uses RTMP, do not apply HLS segment settings to it. If it uses HLS ingest, follow the current YouTube HLS ingestion guidance and verify your configuration against the official page before relying on it. The output protocol affects delivery and latency; the input controller determines how the next video is selected.
This distinction can prevent a long troubleshooting detour. If you see the HLS output playlist changing, that only tells you that the output packaging is updating. If you edit the concat file and see no change in content, inspect the input path and queue control rather than altering HLS segment settings. For guidance on a stream that remains online but stops advancing properly, use the separate checks in the guide to a YouTube live stream that freezes.
Use a controller for a changing queue
For a schedule that must change while the channel stays connected, use a controller or playback system designed to select sources during operation. Its job is to present the next media source to a still-running output path. The encoder continues sending one stream to YouTube while the upstream player changes what it supplies. This is a different architecture from asking a single FFmpeg invocation to watch a file list.
Before adopting a controller, establish which component encodes and which component selects files. If the controller itself reconnects to YouTube for every clip, it may not meet your requirement for a continuous broadcast connection. If it feeds a continuing encoder, confirm how it handles the boundary between sources, errors, and a clip that cannot be opened. The product documentation and a controlled test should answer these questions; the general FFmpeg concat documentation does not certify a particular controller.
Check the media that will cross the handoff. Compare video codec, resolution, frame rate, pixel format, audio codec and channel layout, and whether audio exists at all. Check timestamps and duration as well. If one clip has stereo audio and the next is silent, determine what the player and encoder will output at the boundary. If one source has a different frame rate or dimensions, decide whether to normalise it before playback or encode to a consistent output format.
These checks are not a guarantee of a gapless transition. Arbitrary source files can differ in ways that make a clean handoff difficult, and the cited documentation does not promise seamless transitions for every combination. A controller may pause, buffer, repeat a frame, or expose a brief audio change depending on its design and your media. Test the actual files and command rather than inferring behaviour from a sample that uses different assets.
A practical rehearsal is to run an unlisted or private test where your usual operator can observe the output. Queue a short clip, change the next item, then observe whether the encoder remains connected, whether the expected source starts, whether sound is present, and how YouTube reports the live session. Repeat with a file that has different but realistic properties from your normal assets. Record the exact configuration that worked so a night operator does not have to reconstruct it under pressure.
This approach is particularly useful for bhajan, study, and ambience channels where a fixed visual stream must continue while the programme changes. If you do not need live intervention, a prebuilt sequence and a controlled restart may be simpler. If you do need a rolling queue, budget time to validate the controller and source compatibility before making it responsible for an unattended schedule.
Plan a controlled restart when needed
A restart is often the honest fallback when your existing input path has no documented live handoff. It introduces an interruption or a new live session, so it may not satisfy a strict no-stop requirement. It is still safer than improvising an unsupported file edit during a broadcast and assuming viewers will see the change.
Prepare the replacement sequence first. Check file paths, spelling, permissions, media readability, and order. If the new list includes an announcement or a corrected version of a track, preview those exact assets. Keep a copy of the current working configuration so you can restore it if the new launch fails. Avoid changing several variables at once: a new playlist, different encoder flags, and an ingest protocol change make diagnosis harder.
Choose a low-impact window and tell anyone responsible for the channel what will happen. Make sure you can access the stream key and the relevant YouTube live control room details without exposing credentials in shared notes. Stop the existing job deliberately, confirm its state, then start the new one using the prepared configuration. Do not leave two independent broadcasters publishing to the same intended channel session unless your setup explicitly supports that arrangement.
After restart, verify the new output rather than treating a successful command launch as sufficient. Check the preview, programme audio, selected item, and whether the live session is receiving data. If the restart creates a new broadcast event instead of resuming the old one, make sure the channel’s public presentation and any scheduled links are understood by the people watching. The exact behaviour depends on how the event was created and configured.
For a 24/7 channel, the restart plan should be written down before it is needed. Include who is authorised to make the change, what to do if the new process exits, how to restore the previous queue, and where to look for the active status. If power loss is also a concern, a separate guide to restarting an FFmpeg stream after power loss covers a related recovery problem; automatic recovery after a crash is not the same as safely changing a live queue.
Check the stream after a source change
Treat every source handoff as a change that deserves observation. Start with the local process or player: confirm the expected source is now selected and that the encoder has not exited. Then check YouTube’s live preview or monitoring view for incoming picture and sound. A process can remain running while the media is frozen, silent, or showing the wrong clip, so process status alone is not a complete check.
Listen across the transition. Look for an audio gap, a sudden volume change, clipped opening syllables, or a silence that persists beyond the expected boundary. Watch for black frames, frozen images, aspect-ratio changes, or unexpected overlays. If your stream includes captions or other timed elements, check whether they remain aligned after the switch. These symptoms often point to source differences or transition handling rather than a playlist-file syntax problem.
Keep an operator’s note of what changed and when, without putting stream keys or other secrets in it. Note the source filenames, the controller action, any error message, and what YouTube showed. This makes it easier to distinguish a queue-selection issue from ingest trouble. If the stream is online but the picture stops advancing, use the freezing checklist rather than repeatedly editing the concat list.
Do not conclude that a handoff is reliable because one test worked. Test the source combinations you expect to use, including silent clips and unusually long files if those are part of your library. Confirm what happens after a file is missing or unreadable, and whether the controller advances, retries, or stops. Those behaviours are system-specific and should be known before the schedule is unattended.
If the actual priority is avoiding a computer staying powered overnight, a managed playback path can remove that operational burden; StreamNeo takes an uploaded video and runs it as a YouTube live stream without requiring your computer to remain on. It does not change the fact that FFmpeg itself has no documented guarantee to reread an edited concat list, and a changing multi-video schedule still needs a suitable playback plan.
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 add or replace entries in an FFmpeg concat playlist while it is running?
Do not rely on editing the file to alter the active queue. FFmpeg’s official material covers concatenation methods, but does not promise that a running process rereads an edited local list. Use a controller that manages the next source, or arrange a controlled restart.
Is an HLS playlist the same as an FFmpeg concat list?
No. The concat list describes input files, while an HLS playlist is an output manifest for segments. HLS output behaviour does not establish that FFmpeg will dynamically reload a local input queue.
Can I change videos without disconnecting the YouTube stream?
It may be possible with a playback controller that changes the input presented to one continuing encoder. Whether the handoff is clean depends on the controller, command, and media files, so test the actual source combinations before relying on it.
Should I use RTMP or HLS for a changing playlist?
That choice is about ingest and delivery, not queue control. YouTube says HLS has higher latency than continuous RTMP and defines specific HLS requirements; neither protocol makes a concat input list live-editable. Check YouTube’s current guidance for the ingest method you use.