If you want to switch videos without disconnecting a live FFmpeg YouTube stream, keep the FFmpeg process and its YouTube output session running, and change the content earlier in the pipeline. For a playlist known in advance, use a concat filter graph; for runtime commands, ZeroMQ can control supported filters if your FFmpeg build includes libzmq.
That keeps your local encoder from being stopped just to change a clip. It does not guarantee uninterrupted network delivery or YouTube ingest: a connection can still fail, and YouTube may stop receiving the stream. The important distinction is between changing media inside a running pipeline and restarting the process that publishes to YouTube.
What “switching without disconnecting” means
A live encoder sends a continuous output to YouTube using an ingest address and stream key. If you stop FFmpeg to replace an input file and then start it again, you have stopped that encoder session. Keeping the same stream key does not turn two separate FFmpeg runs into one continuous output process. YouTube’s live encoder setup guidance describes starting the encoder by sending to the server URL with the stream key, and ending by stopping the content.
A switch inside a running FFmpeg graph is different. The output side can keep producing encoded audio and video while the graph changes which prepared segment contributes to that output. From YouTube’s perspective, the encoder is still sending its stream; from your perspective, a different clip has become the programme.
There are limits to that distinction. A graph can only act on inputs and filters it has been configured to handle. The concat filter can advance through a finite sequence already represented in the graph; it is not a general command to open any arbitrary new file at any time. ZeroMQ can send commands to filters in a running graph, but it does not make FFmpeg’s static input list dynamically extensible.
If you need to move between an existing playlist of devotional songs, lessons or shop promotions, plan the graph before going live. If you need an operator to choose entirely new sources at unpredictable times, a separate switching layer feeding a single FFmpeg output may be a better fit, at the cost of another system to configure and monitor. For a wider view of playlist approaches, see how a playlist file can feed a continuous YouTube stream.
Prepare a known sequence with the concat filter
FFmpeg’s concat filter joins corresponding audio and video streams from segments in order. That makes it useful when the clips are known before the broadcast begins. You build one graph containing the inputs and the segments, map the graph’s final audio and video outputs, and send those outputs through one encoder configuration to YouTube.
The requirements matter. Each segment must have the same number of streams of each type, and related audio and video should be concatenated together. Every segment must start at timestamp zero, and corresponding streams need compatible parameters. The filter can choose common pixel and sample formats, but you should explicitly normalise differences such as image dimensions. Frame-rate differences can also affect the result, including producing variable-frame-rate output. These are documented constraints, not optional polish; mismatches can make the graph fail or create an unexpected transition.
A conceptual two-clip layout might look like this:
ffmpeg -re -i clip1.mp4 -re -i clip2.mp4 \
-filter_complex "[0:v]scale=1920:1080,fps=30,setpts=PTS-STARTPTS[v0];[0:a]asetpts=PTS-STARTPTS[a0];[1:v]scale=1920:1080,fps=30,setpts=PTS-STARTPTS[v1];[1:a]asetpts=PTS-STARTPTS[a1];[v0][a0][v1][a1]concat=n=2:v=1:a=1[v][a]" \
-map "[v]" -map "[a]" \
-c:v libx264 -pix_fmt yuv420p -r 30 -g 60 -b:v 5M -maxrate 5M -bufsize 10M \
-c:a aac -b:a 128k -ar 44100 \
-f flv "$YOUTUBE_RTMP_URL/$YOUTUBE_STREAM_KEY"
Treat this as a layout to adapt, not a tested command to paste into a live session. Check your installed FFmpeg version and build, whether every input actually has audio, the timestamp behaviour, desired output size and frame rate, encoder choices, and your YouTube ingest configuration. The example also uses -re pacing, which needs to suit the inputs and setup; do not assume it is correct for every source or playlist.
The sample contains two segments, so it illustrates a finite graph rather than an open-ended playlist. With more clips, each segment needs suitable normalisation and a corresponding place in the filter graph. If one source is silent, has a different stream layout, or uses a different image size, decide how to handle that before the stream starts rather than discovering it at a transition.
The concat demuxer is another way to join prepared media in cases where formats allow it, especially when you do not need to re-encode. FFmpeg’s concat FAQ distinguishes that from the concat filter and protocol. A demuxer playlist is not, by itself, a runtime switch command. For a live encoded output that needs normalisation or other filter work, the filter is often the clearer place to plan the transition.
Advance between segments with the next command
The concat filter documents a next command: it closes the current segment and steps to the next one. In practical terms, that gives you a way to advance through the segments configured in your graph without stopping and recreating the FFmpeg output process. It is suited to a prepared sequence, not to inserting an arbitrary new command-line input after the process has started.
The command must reach the concat filter instance in the graph. FFmpeg’s filter command interface uses a target filter name, a command and, where needed, an argument. In a graph with several filters of the same type, assign and use a clear instance name so the command addresses the intended concat filter. Confirm the exact syntax and response against the installed FFmpeg version before relying on it during a broadcast.
The filter command needs a way to arrive while FFmpeg is running. One documented route is the ZeroMQ filter, described in the next section. If you build a controller or use a command interface, test not only that the command is accepted but that it advances the intended segment and leaves both audio and video progressing as expected. A successful command response alone is not proof that viewers saw a clean transition.
For a small station, a finite sequence can be easier to reason about than a complex live control setup. You can arrange the clips in the order you expect, test the transition points, and keep a written run sheet for the operator. If you have a recurring programme or event replay, planning a continuous stream around recorded sessions may help you decide whether a fixed playlist is enough or whether you need more flexible control.
Use ZeroMQ for runtime filter control when available
FFmpeg’s zmq filter receives messages from a ZeroMQ client and forwards them as commands to filters in the graph. The corresponding azmq filter applies the same idea in an audio filter chain. The FFmpeg filter documentation states that the video zmq filter requires a build configured with --enable-libzmq and is placed between video filters. It documents a local TCP bind address by default.
Do not assume the filter exists just because the ffmpeg executable runs. Check the build configuration or available filters on the actual machine you intend to use, and verify that the relevant filter and command support are present. A package installed on one computer may differ from a build on another. If libzmq is absent, the runtime method described here is unavailable until you use a suitable build or choose a different control architecture.
The boundary is important: ZeroMQ sends commands to filters that are already in the graph. It is not documented as a facility for adding arbitrary new input files to FFmpeg’s command-line input list at runtime. You can use it to send a supported next command to a configured concat filter, or adjust behaviour of a filter that accepts commands, but you still need to plan the graph and its sources.
Keep command access local or otherwise appropriately controlled. A command listener is an operational control point: accidental or unauthorised messages could alter what is being sent. Test the bind address, client connection and target filter name before you depend on the mechanism. Keep notes on how to return to the expected output if the control client disconnects or a command is rejected.
For truly open-ended source changes, a controller built around FFmpeg libraries or a separate switching/mixing layer can feed one continuous output process. That adds complexity: you must validate timestamps, audio continuity, source timing and output behaviour under your own conditions. It is an architectural option inferred from the limits of the documented filter-command interface, not a promise that a particular switcher will preserve every transition.
Keep content switching upstream of YouTube output
Picture the pipeline as source files, then filters and switching logic, then encoding and the YouTube output. The reliable design principle for this goal is to put the change before the one publishing output. Replacing a clip in the graph is an upstream content change. Stopping FFmpeg and starting a new command is a process restart at the publishing end.
This distinction also helps diagnose the right failure. If a clip does not advance, inspect the filter graph, command target and input compatibility. If FFmpeg exits, investigate the process and its logs. If FFmpeg is still sending but YouTube reports poor stream health, examine the connection and ingest conditions rather than assuming the concat switch caused a disconnect. A persistent local process reduces one avoidable interruption—the deliberate restart—but cannot control every link between your encoder and viewers.
YouTube’s current live encoder settings guidance lists supported ingest protocols and encoding recommendations. It recommends a two-second keyframe frequency and says not to exceed four seconds; it also recommends constant bit rate and lists AAC or MP3 audio, with video frame rates up to 60 fps. These are published recommendations, not a guarantee of uninterrupted delivery or a universal command line.
Choose settings that your upload connection can sustain and test them with the actual output. YouTube publishes example bitrates by resolution, frame rate and codec; check its current table rather than copying a value from an old command or another channel. The sample command above uses values only to show command structure and should not be treated as a current YouTube recommendation.
If you are comparing a local FFmpeg pipeline with a managed way to keep a file on air, focus on the specific operational burden. StreamNeo is useful when the problem is keeping a prepared file playing without leaving a computer running or maintaining a local FFmpeg process; it does not replace the need to prepare suitable content or check YouTube’s stream health. For a channel that needs programme labels, transitions and a recognisable schedule, making a continuous stream feel like a TV channel is a separate planning task from keeping its ingest connected.
Test transitions and understand interruption risks
Test with the exact clips and FFmpeg build you will use, but do it before relying on the stream for an overnight schedule. First confirm that every input opens and that the graph starts. Watch the transition from each segment, listen for a gap or overlap, and check that image size, frame rate and audio remain what you intended. Test the command path by advancing at a planned point, then confirm that the next segment actually becomes the output.
Watch both sides of the pipeline. FFmpeg logs can show a filter or encoding problem; YouTube’s live dashboard can show ingest status and stream health. Keep the encoder running through a test long enough to observe more than just the initial connection, and use YouTube’s own advice to test before going live and monitor messages during the event. A local success does not establish that your internet connection will remain stable overnight.
Plan for a failed transition. Keep a known-good output or a simple fallback sequence available, and decide who is responsible for noticing a black frame, frozen picture or silent audio. For a small channel, a fallback can be as simple as keeping one tested background video in the prepared sequence rather than depending on an operator to build a replacement graph under pressure.
Do not confuse a clean content transition with continuity at every other layer. Your local FFmpeg process may remain alive while the upload connection drops; YouTube ingest may have an issue even if the graph behaves correctly. Conversely, an encoder restart may reconnect successfully but still interrupt the event. No concat or ZeroMQ command can promise that the network or YouTube will never interrupt.
If you need to change sources beyond a prepared list, compare the cost of maintaining a separate switcher with the simplicity of restarting between programmes when an interruption is acceptable. A more flexible system is not automatically a better system if nobody can test or operate it. Keep the design matched to how often changes happen and whether they are scheduled or improvised.
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 a new video file to FFmpeg after the stream has started?
Not by sending the concat filter’s next command: that advances to the next segment already configured in the graph. FFmpeg’s documented ZeroMQ filter interface sends commands to filters in that graph; it is not documented as a general way to append arbitrary command-line inputs while running.
Does using the same YouTube stream key keep the stream connected?
The key identifies the stream destination, but it does not keep a stopped FFmpeg process alive. If you stop and relaunch FFmpeg, you have restarted the publishing process even if you reuse the key. Keeping one process running while changing content upstream avoids that deliberate restart, but cannot guarantee network or ingest continuity.
How can I tell whether my FFmpeg build supports ZeroMQ?
Check the actual executable’s build configuration and available filters, and verify that the build includes libzmq support. FFmpeg documents that its zmq filter requires --enable-libzmq; do not assume every packaged build has it. Test a command to the intended filter before you depend on it live.
Is concat the right choice for a 24/7 playlist?
It can suit a finite sequence prepared in advance, provided the streams and timestamps meet the filter’s requirements and you have tested the transitions. If you need to introduce arbitrary new sources while the stream runs, you will need a different control design, such as a switcher feeding one output, or accept a process restart when changing programmes.