A running FFmpeg process should not be expected to notice new entries appended to a concat script. If you need to add videos after a YouTube stream has started, treat that as a queue-and-handoff design problem, not a live-reload feature of the concat demuxer.
When every video is known in advance, prepare a concat list before starting FFmpeg. When videos may arrive later, an external controller can select the next file while an output process continues writing to the same destination, but that architecture must be tested with your files, FFmpeg build and destination; it does not guarantee a gap-free transition.
What a concat playlist tells FFmpeg
FFmpeg's concat demuxer reads a script that names files and presents their packets as though the files had been joined in sequence. In the usual simple form, the script is a text file with one file directive per input, for example:
file '/media/morning.mp4'
file '/media/noon.mp4'
file '/media/evening.mp4'
You pass the script to FFmpeg as an input, then direct the output to the streaming URL. The exact command depends on whether you are copying compatible streams or decoding and encoding them, among other settings. The important point for playlist behaviour is that the script is an input description for a process being started; the documentation does not define it as a watched queue that is continuously refreshed.
The files also need to suit concat's expectations. The demuxer is intended for files with matching streams, codecs and time bases. A list of videos that look similar to a viewer may still contain different stream layouts or timing. If they differ, stream-copy concatenation may not be suitable; you may need a path that decodes and normalises the inputs instead. FFmpeg's concat demuxer documentation describes the format and its constraints.
This distinction matters for a 24/7 devotional, study or ambience channel. The list determines what the process reads in sequence, while the output URL determines where FFmpeg sends the resulting stream. They are related parts of one command, but changing a source-list file is not the same operation as changing the output session.
Why appending a line may do nothing
A common assumption is that if a concat script is a text file, adding another file line should extend the current playlist. The official concat documentation does not promise that a running demuxer checks that script again or reloads edits. The safe operational rule is therefore: do not assume that appending a line will add a video to a stream already in progress.
What happens in a particular setup can depend on when the process reads input, how the file is handled and the installed FFmpeg version. That uncertainty is not a basis for a dependable overnight workflow. If the process has already read or otherwise established what it will consume, an edit on disk may simply sit there until a later run. Restarting FFmpeg after editing might make the change visible on the next run, but it is not the same as adding a file without restarting.
There is a second source of confusion: HLS also uses a playlist file. FFmpeg's HLS append_list option concerns the output playlist of media segments. It appends newly created segments to an existing HLS segment playlist and removes #EXT-X-ENDLIST; it does not add a new local source video to an RTMP input queue. See the HLS muxer options for that separate use. If you mean YouTube ingest rather than HLS segment delivery, keep those two playlist jobs distinct.
Use concat when the full list is ready
If tomorrow's programmes are already selected, concat is a straightforward way to express their order. Make the list before launching FFmpeg, check each path and ordering, and then start the output process. For example, a small channel could prepare a morning prayer recording, a sequence of bhajans and an evening programme in a single list. If the files meet concat's compatibility requirements, FFmpeg reads them in the planned order.
Before starting, check more than filenames. Confirm that the files exist, that the ordering is intentional, and that their streams are compatible for the method you chose. If an item differs in codec, stream layout or time base, decide whether to normalise it rather than hoping stream copy reconciles it. The general FFmpeg command-line documentation explains the input and output model; match options to the version installed on the machine that will run the stream.
A prebuilt list also gives you a useful rehearsal. Run through it locally or in a non-public test destination and watch for timestamp jumps, missing audio or unexpected pauses at boundaries. Inaccurate duration information can contribute to timestamp gaps or artefacts. A successful test is evidence for that file set and configuration, not proof that every future file will behave the same way.
For a channel that plays a stable weekly order, this simpler method may be all you need. The weekly bhajan playlist rotation guide is relevant when the scheduling problem is choosing a planned rotation rather than accepting files during a live session. A preplanned rotation and a dynamically growing list are different requirements; choose the less complex one if the order can be fixed in advance.
Design a queue or controller for later additions
If new videos arrive while the stream is already running, put a queue or playlist manager outside the concat script in charge of what plays next. The controller can maintain a list of approved files, select an item when the current one ends, and arrange for FFmpeg to read that next input. This is an architectural pattern inferred from FFmpeg's input/output model, not a documented concat feature or a tested, universal command recipe.
In practice, the controller needs rules as well as a list. Decide how a new item is validated, whether it goes next or joins the end, what happens if a file is missing or corrupt, and whether a repeated item is allowed. For a local news loop, for example, you might want a new bulletin to join the queue after the current segment rather than interrupting it. A devotional channel may prefer to finish the current bhajan before moving to newly added material. Those are editorial choices that the software should implement explicitly.
The controller also needs an input handoff strategy. It might supervise separate FFmpeg input jobs, or use another mechanism to feed one continuing output process. Each approach has different behaviour at the boundary, and this article does not claim one particular method is seamless. Before choosing an implementation, establish whether you can run a wrapper that launches or controls FFmpeg, whether the media share compatible properties, and whether a brief gap at a handoff is acceptable.
You will also need a recovery policy. If the next item cannot be opened, should the controller retry, skip it, or play a known fallback? If the output process exits, who detects that and decides whether to relaunch it? Keeping these decisions separate from the media list makes failures easier to understand than a collection of manual edits while the stream is live.
For a longer-running channel, consider the whole operating environment too: a stable network and a process that can recover matter alongside playlist logic. The JioFiber continuous-stream guide discusses the connection side, while the Ubuntu server walkthrough is useful if you are planning to keep a stream process running away from your desktop. Neither changes concat's behaviour; they address separate parts of the operating job.
Keep the output session alive across input handoffs
FFmpeg's basic model has inputs introduced with -i and an output URL that receives the result. RTMP is among the protocols FFmpeg supports; see the protocol documentation. For a queue-based design, the intended architecture is to keep writing to the same configured output endpoint while the controller supplies successive video inputs. That is the goal to test, not a guarantee that changing inputs leaves the stream visibly uninterrupted.
A handoff is not merely changing a filename. The incoming media may differ in dimensions, audio presence, frame rate, codec or timestamps. Even when two videos play normally on their own, a transition may reveal a mismatch. A normalising or transcoding path can give the output a consistent format, but it adds processing work and introduces its own settings to validate. Stream copy can be lighter where inputs are compatible, but it does not transform dissimilar sources into matching ones.
The output path can fail independently of the playlist. A queue may be healthy while the destination connection drops, or the output process may be alive while its next input is unavailable. Record enough status to distinguish those cases: current item, handoff time, FFmpeg exit or error, and whether output remains connected. The point is not to collect logs for their own sake; it is to know whether a blank interval came from the source, the controller or the delivery path.
If the current machine cannot be left on, that is another operational requirement, not something concat solves. StreamNeo is relevant to the specific burden of keeping a computer powered and a broadcast process supervised: it lets you upload a video, provide your YouTube stream key and leave the computer off while the broadcast runs. It does not turn a concat script into a live queue, and it is YouTube-only, so a queue design still needs to be considered separately.
Test the complete handoff, not just the playlist
Start with a private or otherwise controlled test appropriate to your channel, and use the same FFmpeg build and destination type intended for the real stream. Online FFmpeg documentation changes as the project evolves, so check the documentation corresponding to your installed version where possible. Do not infer YouTube-specific ingest limits, reconnect behaviour or session guarantees from the concat documentation.
Test a short sequence that includes a normal file boundary and at least one realistic new-item arrival. Confirm that the controller notices the queued item, that the outgoing process continues as intended, and that the destination receives usable video and audio. Look at the transition itself, not only at whether FFmpeg prints a success message. Check for a moment of silence, frozen picture, timestamp discontinuity or the output session dropping and returning.
Repeat with files representative of the library: different durations, audio characteristics and encodings if those occur in your real material. If the workflow rejects incompatible items, verify that the rejection is understandable and does not leave the queue stuck. If it normalises them, check that the output remains within the settings you intend to use. Keep a known-good fallback item available if a failed input would otherwise leave the channel with nothing to play.
A test should end with a written operating decision. If brief transition gaps are acceptable, state that plainly and tell whoever updates the queue what to expect. If they are not acceptable, do not label the design seamless until repeated tests support that wording under the exact conditions you will operate. The FFmpeg reconnect troubleshooting guide concerns output recovery rather than playlist reload, but it can help you keep those failure modes separate.
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 line while FFmpeg is streaming?
You can edit the text file, but the concat documentation does not promise that a running process will reload it. Do not rely on the edit to add the file to the active session. Prepare the complete list before startup, or use a separately designed and tested queue/controller for later arrivals.
Does HLS append_list add videos to a YouTube RTMP stream?
No. That option applies to an HLS output segment playlist, not to a list of local source videos being sent to an RTMP destination. HLS playlist management and a live input queue solve different problems.
Can a queue/controller guarantee no interruption?
No such guarantee follows from the concat documentation or from the architecture described here. Handoffs depend on the controller, input compatibility, FFmpeg version and destination behaviour, so test the exact setup and describe any observed gaps honestly.
Should I use concat or a queue?
Use a prepared concat list when the full sequence is known before FFmpeg starts and the files meet its compatibility requirements. Consider a queue/controller when items may arrive later and you can build and test the extra handoff and failure handling. If you only need a new sequence on the next run, updating the prebuilt list and restarting at a planned time is simpler than live handoff logic.