If you need a YouTube stream to move through a known set of videos, prepare that sequence as a playlist and use FFmpeg’s concat demuxer only when the files have compatible stream characteristics. If you need to choose a different file while the broadcast is running, treat that as a switching-system design problem: FFmpeg’s documented input model does not provide a general command to hot-swap an already-open input.
The distinction matters because a fixed playlist can be tested before broadcast, while an operator switch has to change content without losing control of the output sent to YouTube. Decide which behaviour you need first, then test the complete path, including audio, timestamps and YouTube’s preview.
Choose between a prepared playlist and live control
A fixed playlist is the simpler case. You decide the order in advance, prepare one list of compatible files and let FFmpeg read them in sequence. This suits an overnight devotional rotation, a study channel’s block of lessons or a local business’s loop of product clips when nobody needs to interrupt the order.
Interactive switching is different. An operator may need to replace a clip because a news update has arrived, skip a track, or move to a different ambience scene. The system must accept that choice while keeping a valid video and audio feed going to the YouTube-facing output. Concatenating a prepared list does not, by itself, offer that control.
| Need | Better starting point | Main trade-off |
|---|---|---|
| Play a known sequence once | Concat demuxer with a prepared list | Low setup burden, but files must meet its compatibility requirements |
| Play a known sequence repeatedly | A tested playlist workflow with a deliberate repeat strategy | Repeat behaviour and boundary transitions need to be checked in the actual setup |
| Let an operator choose content during broadcast | Persistent producer or controllable switching/filter design | More setup and testing; switching behaviour depends on the implementation |
| Combine files with different media properties | Normalise files first or use a concat filter and re-encode | Additional preparation or encoding work, but a stable output profile is easier to manage |
If you are choosing between a scheduled prerecorded presentation and a live-style channel, the distinction in YouTube Premiere versus restreaming prerecorded content can help clarify whether you need a continuous encoder output at all. For a continuous channel, establish whether the order is fixed or operator-controlled before writing commands.
Why an open FFmpeg input is not a hot swap
FFmpeg reads inputs and processes them towards configured outputs. An -i argument identifies an input for that process; it is not a live selector that an operator can point at another pathname while the process continues. The FFmpeg command-line documentation describes how inputs and outputs are specified, but it does not document replacing an already-open input as a supported interactive hot-swap operation.
This is why editing a playlist text file while FFmpeg is already consuming it is not a safe assumption. The concat demuxer reads a file list as part of input handling. Its documentation does not promise that changing the list during a running session will alter the active sequence reliably. Make the list before starting, rather than treating it as a remote control.
Stopping the current process and starting another one with a different -i is possible as an operational choice, but it can interrupt the outgoing connection or cause a reconnect. The behaviour depends on the encoder process, network and YouTube event configuration. Do not plan an uninterrupted transition on the assumption that restarting is invisible.
It helps to picture the system in two parts. The upstream side selects and prepares the current content. The downstream side sends a stable audio/video output to YouTube. Interactive control belongs upstream of that output, not in an imagined file-replacement command at the input boundary.
Prepare a fixed playlist with concat
For files with matching stream characteristics, FFmpeg’s concat demuxer can read a prepared list sequentially as one input. This is appropriate when the sequence is known and each item presents the expected streams, codecs and time bases. Consult the FFmpeg concat documentation for the list format and the demuxer’s conditions; do not assume any arbitrary group of MP4 or MOV files will work together without preparation.
Build the list as part of pre-broadcast work. Confirm the order, paths and filenames, and keep a copy of the exact list used for the stream. Check that the files are available in the environment where FFmpeg will run. A path that works on a desktop may not exist on a remote machine, and a renamed file can make a sequence stop before it reaches the next item.
Duration information also matters. With the concat demuxer, later timestamps are based on the preceding file’s duration. If the duration is inaccurate, the transition can contain a timestamp gap or other artefact. Verify durations and test each boundary, rather than judging the playlist only by watching the first few minutes.
The demuxer is not the only concatenation path. FFmpeg’s FAQ describes the concat filter as the approach designed for concatenation when re-encoding is needed. A filter graph can bring inputs into a common output profile, but it requires more planning than a compatible demuxer list. Neither method removes the need to verify the result in the intended live configuration.
For a rotating channel, decide what should happen at the end of the list before the broadcast. A sequence that ends is not the same as a loop that continues indefinitely. Test the chosen repeat arrangement and observe the transition from the final item back to the first. If you need a more elaborate schedule across channels or time slots, the workflow in rotating playlists across several YouTube channels with a cloud scheduler addresses scheduling as a separate problem from FFmpeg’s input handling.
Check matching stream characteristics
The concat demuxer has strict expectations. FFmpeg says the files need the same streams, codecs and time bases. A set of clips that look similar in a media player may still differ in properties that matter to the demuxer, such as stream layout or encoding details.
Before making a list, inspect every file. Record the video and audio streams present, codec, time base, dimensions, frame rate and audio layout. Check whether every item contains audio: a silent clip mixed with files containing stereo audio can create an unexpected change unless the workflow explicitly handles it. Also look at aspect ratio, because a change from a wide clip to a portrait source can produce an awkward result even if an output can be made technically valid.
If the properties differ, do not assume the demuxer will reconcile them. One practical route is to normalise each source ahead of time to a common specification. Another is a concat-filter graph that re-encodes to a deliberately chosen output profile. The filter route is useful when re-encoding is acceptable; it still requires you to specify the desired dimensions, frame rate, pixel format, audio presence and layout.
A 2024 FFmpeg-user discussion notes that the demuxer is not suited to arbitrary differences in codec, stream layout, resolution and aspect ratio, and suggests transcoding to common properties. Treat this as practitioner guidance rather than a formal guarantee. The official demuxer requirements remain the more important check: inspect the media and test the exact files you plan to use.
Normalisation should be consistent across the whole set. If one clip is converted to a different frame rate or audio layout from the others, you may simply move the mismatch to another property. Save the prepared versions separately from originals, label them clearly and retain enough information to identify the source. That makes it easier to correct a bad conversion without losing the unmodified file.
Design for interactive switching
For operator-controlled changes, keep the YouTube-facing output session running and make the selection happen before the output. A persistent producer or controllable filter design can supply whichever content is selected while maintaining a consistent outgoing profile. This is architectural guidance based on FFmpeg’s input-to-output processing model, not a universal command supplied by its documentation.
The design has two responsibilities. First, it needs a reliable way to change the upstream content: an operator control, a producer that accepts commands, or another mechanism appropriate to the chosen setup. Second, it needs to keep presenting valid video and audio while that change occurs. Decide what the viewer should see between sources. A brief cut, a holding image or a fade are different behaviours and should be implemented and tested deliberately.
Keep the output characteristics stable even when incoming files vary. Establish the target dimensions, frame rate, pixel format and audio layout before building the switching path. If the inputs are heterogeneous, convert or filter them so that each selection reaches the output in the expected form. The switcher’s behaviour depends on how it handles each input; compatibility cannot be inferred just from the fact that one clip played successfully.
There is a trade-off between convenience and complexity. A persistent switching design can give an operator control without rebuilding the whole broadcast for every selection, but it needs more careful implementation and rehearsal. If the simplest available method restarts FFmpeg, accept that a reconnect may occur and validate the result in the same kind of YouTube event you will use. Do not promise viewers an uninterrupted change until your actual setup has demonstrated it under realistic conditions.
A channel that only needs to choose among files occasionally may not need elaborate live control. You can instead prepare a longer sequence with known transitions and avoid operator action overnight. For guidance focused on the broader playlist workflow, see scheduling a YouTube 24/7 playlist with OBS and VLC. That approach is useful when its tools and operating model suit you; it does not turn a running FFmpeg input into a hot-swappable source.
Keep the outgoing stream alive during changes
The transition is only one part of the problem. YouTube must continue receiving a valid encoder output, and you need to know whether the change affected video, audio or connection health. A plan that changes the picture but unexpectedly drops audio is not a successful switch.
Use YouTube’s current live encoder settings for the protocol and output settings appropriate to your stream. YouTube recommends RTMPS, lists H.264, HEVC and AV1 video encoding, AAC or MP3 audio, CBR and a recommended two-second keyframe interval that should not exceed four seconds. Its bitrate guidance depends on resolution and frame rate; use the current table rather than copying a value from an unrelated setup. For example, the cited guidance gives 5 Mbps for H.264 at 1080p30 and 14 Mbps for H.264 at 1080p60. Those apply to those specific rows, not every stream.
Keep the stream key private. YouTube describes it as equivalent to the stream’s password and address in its stream settings guidance. Do not place it in a public script, screenshot or log. If you think it has been exposed, use the current Live Control Room process to reset it.
Before a real broadcast, test representative movement and audio, then perform several transitions. Watch the YouTube preview and stream health while you switch; a local preview alone does not prove that YouTube is receiving the intended result. Check for frozen frames, a black interval, timestamp discontinuities, missing audio, clipping or a reconnect. YouTube recommends testing before an event and monitoring stream health during it.
For an always-on channel, consider what should happen if the operator is unavailable or the input fails. A fixed sequence may be more dependable for unattended hours precisely because it removes a decision point. A control design can still be right when news, music or business content needs active selection, but define a fallback source and rehearse returning to it. If your concern is continuity over a long devotional broadcast, the checks in keeping a 24/7 devotional YouTube stream running past 12 hours are relevant to the wider operating routine.
The practical rule is to change the upstream content while keeping the downstream output predictable. If you cannot verify that behaviour in your own FFmpeg build, file set, network and YouTube event, choose a prepared playlist or plan for a reconnect rather than relying on an untested live switch.
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 change the file after FFmpeg has started?
Not by changing the existing -i input as though it were a live selector. FFmpeg’s cited documentation does not describe an interactive hot-swap operation for an already-open input. Use a prepared sequence for automatic advancement, or design a persistent upstream switching method and test it.
Can I edit the concat list while the stream is live?
Do not rely on that to change what the running session will play. The concat demuxer is documented for sequential reading of a list, not as a live playlist control surface. Prepare the list in advance and test the full sequence, including boundaries and end behaviour.
What if my videos have different resolutions or codecs?
The concat demuxer requires matching stream characteristics, including streams, codecs and time bases, so arbitrary differences should not be assumed to work. Normalise the sources to common properties or use a concat filter when re-encoding is acceptable. Test the resulting output profile before sending it live.
Will restarting FFmpeg keep the YouTube broadcast uninterrupted?
There is no general guarantee: restarting can cause a reconnect, and the outcome depends on the implementation and event configuration. Test the exact process with YouTube’s preview and health indicators before relying on it. If uninterrupted output is essential, keep the output session alive and switch content upstream using a tested design.