For a prepared sequence of local video files, FFmpeg’s concat demuxer can present them to one FFmpeg process in order, ready to be encoded and sent to YouTube Live. That is different from changing the programme on demand while the stream is already running: do not assume an edited list will be picked up or that a live cutover will be continuous.
The dependable starting point is to prepare the sequence, check that its files are compatible, and test the complete output using your FFmpeg build and YouTube broadcast. If you need to choose a different source while live, treat that as a separate switching requirement and test it independently.
What switching means in a concat workflow
The word “switch” can describe two different jobs. In the first, you prepare an ordered list of files and FFmpeg plays them one after another as a single input. In the second, you or an operator chooses another programme or source while the broadcast is underway. The concat demuxer documents the first job; it does not establish the second as a reliable live-control feature.
For a devotional channel, a prepared list might contain a morning bhajan recording, a longer kirtan video and an evening prayer recording, in the order you want viewers to see them. FFmpeg reads those files sequentially. You can send the resulting audio and video to YouTube’s live ingest using the address and stream name for your broadcast.
This approach is useful when the sequence is known before you start and you can prepare compatible files in advance. It is not a control panel for moving to an unlisted video at a particular moment. If the sequence itself changes after the FFmpeg process has started, the documentation does not promise when—or whether—an edit to the script will affect playback.
Think of this as assembling one programme, not changing a television channel live. A prepared sequence can still be a poor fit if clips have different stream layouts or timing, or if the content needs frequent operator decisions. The FFmpeg playlist-order guide is useful if your immediate problem is arranging a fixed loop correctly.
Prepare compatible local video files
Start by deciding exactly which clips belong in the run and in what order. Put the list together before launching FFmpeg, then check that each path points to the intended file. Relative paths depend on the directory from which the process runs; absolute paths can be easier to reason about in a scheduled or unattended setup, provided those paths exist where FFmpeg runs.
The concat demuxer expects the files to have compatible streams, codecs and time bases. In practical terms, do not assume that two files will join cleanly merely because both have an MP4 extension or play in the same desktop player. One may have audio and video while another has only video; one may use a different codec or timing basis. Such differences can require preparation or a different workflow.
If you already have a set of similar exports from the same editing preset, compatibility may be straightforward. If the files come from different phones, editing apps or downloaded sources, inspect them rather than relying on their names or container extensions. You may need to re-encode or otherwise normalise them so their streams are consistent. Re-encoding takes time and can affect image or sound quality, so preserve originals and check the result before replacing a working sequence.
Also verify that each file contains the intended audio. A silent devotional video followed by a video with audio can create a confusing transition even if the video itself appears fine. For a local news loop, check that spoken audio does not overlap unexpectedly or begin at an unsuitable level. These are editorial checks as well as technical ones: a sequence that decodes is not necessarily a sequence that sounds right.
Write the concat demuxer file list
Create a plain-text script with one file line per video, in playback order. The following is an illustrative shape; replace the sample paths with paths that exist on the machine running FFmpeg:
ffconcat version 1.0
file '/media/morning-bhajan.mp4'
file '/media/evening-prayer.mp4'
The first line identifies the concat script format. Each following line names one input file. Preserve the order: the first listed clip plays first, followed by the next. Keep the script somewhere stable, and use a filename that makes it clear which programme sequence it represents. The FFmpeg concat demuxer documentation describes the script format and the sequential input behaviour.
Paths must follow the script’s syntax. A path containing spaces or special characters needs particular care; quote it as appropriate for the concat format, and test that FFmpeg can open it. Do not confuse the quoting rules for this file with shell quoting in the command that launches FFmpeg. They are different parsing stages. A quick test against the actual file list is safer than assuming a line copied from a shell command will work unchanged in the script.
Keep the list and files together in a way that survives a restart if this is intended to run unattended. If the media is moved, renamed or mounted from removable storage, the stored paths may stop resolving. A missing file can interrupt the intended programme, so check the working directory and file availability under the same account and launch method that will run the live process.
The script is a prepared input description, not a promise of dynamic playlist control. Create and validate the version you intend to use before starting. Do not build an operating plan around changing a line during a live broadcast unless you have separately reproduced the behaviour with your exact FFmpeg version and confirmed the result in YouTube Live Control Room.
Check streams, codecs, time base and duration
Before encoding, inspect every file and compare its streams. The relevant questions are whether each file has the expected audio and video streams, whether the codecs match, and whether the time bases are compatible for concatenation. FFmpeg’s documentation makes these compatibility conditions central to the concat demuxer workflow; it is not a general-purpose repair step for unlike media.
Duration metadata matters too. FFmpeg uses a file’s duration to place timestamps for the next file. If a duration is inaccurate, the hand-off can produce timestamp gaps or other artifacts. Those may appear as a pause, an abrupt transition, audio timing trouble or visible instability. Do not infer that a file is sound just because a media player can seek to its end; verify the encoded stream and the output sequence.
A practical review can be done in stages. First inspect the files individually and note their stream layout and technical properties. Then run the concat input locally without sending it to YouTube, and watch or listen through the boundaries between clips. Finally, test the encoded output settings you plan to use. If the transition is wrong at this stage, changing YouTube ingest settings is unlikely to correct the underlying file mismatch.
You can choose to normalise source clips in advance or configure a filter and encoding path that gives the output a consistent format. The right choice depends on whether the source material is already compatible, the processing capacity available, and whether another generation of encoding is acceptable. Do not copy a command from a different machine and assume it suits your files: options, build capabilities and output requirements can differ.
Record what you checked, including the file order and the version of the script. This is especially helpful when a channel has a weekly playlist or when one person prepares the media and another starts the broadcast. When something changes, you can identify whether the list, a source file or the encoding configuration was altered, rather than troubleshooting an undocumented mix of changes.
Send FFmpeg output to YouTube Live ingest
YouTube provides ingestion information for a live broadcast, including an ingest address and a stream name. Depending on the encoder, you may enter them separately or combine them in the form STREAM_URL/STREAM_NAME. Consult the YouTube LiveStreams API documentation for the relationship between the ingestion address and stream name, and use the current credentials for the broadcast you are setting up.
For RTMP-based ingest, use the RTMPS address supplied for the broadcast when that is the configured option. YouTube describes RTMPS as RTMP carried through SSL in its RTMPS ingestion guidance. Sending cleartext RTMP to an endpoint expecting RTMPS can result in a connection timeout, so check that the protocol and address agree.
Your FFmpeg command needs to read the concat input, apply any necessary encoding, and send the output to the assigned ingest destination. The exact options depend on whether the source streams can be copied or must be re-encoded, the audio and video present, your target output settings and YouTube’s current ingest configuration. The concat script alone does not define the full command.
Treat the stream key or stream name as a credential. Do not publish it in a tutorial, paste it into a public issue or leave it in a shared script where people who do not need it can read it. Use the value shown for your own broadcast rather than an example copied from someone else. If you use a script to launch FFmpeg, account for who can read that script and how you will replace credentials if needed.
Do not try to solve playlist changes by switching ingest protocols mid-broadcast. YouTube’s DASH ingestion guide says RTMP and DASH cannot be mixed during the same broadcast. HLS has its own playlist and segment requirements, and is not simply an alternative way to make local concat-list edits live; YouTube’s HLS setup guidance covers that separate ingest route.
Test the prepared sequence before going live
Test with the actual FFmpeg build and the actual files, not only with a short hand-made sample. Start by checking that the concat script opens and that the sequence runs to completion locally. Observe the beginning and every clip boundary. Listen for missing audio, abrupt changes in loudness or a gap, and watch for a frozen frame, black frame or timestamp disturbance.
If you intend to repeat the sequence, test the repeat as well as the first pass. FFmpeg has a -stream_loop option used in some looping examples, often alongside -re to pace file input at its intended rate. That is not a universal command recipe: the correct placement and surrounding options depend on the input and output path. Do not rely on a third-party example without validating it with your build and media.
Then test the full broadcast path in YouTube Live Control Room. Confirm that YouTube receives the expected audio and video, that the stream health view is acceptable, and that transitions remain correct after encoding and ingest. A local test can expose file and timestamp problems; the live control room test checks the part of the route that includes YouTube’s ingest and broadcast handling.
Make one change at a time if a test fails. For example, if a transition stalls, first establish whether the source files have matching stream properties and accurate duration information. Then check the FFmpeg output configuration and ingest connection. Changing several settings together can hide the cause and make a successful rerun difficult to reproduce.
Do not treat a brief successful test as proof of all-night reliability. For a channel that will run while you sleep, test a representative sequence long enough to include the transitions and repeat behaviour on which the programme depends. Confirm how you will notice a dropped process or a failed connection, and what action is needed to recover. A fixed playlist can be technically correct while the broader operation still needs monitoring and a restart plan.
Separate live source changes from a prepared list
If the requirement is “play these files in this order”, concat is the straightforward documented workflow. If the requirement is “let an operator choose the next video while viewers are watching”, that needs a separate control and switching design. The available concat documentation does not settle whether edits to an already-read script take effect, when they might take effect, or whether output remains continuous.
There are several practical distinctions to settle before choosing a method. Are all clips known before launch, or must new selections be recognised while the stream runs? Are the sources already compatible, or would they need re-encoding? Is a transition gap acceptable? Will the change happen inside one running process, or would it involve stopping and restarting a process? Each answer changes the testing burden and the likely viewer experience.
| Requirement | Prepared concat sequence | Operator-controlled live change |
|---|---|---|
| Clips known before launch | Fits the documented ordered-list workflow | May still work, but adds control requirements |
| New selection recognised while running | Not established by editing the list | Must be designed and tested explicitly |
| Compatible streams and timing | Required for the concat assumption | Depends on the switching method and source handling |
| Continuity at a change | Test boundaries in the prepared output | Do not assume a gap-free cutover |
| Ingest protocol | Use the broadcast’s configured ingest details | A protocol change is not a shortcut; RTMP and DASH cannot be mixed in one broadcast |
A separate switching design could involve an operator-controlled input or a process restart, but neither should be represented as seamless without testing. A restart can interrupt output; a different input arrangement can introduce its own format or timing issues. If continuity matters, test the exact change procedure in a controlled broadcast and inspect what viewers and YouTube’s control room actually receive.
Some channels do not need live choice at all. A study channel might schedule lectures in a prepared order, while a local news loop may need staff to replace an item at short notice. If the only need is a repeatable fixed programme, the guide to making a YouTube live stream repeat a video covers the related repeat use case. If your schedule is the main issue, see how to schedule a YouTube live playlist.
For a 24/7 channel, there is also a difference between a carefully prepared file sequence and the problem of keeping the broadcast process running when your own machine is off. StreamNeo addresses that specific computer-off requirement by taking an uploaded video and running it as a YouTube live stream, rather than asking your local computer to remain on for the broadcast.
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 video to the concat list while FFmpeg is streaming?
Do not rely on that behaviour. The concat demuxer documentation describes reading a file list as an input, but does not establish that changes made after the process starts will be picked up at a useful time. Test any proposed live-edit workflow with the exact FFmpeg build and verify the output in YouTube Live Control Room.
Do all the videos need to be in the same format?
The files need compatible streams, codecs and time bases for the concat demuxer’s assumptions to hold. Matching file extensions do not prove that they are compatible. Inspect the streams, duration information and transitions, and prepare or re-encode files if your tests show a mismatch.
Can I loop the prepared playlist continuously?
FFmpeg’s stream-loop option is used in looping examples, but a sample command is not automatically right for your sources and output. Test the initial playback, the repeat boundary and the complete YouTube ingest path before using it for a long-running channel. Keep a recovery plan for problems that a loop setting cannot prevent.
Can I switch from RTMP to DASH to change the playlist?
No. YouTube documents that RTMP and DASH ingestion cannot be mixed within the same broadcast, so a protocol change is not a playlist-switching method. Keep the configured ingest route consistent and design operator-controlled source changes as a separate workflow.