A playlist file lets FFmpeg read several local media files in sequence and send their combined output to a YouTube live stream. It controls which files FFmpeg opens; it does not, by itself, keep the encoder, internet connection, or YouTube ingest session healthy.
For compatible files, use FFmpeg's concat demuxer and, where appropriate, stream copy. Then test the complete path from disk to YouTube, monitor stream health separately, and prepare a recovery method for process or network failures.
Separate looping from stream reliability
There are two different jobs in a 24/7 stream. The first is choosing what happens when one file ends. The second is keeping the complete pipeline operating: reading media, encoding or copying it, uploading it, and maintaining the live connection to YouTube.
A concat playlist handles the first job. It is a text file that tells FFmpeg to process one input after another. It does not restart FFmpeg when the process exits, restore a dropped connection, replace a damaged file, or correct a stream key. If the final file ends, FFmpeg normally reaches the end of its input unless you have arranged another layer of looping or process supervision.
This distinction matters for devotional channels, music loops, study channels and local programming. A playlist containing ten videos may run in the intended order, but a missing file can stop the input before the audience expects. A healthy local playlist can also be sent through a weak upload connection and still produce a broken broadcast.
For a broader view of the content side, see how a 24/7 channel can be built from one video. That approach and a multi-file playlist solve different scheduling problems. Neither removes the need to check the delivery path.
Keep a written distinction in your operating notes:
| Problem | What addresses it | What it does not address |
|---|---|---|
| Play files in sequence | FFmpeg concat demuxer | Upload failures or a crashed process |
| Make unlike files consistent | Concat filter and re-encoding | A bad stream key or unstable network |
| Send output to YouTube | RTMPS or another supported ingest method | A failed local disk or encoder |
| Recover after a stopped process | A separate supervisor or restart procedure | Incorrect media timestamps |
| Confirm that YouTube is receiving usable media | Stream health and preview checks | Future failures after the check |
You can also use a cloud-based workflow when leaving a computer running overnight is the problem. StreamNeo turns an uploaded video into a YouTube live stream, so the local playlist and the recovery of a local FFmpeg process are no longer the part you have to keep running on your own computer. It remains your responsibility to prepare lawful, suitable media and check the live channel.
Create the playlist file correctly
Create a plain text file, for example playlist.txt, with one file directive for each input:
file '/path/to/first.mp4'
file '/path/to/second.mp4'
file '/path/to/third.mp4'
The FFmpeg concat demuxer reads this script and demuxes the files sequentially. Use paths that are valid on the operating system where FFmpeg is running. If a path contains spaces or special characters, quote and escape it according to the concat demuxer's rules rather than assuming that shell quoting alone will be enough.
The relevant input shape is:
ffmpeg -re -f concat -safe 0 -i playlist.txt ...
Here, -f concat selects the concat demuxer. The -safe option controls how paths in the list are treated. Use -safe 0 only when the playlist is trusted and the paths require it. It is not a general repair option, and it should not be used to make an untrusted playlist acceptable.
The file must be accessible to the account running FFmpeg. A playlist created on Windows will not automatically work on Linux if it contains Windows drive letters or backslashes. Likewise, a path copied from a file manager may point to a location that exists for your user account but not for a scheduled service.
Before starting the stream, check each entry manually. Confirm that the file exists, can be opened, has the intended duration, and is the version you meant to publish. For a local music or talk station, this is also the point to check whether a file contains the expected language, advert breaks, or silence. A technically valid playlist can still produce the wrong programme.
The playlist itself is not a YouTube playlist and not an HLS media playlist. It is an FFmpeg input script. YouTube's HLS ingest process uses a different segmented playlist and delivery method, which is discussed below.
Set a 1080p30 SDR starting point
A sensible starting point for a standard 1080p live channel is 1920 by 1080 pixels, 30 frames per second, progressive video, and SDR colour. This is a starting configuration rather than a guarantee that every source or connection should use it.
The source files should be inspected before you choose the output settings. If one file is 1280 by 720 and another is 1920 by 1080, -c copy cannot make them the same format. If one file is 25 fps and another is 30 fps, copying both streams into one continuous output may create timing or compatibility problems. A vertical phone recording may also need scaling and padding rather than direct copying.
For a controlled set of matching sources, an illustrative re-encoding shape could look like this:
ffmpeg -re -f concat -safe 0 -i playlist.txt \
-vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2" \
-r 30 -pix_fmt yuv420p -c:v libx264 -preset medium -b:v 4500k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 48000 -ac 2 \
-f flv 'rtmps://<YouTube-ingest-endpoint>/<stream-key>'
This is an illustrative command shape, not a tested command. The suitable encoder name, preset, available hardware acceleration, and supported pixel formats depend on your FFmpeg build and machine. Do not paste it into a production stream without checking the files, build, destination, and local performance.
The example uses 4,500 kilobits per second for video as a documented starting point rather than a promise that it is right for every account or connection. YouTube's current guidance should be checked before choosing an output profile, particularly if you are changing resolution, frame rate, HDR or codec. If your source is already suitable and your priority is to avoid re-encoding, use the compatibility checks in the next section instead.
SDR is deliberately simpler for a first setup. HDR, unusual colour ranges, interlaced material, variable frame rate recordings and mixed pixel formats introduce additional decisions. A channel showing a still devotional image with audio may not need the same treatment as a channel showing fast local events. The output should be stable and visually correct, not merely labelled 1080p.
Configure bitrate, keyframes and audio
A live encoder needs a steady output, not just a high peak quality setting. Bitrate is the amount of data sent over time. A high bitrate can preserve detail but requires more upload capacity and leaves less room for network variation. A lower bitrate reduces the upload burden but may show more compression in moving scenes or text overlays.
For a practical test, measure the complete upload route while the chosen encoder is running. Do not judge it only from a speed-test result taken at another time. Other devices, Wi-Fi interference, mobile-network congestion and local backups can change the available capacity overnight.
Keyframes are points where a decoder can begin a new section of video without relying on a long chain of earlier frames. A regular keyframe interval makes live ingest easier to process. In the illustrative command, -g 60 with 30 frames per second represents a two-second interval, while -keyint_min 60 and scene-cut control are used to make that interval more predictable. These are encoder settings, not a substitute for checking YouTube's current live encoding guidance.
Audio needs the same attention as video. A common starting arrangement is AAC, stereo, 48 kHz, with a moderate audio bitrate. The important point is consistency: if one file has stereo AAC and another has a different channel layout or sample rate, direct stream copy may fail or produce an output that behaves differently at the transition.
Check for files with no audio stream, multiple audio tracks, unusual channel layouts or long silent sections. A playlist for a study channel may intentionally contain quiet material, but an accidental missing audio stream is a different problem. Decide whether the output should always contain one selected audio stream and normalise it when necessary.
FFmpeg's documentation explains the concat demuxer's requirements for matching streams, codecs and time bases in its concat demuxer documentation. When the files meet those conditions and the output supports them, -c copy can avoid a re-encode:
ffmpeg -re -f concat -safe 0 -i playlist.txt \
-c copy -f flv 'rtmps://<YouTube-ingest-endpoint>/<stream-key>'
Use this only as a conditional example. Stream copy is not a universal shortcut. Incorrect duration metadata, unequal stream lengths, different time bases or mismatched codecs can cause gaps, timestamp warnings, broken transitions or a failed output.
When the inputs need scaling, frame-rate conversion, codec changes or audio normalisation, use a concat filter workflow and re-encode. FFmpeg's FAQ explains the difference between concatenating with the demuxer and using the filter approach. The filter route uses more processor time, but it gives you control over a common output format.
Use RTMPS where supported
For a normal YouTube encoder workflow, obtain the current ingest address and stream name or key from YouTube Live Control Room. Keep the key private. Treat it like a credential: do not put it in a public tutorial, commit it to a shared repository, or paste it into a support forum with the rest of the command.
YouTube's RTMPS ingestion guidance describes RTMPS as RTMP carried over SSL and specifies the supported connection arrangement. The exact endpoint and path belong to the configured live stream, so the placeholder in the commands above must be replaced with the current value supplied for your broadcast.
The final output format in the examples is flv, which is commonly used for an RTMP-family live output. It does not mean that your source files must be FLV files. The input playlist can contain compatible MP4 or other supported media while FFmpeg produces the chosen live output format.
YouTube's live documentation also describes the ingestion address and stream name as separate pieces that an encoder may accept separately or combine into a URL. Check what your FFmpeg build and command syntax expect, and avoid adding extra punctuation to the key. A small destination error can look like a network failure when the real problem is the URL or credential.
HLS ingest is a separate method. YouTube's HLS ingestion documentation describes HTTPS delivery of media segments and a rolling playlist. As listed on YouTube's site in September 2026, its HLS requirements include transport-stream segments, segment durations between one and four seconds, and no more than five outstanding segments. The same documentation notes that HLS has higher latency than RTMP because it sends video in segments.
Do not turn playlist.txt into an HLS playlist by changing its filename. The local concat script lists source files for FFmpeg. An HLS media playlist describes segmented output for an ingest protocol. If you choose HLS, follow the current YouTube requirements for that workflow rather than adapting the concat command by guesswork.
Test the complete encode and upload path
Test the whole route before relying on it overnight. Start with a short, private or unlisted broadcast where appropriate, then observe the local FFmpeg output and YouTube's live preview. This checks more than whether FFmpeg can open the first file.
A useful test sequence is:
- Open every playlist file directly and confirm its duration and audio.
- Run the concat command without the YouTube destination if you need to inspect local output first.
- Send the output to the configured live destination using the intended resolution, frame rate, bitrate and audio settings.
- Watch a transition between files rather than stopping after the first input.
- Leave the process running long enough to encounter the conditions that matter for your schedule.
- Stop it deliberately and record what has to be restarted, cleared or reconnected.
Look for decoder errors, timestamp warnings, missing audio, sudden frame-rate changes and rising CPU use. A command that begins successfully may still fail when the second file has a different time base or when the machine reaches a sustained encoding load.
On YouTube, check the live preview, stream health messages and the received video and audio indicators. The YouTube Live Control Room guide is useful for separating what the control room displays from what it will not automate for you.
Test the upload from the location where the channel will actually run. A desktop test on a wired connection does not prove that a laptop on Wi-Fi, a machine in a shop, or a computer using mobile broadband will behave in the same way. If the stream runs from a different city or premises, repeat the test there.
Do not describe a command as tested merely because it starts. A meaningful test includes the playlist transitions, audio, output format, upload route and the intended viewing device. It still cannot predict every future failure, which is why recovery planning remains separate.
Monitor YouTube stream health
Monitoring should answer three questions: is FFmpeg still running, is data leaving the machine, and is YouTube receiving and processing usable audio and video. Checking only one of these can give a false sense of security.
FFmpeg may remain open while the input is stalled or the output is blocked. A router may show an active connection while YouTube is receiving no useful frames. YouTube may display a warning even though the local process has not reported an obvious error. Record which signal you are checking and what action follows it.
For a small channel, a simple operating routine can be enough. Check the process log, confirm that the playlist has advanced, inspect YouTube's health indicators, and open the public stream from a separate device. For a channel with scheduled programming, keep a note of expected file transitions so a silent or frozen output is easier to recognise.
You should also monitor the source disk and available processor capacity. A nearly full disk can prevent logs or temporary files from being written. A machine running other applications may begin dropping frames after an update or a change in source material. These are operational conditions, not playlist syntax problems.
The RTMP, RTMPS and SRT comparison can help when you are deciding which delivery protocol fits the connection and workflow. For this FFmpeg-to-YouTube procedure, use the protocol that YouTube currently supports for your chosen ingest setup and validate it with a real broadcast.
Plan process recovery and failover separately
A playlist can finish normally, encounter an unreadable file, or continue while the network output has failed. Each case needs a different response. Recovery should not be hidden inside a complicated command that nobody can explain at two in the morning.
Write down what happens when FFmpeg exits. Decide whether a person restarts it, a service manager launches it again, or a scheduled task handles it. The restart procedure should include checking the error, confirming that the destination credential is still valid, and deciding whether to resume the same playlist or skip a damaged input.
A process restart is not the same as a network failover. If the broadband connection is down, restarting FFmpeg repeatedly may create more noise without restoring delivery. If the stream key is wrong, another network will not correct it. If a source file is corrupt, a new process will usually encounter the same file again.
Keep an alternate content plan. A second playlist with known-good files can help you distinguish a media problem from a delivery problem, but it does not guarantee that YouTube will accept the output. A separate computer or connection may reduce one point of failure, but it adds setup, credentials and testing work.
For a lofi or ambience channel, you might keep a simple fallback file ready and document who starts it. For a local news loop, you might prioritise a clear handover procedure so an operator knows whether to restart, change the source, or end the broadcast. For a devotional channel, you may need to consider whether a silent gap is preferable to an unplanned restart. These are editorial and operational decisions, not FFmpeg defaults.
Automatic restart deserves its own test. The guide to restarting a YouTube lofi stream after a crash covers the recovery problem separately from the playlist problem. Whatever method you use, test a controlled stop and confirm that it does not create overlapping broadcasts or expose the stream key in logs.
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 put MP4 files directly into a text playlist?
Yes, the concat demuxer can read a text file containing file directives that point to the media inputs. The files still need compatible streams, codecs and time bases if you want to use stream copy. Check paths, quoting and file permissions before sending the result to YouTube.
Why does -c copy fail when every file is an MP4?
The MP4 container is not enough to prove compatibility. The files may use different video codecs, frame rates, audio layouts, time bases or stream counts. Compare the media properties and use a concat filter with re-encoding when the inputs need normalisation.
Does the concat playlist keep my YouTube stream alive forever?
No. It controls the order in which FFmpeg reads inputs. It does not repair a failed upload, restart a crashed process, replace a missing file or recover from a YouTube ingest problem. Treat looping, monitoring and recovery as separate parts of the operation.
Is a local FFmpeg playlist the same as a YouTube HLS playlist?
No. The local file is an FFmpeg concat input script. An HLS playlist is part of a segmented delivery workflow with its own transport, segment and rolling-playlist requirements, so it should be configured from YouTube's current HLS documentation rather than copied from a local concat list.