A playlist in this guide means a sequence of video files stored on your computer or another filesystem you can access, not a playlist page on YouTube. FFmpeg can read and combine local inputs, but it does not treat a YouTube watch-page playlist URL as a supported playlist input.
The dependable workflow is to inspect each file, make incompatible media consistent, then encode the sequence as one live H.264 video and AAC audio output. You send that output to the ingest protocol selected in YouTube Live; the example below uses RTMP and is a starting pattern, not a universal preset.
What an FFmpeg playlist means
For FFmpeg, a playlist here is a text file that names local media files in order. The concat demuxer reads those entries as a single input when the files have compatible streams and timing characteristics. A list of URLs from YouTube is a different thing: it is not an input format that this workflow can consume directly. Downloading or reusing video also raises rights and permission questions that a command cannot settle.
There are two common ways to combine local clips. The concat demuxer joins compatible files without decoding and re-encoding each one first. A concat filter decodes the inputs, lets you adjust them and then encodes a new output; it is generally the useful route when frame sizes, frame rates, audio layouts or codecs differ. Neither approach makes arbitrary files compatible automatically.
A playlist can run once or repeat. For a continuous channel, repeating a prepared sequence is often simpler than relying on manual restarts, but it does not remove the need to monitor the broadcast. Decide the order and whether the sequence should loop before preparing the list. If the visual material is an animation loop, the choices around motion and cadence are also relevant to a guide to frame rate for pre-recorded animation.
Inspect the source files before joining them
Do not assume that files with an .mp4 extension have the same internal structure. One might contain H.264 video and AAC stereo sound, another HEVC video and no audio, and a third might use a different frame size or a variable frame rate. The extension describes a container, not a guarantee about the streams inside it.
Use ffprobe, which is distributed with FFmpeg, to inspect each source. A compact check is:
ffprobe -v error -show_entries stream=index,codec_type,codec_name,width,height,r_frame_rate,avg_frame_rate,time_base,sample_rate,channels -of table clip-01.mp4
Repeat this for every file, or use a small script to collect the results. Compare at least the video codec, dimensions, frame rates and time bases; for audio, compare whether a stream exists, its codec, sample rate and channel count. Also check stream count and order. A file with commentary on a second audio stream can produce a surprise if the final command maps only the first audio stream.
The output from ffprobe is evidence for a decision, not a pass/fail certificate. If the first two files have matching video and audio characteristics, the demuxer may be appropriate. If a later file has no audio, a different size, or a different time base, pause and decide how it should be normalized. You can read about the distinction between input handling and FFmpeg command options in the FFmpeg command-line documentation, and consult its concat FAQ for the supported concatenation approaches.
Listen and watch a sample from each source as well. A technically compatible file can still have a black opening, an abrupt audio peak, an unwanted slate, or a different loudness from its neighbours. FFmpeg can transform streams, but only you can decide whether those changes are acceptable for the channel.
Normalize files that do not match
The concat demuxer expects the relevant streams to be compatible; it does not resize images, add missing audio, or repair different codecs and time bases. If files are heterogeneous, normalize them before concat, or use a filter graph that decodes and re-encodes the sequence. FFmpeg's FAQ points to the concat filter where re-encoding is required.
A practical normalization target is a set of decisions, not a magic preset. Choose one output frame size and frame rate suitable for your material and channel, a consistent pixel format, and an audio sample rate and channel layout. Apply those choices to every clip. A vertical phone clip mixed with landscape footage, for example, needs a deliberate crop, pad or background treatment; blindly stretching it distorts the image. A clip without sound may need a silent audio track if the chosen filter graph or mapping expects audio on every segment.
One pattern is to convert each file to a common intermediate format, review the results, and then use the concat demuxer on those normalized files. Another is a filter_complex graph using the concat filter and explicit video and audio filters. The latter can avoid intermediate files but grows harder to audit as the number of clips and differences increase. In either case, test a short section with clips at a transition before you prepare the whole schedule.
Normalization can reduce quality because it means another encode, and scaling or frame-rate conversion changes the source. Keep originals, retain a written record of the chosen order and settings, and inspect the output on a normal player before going live. If the source material is already compatible, an unnecessary intermediate encode adds work without solving a real problem.
Create and validate the file list
For compatible or already-normalized files, create a plain text file such as playlist.txt with one entry per line:
file '/media/clip-01.mp4'
file '/media/clip-02.mp4'
file '/media/clip-03.mp4'
Use paths that exist from the machine running FFmpeg. Quoting matters when a filename contains spaces or special characters; the exact escaping needed can depend on the path and operating system. Avoid ambiguous relative paths by using absolute paths while testing. The -safe 0 option shown later permits paths outside the concat demuxer's restricted safe subset, so only use a list you control and understand.
Check the order in a text editor and confirm every file opens at that exact path. Then run a local test that reads the concat input and writes a short output file rather than sending it to YouTube. Play the result across transitions, not just at the beginning: look for frozen frames, missing audio, a pause, an unexpected aspect ratio, or a jump in sound level. A malformed list can fail before streaming, while a stream mismatch can become apparent only when FFmpeg reaches a later entry.
If your schedule changes, update and validate the list before restarting the live output. Keep filenames simple and avoid editing the list while a broadcast is running unless you have confirmed the behaviour for your workflow. The file list is a production document: a typo can create a dead section in what viewers see.
Configure H.264 video and AAC audio
For a compatible concat input, a representative RTMP command is:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \
-map 0:v:0 -map 0:a:0? \
-c:v libx264 -pix_fmt yuv420p -preset veryfast \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv 'rtmp://YOUR_INGEST_URL/YOUR_STREAM_KEY'
This illustrates the shape of the workflow; it has not been tested as a universal YouTube command. Check that your FFmpeg build includes libx264, that the input mapping matches your files, and that the selected ingest protocol and current YouTube guidance fit your use. The -re option reads file input at its native rate instead of sending it as fast as the machine can process it. -stream_loop -1 repeats the concat input. -map selects the first video and, if present, first audio stream. The question mark makes the audio mapping optional, but optional mapping does not add silence where source clips lack audio.
libx264 encodes H.264 video; yuv420p is a commonly used pixel format for broad playback compatibility. -preset veryfast trades some compression efficiency for less encoding work, so test whether your machine can sustain the chosen output. The native FFmpeg AAC encoder is selected with -c:a aac; specifying a bitrate selects its constant-bitrate mode, and AAC-LC is its default profile. The example's audio rate and channel settings reflect YouTube's HLS guidance, not a claim that those values are the current RTMP recommendation. Check the separate, current encoder settings guidance for the protocol you will use before treating any numeric setting as final.
Do not copy a bitrate or resolution from an unrelated tutorial without checking it against the source resolution, available upload capacity and current YouTube encoder requirements. A higher output size or rate can consume more upload bandwidth and increase encoding load; a lower one can lose detail. For a broader comparison of how resolution and bitrate choices affect long-running broadcasts, see bitrate ladders for long-run streams. Measure the actual output and keep headroom on the connection rather than assuming the advertised line speed is available continuously.
RTMP and HLS are different delivery protocols, not interchangeable URLs. The command above packages output as FLV for an RTMP-style endpoint. YouTube's HLS ingest instead has its own packaging and upload rules: MPEG-TS segments, a rolling playlist with no more than five outstanding segments, HTTPS POST or PUT, and segments from one to four seconds. See YouTube's HLS ingestion guide before building an HLS workflow; do not substitute an HLS URL into the RTMP example.
Send the stream to YouTube Live
In YouTube Live setup, obtain the ingest information for the broadcast and select the matching protocol. The RTMP URL and stream key are credentials for sending video to your channel. Keep the key private: do not paste it into a public repository, share a screenshot containing it, or leave it in a script that other people can access. If it is exposed, use YouTube's current controls to replace it.
Replace the placeholders in the command with the selected ingest URL and key, preserving the URL structure provided by YouTube. Be cautious about shell history and process listings, which can reveal command arguments on some systems. You can reduce accidental exposure by using a protected environment or secret-management method appropriate to your operating system, but make sure your chosen method works with FFmpeg and does not leak the key into logs.
Start with a private or otherwise non-public test where possible. Confirm that FFmpeg is encoding without errors, that the YouTube preview receives a picture and sound, and that the live health indicators do not show a problem before changing visibility. Check the beginning, one or more transitions, and a loop boundary. The official YouTube Help encoder settings should be checked for current requirements; account eligibility and Studio screens can change, so verify the applicable setup inside your account rather than relying on an old screenshot.
A successful FFmpeg process is not proof that viewers can watch the stream. The network may drop, YouTube may report ingest trouble, or a later file may fail only when reached. Keep an operator available to respond, especially for a news loop or a channel where silent gaps would matter. For an extended broadcast, consider the separate question of how much upload bandwidth a YouTube radio livestream needs, then leave room for normal network variation.
If keeping a computer awake, connected and watched through the night is the part that makes this setup impractical, StreamNeo removes that specific burden: it turns an uploaded file into a YouTube live stream without needing your own computer to keep encoding continuously.
Choose a workflow that fits the channel
FFmpeg is a good fit if you are comfortable preparing files, checking logs and maintaining a command-line process. You control the sequence and encoding choices, but you also own the work of keeping the computer, power and internet connection available and responding when a process stops. A local setup may suit a short schedule or a channel where someone is already responsible for the machine.
A managed workflow can make more sense when the same prepared material must run while your own computer is switched off. Conversely, if you need live scene switching, guests, overlays or frequent changes to content, a static file playlist may not be the right production model. Compare the job you actually need to do rather than judging tools only by whether they can produce an H.264 stream.
For either route, retain the original media and a validated order, check rights for every item, and monitor the live output. A reliable workflow is not simply a command that starts once; it is a repeatable process for identifying bad inputs, testing transitions, protecting access and recovering when something fails.
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 FFmpeg stream a YouTube playlist page directly?
No. This workflow treats a playlist as local files named in an FFmpeg concat list, not as a YouTube watch-page playlist URL. Prepare media files you have permission to use and provide them as supported FFmpeg inputs.
Can I concatenate different video files unchanged?
Only when their relevant streams and timing characteristics are compatible with the concat demuxer. If codecs, dimensions, time bases or audio layouts differ, normalize the files or use a filter-based concat workflow that re-encodes and then test transitions.
Does the example command apply to HLS as well as RTMP?
No. It illustrates an RTMP-style FLV output. YouTube HLS requires its own MPEG-TS segment packaging, rolling playlist and HTTPS upload behaviour, so consult the HLS documentation and configure that protocol separately.
Why does the YouTube preview have no sound?
Check whether the source clips contain audio, whether the intended stream is the first audio stream, and whether the map and encoder settings match the files. The optional map in the example skips audio when it is absent; it does not create an audio track or fix inconsistent audio between clips.