To stream several MP4 files from a server in a chosen order, use FFmpeg as the encoder and give its concat demuxer a text file listing those paths in sequence. FFmpeg sends one continuous feed to YouTube Live; the playlist controls the media order, while YouTube Studio controls the event and when viewers can watch it.
Before relying on the feed, check that the files are readable and suitable for concatenation, test the transitions, and confirm the preview in YouTube’s Live Control Room. A list of paths does not make arbitrary MP4 files match, and it does not schedule a YouTube event.
Prepare the files and intended order
Start with the editorial decision, not the command line. Write down the exact order viewers should see: for example, an opening welcome, a sequence of devotional songs, then a closing card. Give the files unambiguous names or keep a separate run sheet, and make sure the order you intend is the order you later put in the playlist file. The concat demuxer reads entries in order; it does not infer a sequence from titles, creation dates or a YouTube playlist.
Place the MP4s where the server process can read them. Paths can be absolute, such as /srv/channel/opening.mp4, or relative to the working directory from which FFmpeg runs. Absolute paths are easier to reason about in a service or scheduled job, because a changed working directory will not silently point the process at a different folder. Check spelling, letter case and mount availability, especially if the files are on a separate disk.
Do not assume that two files with an .mp4 extension can be joined cleanly. They may have different resolutions, frame rates, video codecs, audio codecs, stream layouts or time bases. A practical FFmpeg playlist guide recommends matching resolution, frame rate, video codec and audio codec for a seamless concat workflow. That is useful operational advice, not a formal YouTube rule. Check the properties of every file with media inspection tools and, where possible, standardise mismatched sources before the live run.
A transition that looks acceptable in a local test can still expose a black frame, a sudden audio-level change or a long pause on air. Listen across the boundary as well as watching it. If you are preparing a long-running music or study stream, normalise the editorial plan and check that each source contains the intended audio and picture for its whole duration. FFmpeg will not repair missing content or make an unsuitable file broadcast-ready simply because it appears in a playlist.
Also check that the server has enough local storage for the files and that its network connection can sustain the outgoing feed. For background on the network side of a continuous stream, see this guide to calculating bandwidth for a continuous YouTube livestream. The relevant capacity depends on your chosen output settings and operating environment, so do not treat another channel’s figures as a guarantee for yours.
Create the concat-demuxer playlist
Create a plain-text file with one file entry per source, in the exact intended order. For example:
file '/srv/channel/01-opening.mp4'
file '/srv/channel/02-main.mp4'
file '/srv/channel/03-break.mp4'
Save it somewhere stable, such as /srv/channel/playlist.txt. The list is not a media playlist served to YouTube; it is an input description that FFmpeg reads locally. The first entry is read first, followed by the next entry, and so on. To change the order, edit the file and verify it again before starting the encoder.
The example assumes simple paths without embedded apostrophes. If a path contains special characters, spaces or quotes, follow the concat-demuxer syntax documented for the FFmpeg version installed on your server. Do not rely on shell quoting rules to fix the playlist format: the playlist is parsed by FFmpeg, not by your command shell. Keep the list in a predictable encoding and avoid adding explanatory text that the demuxer could interpret as an entry.
The concat demuxer is different from asking FFmpeg to join arbitrary files through a generic concat filter. It presents a sequence of inputs for demuxing under certain compatibility conditions. Exact behaviours and available options can vary by FFmpeg version, so check the installed version’s documentation before adopting a production command. The research available for this guide includes a practical third-party concat example, but not a retrieved official FFmpeg manual page; treat the command patterns here as a starting point and validate them against your deployment.
Keep an untouched copy of the list used for a broadcast. If someone later reports that a segment played in the wrong place, the saved file lets you distinguish a playlist-order mistake from a YouTube event or presentation problem. A simple run sheet with filenames and intended transitions can help a second person review it without needing to inspect the command itself.
Configure FFmpeg as the encoder
FFmpeg reads the concat list, encodes or passes through the media as configured, and sends the resulting stream to an ingest endpoint. A basic command shape is:
ffmpeg -re -f concat -safe 0 -i /srv/channel/playlist.txt \
-c:v libx264 -c:a aac -f flv \
'rtmp://INGEST-SERVER/APP/STREAM-KEY'
This is a template, not a universal production preset. -f concat tells FFmpeg to use the concat demuxer, -i names the playlist, and -re asks FFmpeg to read at native rate rather than racing through a file. The encoder options shown are common illustrative choices, but the right output parameters depend on the source files, your FFmpeg build and the ingest configuration. Confirm the syntax and supported encoders with the installed FFmpeg version before using it live.
The -safe 0 option is included because the sample uses absolute paths. It relaxes the demuxer’s path safety checks, so only use it with a playlist you control and have reviewed. A playlist file that an untrusted person can edit could point FFmpeg at unexpected local files. If your setup permits it, relative paths in a controlled directory may allow a more restrictive configuration.
You must decide whether to re-encode or copy streams. Re-encoding can produce a consistent output format when sources differ, but it uses CPU and may add complexity. Stream copying avoids video and audio re-encoding, but it does not make incompatible inputs compatible; transitions can fail or behave unexpectedly if the files differ. Test both the media sequence and the selected output settings with representative files before depending on the feed. For guidance on a longer FFmpeg-based server setup, see how to run a 24/7 YouTube stream on EC2 with FFmpeg and systemd.
YouTube accepts an encoder feed using the server URL and stream key shown in YouTube Studio. Keep the key private: anyone who obtains it may be able to send content to your stream configuration. Do not put a real key in a public article, shell history you share, screenshots, support tickets or logs. In an operational script, use an access-controlled configuration method rather than leaving the secret in a file other people can read.
For a channel that needs the computer switched off after setup, StreamNeo removes the need to keep this local FFmpeg process running on your own server: you upload the video, provide the YouTube stream key and the broadcast continues from the cloud with monitoring and automatic restart if it drops. It is YouTube-only, so this is relevant when the task is a prerecorded YouTube feed rather than a encoder workflow.
Send the feed to YouTube ingest
In YouTube Studio, create or select the relevant live stream setup and copy the server URL and stream key into the encoder configuration. The exact labels can change, so use the current values shown for the selected stream rather than copying an old endpoint from a tutorial. YouTube’s live streaming setup guidance describes entering the server URL and stream key in your encoder. Treat the key as a password, and regenerate or replace it through Studio if you believe it has been exposed.
The command template uses RTMP-family ingest because it is a straightforward match for an FFmpeg file sequence. YouTube also documents RTMPS, which carries RTMP through an SSL connection. Use the protocol and endpoint that YouTube shows for your stream and that your FFmpeg configuration supports. Do not simply replace rtmp with rtmps without checking the endpoint syntax and build support.
HLS is another YouTube ingest option, but it is not merely a different spelling of the same target. YouTube describes higher latency for HLS than its continuous RTMP feed, and HLS requires a rolling playlist with no more than five outstanding segments. It may suit particular codec or HDR requirements, but adds segmented-playlist considerations. The YouTube HLS ingest guidance and the RTMPS ingestion documentation are the places to check the current protocol requirements.
Once FFmpeg starts, read its output rather than assuming that an open process means a healthy broadcast. Look for input errors, missing streams, encoder failures and connection messages. Keep a way to stop and restart the process safely, but do not expose the stream key while capturing diagnostics. If the connection drops, identify whether the cause is local media, encoder configuration, network access or the YouTube ingest endpoint before restarting repeatedly.
Check the files and feed before air
Test the playlist from beginning to end if the sequence is short enough; for longer material, at minimum test each file and each transition in a representative run. Confirm that the opening image and sound are correct, that one file advances to the next without an unintended gap, and that the last entry behaves as intended. A playlist can end when it reaches its final input. If you expect continuous repetition, confirm how your chosen FFmpeg workflow will loop the sequence rather than assuming that concat automatically repeats it.
For long broadcasts, a failed source path can interrupt the intended sequence. Validate that all paths are accessible to the same account that will run FFmpeg, and that files are not being moved or replaced during playback. A file can work for an administrator in an interactive shell but fail under a service account with different permissions. Make the test use the same account and working setup as the actual run.
The YouTube preview is another separate check. Once the ingest feed arrives, confirm that picture and sound appear correctly in the Live Control Room before you ask viewers to join. Check stream health and watch enough of the preview to see a file boundary if the start point allows. A green or connected state is not a substitute for hearing the audio and seeing the actual image.
If the feed appears but the preview is black, silent or delayed, pause before going live. Recheck the selected input, output mapping, codecs and ingest URL. If the preview begins with a later file than expected, verify the playlist order and whether FFmpeg resumed from a prior process or was started with a different list. For an overview of the operational trade-offs of running a stream on a small server, see whether a $5 VPS can handle a 24/7 YouTube stream; a server’s nominal price alone does not establish that it can sustain your chosen workload.
Use event controls to go live
The encoder’s playlist and YouTube’s broadcast event are distinct controls. The playlist determines what the encoder sends and in what order. The event determines the viewer-facing live session, including its scheduled time and the moment it is made available to viewers. You can prepare an ordered media feed without having created a public event, and scheduling an event does not rearrange the files sent by FFmpeg.
For a scheduled broadcast, select or create the event in Studio, start the encoder feed and wait until the Live Control Room preview is present and looks right. Then use the event controls to start the broadcast when you are ready. YouTube’s live streaming help page gives the current workflow for previewing and starting a stream. Follow the controls displayed for the event rather than assuming that FFmpeg’s connection itself puts the event live.
This distinction matters if you plan multiple separate shows. A sequence of MP4s is one encoder feed; it does not create a calendar of distinct YouTube events, separate watch pages or independent notifications. YouTube’s API documentation models an ingest configuration as a liveStream and viewer-facing events as liveBroadcast resources. Its broadcasts and streams documentation explains their relationship, including the recurring-event pattern. Choose a single continuous show when that is what your audience needs; use separate event controls when each session should have its own scheduled identity and start/end handling.
When a show is finished, stop sending content and end the event with the documented Studio controls. YouTube Help says streams under 12 hours are automatically archived; do not assume that a longer continuous or looping playlist will become one complete archive on the strength of that guidance. If the recording matters, check YouTube’s current archive information and make a separate recording plan. The length of the file sequence does not itself decide the event’s controls or archive behaviour.
Decide how to operate the sequence
A server-side FFmpeg workflow suits you if you can maintain the files, inspect the process and respond when the feed needs attention. It gives direct control over the playlist and encoding, but the server, disk, network and process all become part of the operational checklist. If the channel is a small business demo loop, for example, someone should verify that a revised product clip appears in the intended slot before the next scheduled event.
A managed workflow may reduce the need to keep your own machine or process running, but it changes where you configure the sequence and what controls are available. Compare the required media handling, event model, monitoring and recovery process rather than assuming that one approach is best for every channel. If you want separate scheduled events, identify how each option handles event creation and start controls; a media playlist alone does not provide those features.
Before a long run, keep a short operational record: the playlist file used, the event selected, the start time, the first and last media items, and who can access the stream key. This is not a promise of uninterrupted operation; it gives you a factual starting point when you need to find why a file or event behaved differently from the plan. For a continuous stream, also plan how a person will notice a dropped feed or an unexpected transition, particularly overnight.
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
Does the concat playlist schedule my YouTube Live event?
No. It orders media sent by FFmpeg as one feed. Create or select the viewer-facing event in YouTube Studio and use its controls to schedule or start it.
Do all my MP4 files need to be identical?
They do not need to be byte-for-byte identical, but differences in resolution, frame rate, video codec or audio codec can create concat problems. Check the media and test the transitions; re-encoding or preparing compatible files may be needed.
Can I use the same playlist for separate scheduled events?
You can use a media sequence as the encoder input, but the sequence itself does not create separate YouTube events or watch pages. Manage each event in Studio and confirm how its ingest stream is associated with the event.
Will a long playlist become one complete YouTube archive?
Do not assume so. YouTube Help says streams under 12 hours are automatically archived, but that does not establish that a longer continuous feed will be preserved as one complete archive. Check the current official guidance and keep a separate recording plan if the archive matters.