If you want several local video files to appear as one YouTube Live broadcast, FFmpeg can read them from a plain-text concat playlist and send the result through one command invocation. The important choice is whether the files are compatible enough for stream copying or need to be decoded and re-encoded into a common format.
The command below is a template, not tested universal advice. File codecs, time bases, frame sizes, FFmpeg builds, YouTube settings and available upload bandwidth all affect whether a particular command works reliably.
Prepare and order the video files
Start by putting the files you want to broadcast in a known location and decide their order before touching FFmpeg. A local folder with short, simple filenames makes the playlist easier to inspect and reduces mistakes caused by spaces, unusual punctuation or inconsistent paths.
For example, you might have three recorded devotional videos:
clip-01.mp4
clip-02.mp4
clip-03.mp4
The order in the playlist is the order FFmpeg will attempt to send them. FFmpeg does not choose files by filename unless you arrange the list that way, and it does not automatically find every video in a folder when using the concat demuxer.
Check each file before building the broadcast. Note its container, video codec, audio codec, resolution, frame rate, audio sample rate and whether it contains the same number and type of streams as the other files. You can inspect this with FFmpeg tools such as ffprobe, or by checking the media details in the player or editor you already use.
The closer the files are to one another, the more realistic a stream-copy workflow becomes. Three MP4 files with the same H.264 video settings, AAC audio settings, resolution, frame rate and stream layout are a different case from a mixture of vertical phone footage, screen recordings and music videos.
Also check the stored duration of every file. The concat demuxer uses duration information to advance timestamps between inputs. If a file has inaccurate or missing duration metadata, the transition can contain a timing gap, an overlap or other artefact even when the visible media appears normal.
If your aim is a repeating station rather than a single run, decide that now. A single pass ends when the final listed file ends. For a devotional, music or study channel, the distinction matters because a playlist that reaches its final file can leave the encoder stopped rather than continuing overnight. The reason a 24/7 study stream stops when its playlist ends is usually this basic difference between a finite input and a deliberately repeating one.
Create a plain-text concat playlist
Create a UTF-8 plain-text file named something such as playlist.txt. Put one file directive on each line:
file 'clip-01.mp4'
file 'clip-02.mp4'
file 'clip-03.mp4'
The paths are interpreted from the location where the command runs, unless you use absolute paths. Relative paths are usually easier to move between a test folder and a production folder. If a filename contains an apostrophe, quote or escape it according to the concat demuxer syntax rather than assuming ordinary shell quoting will solve it.
You can also use full paths, for example:
file '/home/channel/videos/clip-01.mp4'
file '/home/channel/videos/clip-02.mp4'
On Windows, use the path form accepted by your FFmpeg build and shell. Test the playlist locally before pointing it at a public broadcast. This catches a missing file or malformed line without involving YouTube.
The -f concat option tells FFmpeg to use the concat demuxer, which joins inputs at the packet level. That is not the same as the concat filter. The demuxer can be efficient and may allow stream copying, but it expects the listed files to have matching stream characteristics. The filter works after decoding and is suited to a different class of workflow, generally followed by re-encoding.
The -safe 0 option is often included when the playlist contains paths that the concat demuxer would otherwise reject under its safe-path policy. It does not make unknown files safe. Keep the playlist and all referenced paths local and trusted, particularly when a playlist is generated by another application.
If you are creating a long music or ambience channel, review the transitions as well as the list syntax. A technically valid playlist can still produce an abrupt change in loudness, an unwanted silent section or a visible jump between differently framed sources. A rotating Indian music playlist workflow can help you think about ordering and repetition, but the FFmpeg compatibility checks still apply.
Choose stream copy or re-encoding
There are two practical routes. Stream copy uses -c copy or equivalent per-stream copy settings, so FFmpeg does not decode and encode the media again. Re-encoding decodes the inputs and creates one common output profile for YouTube.
| Approach | Best fit | Main benefit | Main constraint |
|---|---|---|---|
| Concat demuxer with stream copy | Files with matching codecs, time bases, dimensions, rates and stream layout | Avoids another encode and reduces processing load | Strict compatibility requirements and less control over inconsistent inputs |
| Concat demuxer with output re-encoding | Files that are close enough for the demuxer but need a common output | Produces a defined video and audio format for ingest | Uses CPU or GPU time and adds an encode step |
| Concat filter with re-encoding | Inputs with differing layouts or parameters | Lets you normalise and join decoded streams | More complex command and more processing |
The FFmpeg concat documentation states that all files must have the same streams, including the same codecs and time base. In practice, also compare resolution, pixel format, frame rate, audio channel layout and stream order. A different file extension does not by itself prove incompatibility, and the same extension does not prove compatibility.
A stream-copy test may look like this fragment:
-c copy
Do not treat that fragment as a guarantee that the playlist will work. If one file is 1920×1080 H.264 with AAC stereo and the next is 1280×720 HEVC with a different audio layout, copying packets into one continuous output is not the right shortcut. You may see an error, a broken transition or output that YouTube cannot use as expected.
Re-encoding is usually the more forgiving choice when the inputs are inconsistent. It lets you select one output resolution, frame rate, video codec, audio codec, bitrate and keyframe pattern. The trade-off is processing load and an additional generation loss. If the computer cannot encode in real time, FFmpeg may fall behind the input and the live broadcast will not be stable.
A concat filter workflow may be appropriate when files differ in ways the demuxer cannot reconcile. It requires a more detailed filter graph to scale, format and align each input, so it is outside the simple one-list pattern in this guide. Test that workflow separately rather than quietly assuming that -f concat will normalise every source.
Configure YouTube ingest details
In YouTube Studio, create or select the live stream in the Live Control Room. Copy the current stream URL and stream key shown for the encoder destination. You will use those values at the end of the FFmpeg command.
Treat the stream key as a credential. Do not publish it in a tutorial screenshot, paste it into a public issue or commit it to a script that others can access. If it is exposed, replace or reset it in YouTube Studio before broadcasting again.
YouTube’s encoder setup guidance describes the general sequence: configure the encoder, wait for the incoming preview and stream-health information, then select Go live in the control room. When finished, stop sending from FFmpeg and end the broadcast in YouTube Studio.
For standard live ingest, YouTube recommends RTMPS. The server address supplied in YouTube Studio may therefore begin with an RTMPS scheme, and you should use the exact current value rather than substituting a URL copied from an old guide.
YouTube’s live encoder settings list H.264, H.265 and AV1 video support, up to 60 frames per second, and AAC or MP3 audio for the relevant ingest workflows. The exact choices depend on the protocol and the output you select, so check the current official page before settling on a profile.
The page recommends a two-second keyframe frequency and says it should not exceed four seconds. For H.264, it lists 14 Mbps as the recommended video bitrate for 1080p30 and 8 Mbps for 720p30. Those are examples for specific output conditions, not a rule that every source should use 8 Mbps. Your resolution, frame rate, codec and upload capacity must agree.
For stereo audio, YouTube recommends 44.1 kHz and 128 kbps in its encoder settings. A source with unusual audio settings can be re-encoded to those values, but confirm the current documentation and your chosen output profile before relying on a template.
Adapt the illustrative FFmpeg command
Here is an illustrative re-encoding template based on the concat playlist pattern:
ffmpeg -re -f concat -safe 0 -i playlist.txt -c:v libx264 -preset veryfast -b:v 8M -maxrate 8M -bufsize 16M -g 60 -c:a aac -b:a 128k -f flv 'rtmps://SERVER/STREAM_KEY'
This is a template, not a tested universal command. Replace SERVER/STREAM_KEY with the server URL and stream key shown in YouTube Studio. Never copy the example literally with a real key left in a public script or article.
The options have specific jobs. -re asks FFmpeg to read the input at approximately its native playback rate instead of consuming a file as quickly as the machine can process it. -f concat selects the concat demuxer, -safe 0 relaxes its safe-path check, and -i playlist.txt supplies the list.
-c:v libx264 selects H.264 video encoding and -c:a aac selects AAC audio encoding. The -preset veryfast value is an encoder-speed choice, not a promise about quality or real-time performance. A slower preset can require more processing, while a faster one can change compression efficiency. Test with the actual computer and media.
The example uses an 8 Mbps video target, an 8 Mbps maximum rate and a 16 Mbps buffer value. That 8 Mbps example aligns with YouTube’s listed H.264 recommendation for 720p30, but it is not appropriate for every resolution or frame rate. Set the output dimensions and frame rate explicitly when your sources are not already consistent, and make sure your upload connection has headroom above the sustained stream rate.
The -g 60 example represents a two-second GOP only when the output is 30 fps. If the output is 25, 50 or 60 fps, adjust the GOP length so it is roughly twice the output frame rate when targeting a two-second keyframe interval. The setting must be considered alongside the actual frame rate produced by the command, not copied independently.
The template does not explicitly set every output property. Depending on the inputs and FFmpeg build, the output may inherit or select values you did not intend. If your files have mixed dimensions, frame rates or pixel formats, add the necessary scaling, frame-rate and format controls, or move to a concat-filter workflow. Do not assume that a successful process start proves that every transition will be correct.
If all clips have matching streams and time bases, test a copy variant by replacing the codec settings with -c copy. Copying avoids the encode cost, but it retains the source characteristics and leaves less room to correct inconsistent inputs. A controlled local test should include every type of transition that will appear in the final playlist.
Repeat a playlist for a longer broadcast
The basic command plays the listed files once. To ask FFmpeg to loop the concat input, a pattern may place -stream_loop -1 before that input:
ffmpeg -stream_loop -1 -re -f concat -safe 0 -i playlist.txt -c:v libx264 -preset veryfast -b:v 8M -maxrate 8M -bufsize 16M -g 60 -c:a aac -b:a 128k -f flv 'rtmps://SERVER/STREAM_KEY'
This is still an illustrative pattern, not a guarantee of seamless repeat transitions. Confirm that the installed FFmpeg build accepts the option in this arrangement, then watch what happens when the final file returns to the first file. Stored duration errors, incompatible streams and different timestamp behaviour can become more noticeable after repetition.
A repeating broadcast should be tested for longer than a single file transition. Check the end of the list, the beginning after the loop, audio continuity and whether the process remains at real-time speed. If your playlist changes, create and test the replacement list before using it for a public channel.
A finite event and an always-on channel also have different stopping expectations. YouTube says streams under 12 hours are automatically archived, but that does not mean a process running indefinitely will remain one archive or that the broadcast will continue without intervention. Check the current YouTube documentation and choose an operating plan that matches the duration you actually need.
Start and monitor the broadcast
Run a private, unlisted or otherwise controlled test before a public event. Watch the FFmpeg terminal for input errors, encoder speed, timestamp warnings and messages showing that the process has reached each file. At the same time, watch the YouTube preview and stream-health panel.
If the preview does not appear, first check that the command is using the current server URL and stream key. Then inspect whether FFmpeg is still running, whether it can read the playlist, whether the output is being produced in real time and whether the upload connection is sustaining the selected rate.
If playback stops at the first file, inspect the playlist syntax and path resolution. If it stops at a transition, compare the stream parameters and stored durations of the two files on either side. If timestamps jump or the picture breaks, do not assume that increasing the bitrate will fix it; compatibility and duration metadata are more likely starting points.
Monitor the machine as well. Re-encoding can consume enough CPU or GPU capacity to make the process fall behind, while stream copy can expose source incompatibilities that re-encoding would have removed. A stable upload connection matters just as much as the nominal bitrate. Keep some capacity for ordinary network traffic rather than treating the full connection speed as available to FFmpeg.
If the main difficulty is keeping a personal computer running, awake and supervised through the night, StreamNeo removes that specific operational burden by taking an uploaded video, your YouTube stream key and the continuous broadcast out of the local-machine loop, with automatic monitoring and restart when the stream drops.
For a local FFmpeg setup, save the exact command, playlist and test notes after a successful trial. Keep the stream key outside shared documentation, and make a small change at a time when troubleshooting. The Go Always Live checklist is useful for checking the wider channel operation before handing the broadcast to an audience.
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 one FFmpeg command play several videos in sequence?
Yes. Put the files in a concat playlist and pass it to FFmpeg with -f concat. The files still need compatible streams for a reliable demuxer workflow, and the command normally ends when the final listed file ends unless you configure input looping.
Should I use -c copy or re-encode?
Use stream copying only after testing that the files match in codec, time base, dimensions, frame rate, audio layout and other relevant stream properties. Re-encoding is more suitable when the sources differ, because it creates a common output, but it uses processing capacity and adds an encoding step.
Why does -g 60 not always mean a two-second keyframe interval?
It equals two seconds only when the output is 30 frames per second. For another frame rate, choose a GOP length roughly twice that rate if you are targeting a two-second interval, then verify the actual output and YouTube stream health.
What should I do if YouTube shows no preview?
Confirm the current server URL and stream key in YouTube Studio, then check the FFmpeg output for playlist, input, encoder and network errors. Test privately or unlisted first, and do not publish a stream key while sharing logs or screenshots.