To repeat a playlist on YouTube Live, use FFmpeg’s input-looping option with a concat-demuxer playlist. The repeat happens in FFmpeg as it sends a live feed; YouTube does not repeat an uploaded source for you.
The simplest pattern works when the files have compatible streams. If they need normalising, use a filter-based approach and re-encode; then test the transitions, ingest settings and stream health before relying on the channel overnight.
Build a playlist with the concat demuxer
Create a plain text file containing one file entry per clip, in the order you want them played. For example, save this as playlist.txt beside the media files:
file 'clip-01.mp4'
file 'clip-02.mp4'
file 'clip-03.mp4'
Use relative paths where possible, and check spelling and letter case. The paths are interpreted from the working directory where FFmpeg runs, which may not be the directory containing the playlist. If the command is launched elsewhere, either change directory first or write paths that resolve from the launch location. A missing clip can stop the input before it reaches the end of the list.
This playlist format is for FFmpeg’s concat demuxer. It is not a YouTube playlist URL, a list of items in YouTube Studio, or a playlist that viewers click through. FFmpeg reads the media files as one input and sends the resulting output to YouTube Live. See the FFmpeg concat demuxer documentation for details on its file entries and options.
The demuxer has a safe-path setting that defaults to 1; keep entries as ordinary relative paths when you can. Its safe=0 mode accepts any filename, but widening what the playlist can reference should not be a casual fix for a path problem. First correct the working directory or file names. The playlist is configuration that FFmpeg will read, so use files and paths you control.
If the list contains devotional tracks, for instance, order them to make sense across the join between the final and first clips. A file list will loop mechanically, not make an editorial decision about the transition. Listen to the end of the last track and beginning of the first together, particularly if the stream is meant to feel continuous.
Check that the files can join cleanly
The concat demuxer can avoid re-encoding when the input files are compatible. In practice, inspect whether the clips have matching stream layouts and consistent media properties, including video dimensions, frame rate and codec, and the presence or absence of audio. Compatibility is not established merely because every file has an .mp4 extension; a container can hold different streams and settings.
Use FFmpeg’s probe tools or another media inspector to review a sample of each file. Confirm that every clip contains the audio and video streams you expect. A silent still-image segment may have no audio stream, while the music clips around it do. A resolution or frame-rate change between segments may also make a direct join unsuitable. The precise result depends on the files and FFmpeg build, so treat inspection as a first check, not proof of a perfect transition.
Play through joins before going live. Watch for a brief freeze, a black frame, an audio gap, abrupt loudness change or a timestamp warning. For a music channel, listen with headphones across each transition; for a local news loop, check captions, graphics and voice levels as well as motion. You do not need to test every possible condition by guesswork: use representative clips, then validate the assembled list in an actual short run.
When the files are compatible and your goal is to avoid an extra generation of compression, the concat demuxer is worth trying. When they are not, do not force a copy-only command and assume the output is sound. FFmpeg distinguishes the concat demuxer from the concat filter; its FAQ on concatenating video files recommends the filter when re-encoding is needed.
For another file-based YouTube workflow, the guide to looping a single video without a black screen covers a one-file case. A playlist adds ordering and compatibility questions, but the key distinction remains: FFmpeg produces the repeated programme before YouTube receives it.
Loop the playlist input in FFmpeg
For a playlist, put -stream_loop -1 before the playlist input. The -1 value asks FFmpeg to loop that input indefinitely. The following is an illustrative command that encodes the programme as H.264 video and AAC audio, then sends an FLV output to an RTMP-style ingest address:
ffmpeg -re -stream_loop -1 -f concat -i playlist.txt \\
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \\
-r 30 -g 60 -pix_fmt yuv420p \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "$YOUTUBE_INGEST_URL/$YOUTUBE_STREAM_NAME"
The command is a starting point, not a universal recipe. It reads at a rate suitable for live output with -re, loops the playlist input, and encodes to the selected output settings. Keep input options before the matching -i. Confirm the behaviour with the FFmpeg build installed on your machine, particularly if it is old, and test the actual command before scheduling a long run.
The output placeholder represents values from your YouTube live stream settings. Depending on the encoder interface, the stream name may be appended to the ingestion URL or supplied in a separate field. Do not copy the example literally without checking the form expected by your setup. YouTube’s LiveStreams API documentation describes the ingestion address and stream name. Treat the stream name as sensitive: do not publish it in a script, screenshot or public support request.
-stream_loop -1 is the part that makes the input repeat in FFmpeg. By contrast, -f concat selects the concat demuxer and -i playlist.txt points it to the list. -re is commonly used to pace file input at its native rate for live output; its behaviour should be verified on the installed version and in a test stream. None of these options alters an already uploaded YouTube video or makes YouTube replay a file on its own.
A loop can still fail at a boundary. If a file ends with unusual timestamps, a different stream layout, or a damaged frame, the command may show an error or the output may have an audible or visible discontinuity. Indefinite input looping means FFmpeg keeps requesting the input again; it is not a guarantee that every clip is valid, that the process will never stop, or that the broadcast remains uninterrupted.
Decide whether to copy or re-encode
There are two practical paths. Copying streams avoids decoding and encoding them again, but only makes sense when the files can be joined consistently and the output already meets the live ingest requirements. Re-encoding gives you a chance to standardise properties such as codec, resolution, frame rate and audio format, at the cost of more processing and another lossy encode in many cases.
| Output approach | Use it when | Main trade-off |
|---|---|---|
| Concat demuxer with stream copy | Inputs have compatible stream layouts and the existing media suits the intended output | Less processing, but mismatches and boundary issues are not corrected for you |
| Concat filter with encoding | Inputs need normalising, such as differing dimensions or frame rates | More control over a consistent output, with added encoding work and possible quality loss |
| Encode a concat-demuxer input | Inputs can be read as a list but the output needs a chosen standard format | Often a useful starting point, but it still needs a test for transitions and timing |
The example above encodes the concat input. It does not use -c copy, so FFmpeg decodes and re-encodes the streams to the selected codecs. If you want to try stream copy, the codec options would be replaced with -c copy, but do so only after verifying compatibility and the YouTube output requirements. A command that completes is not by itself evidence that the stream is suitable.
When normalisation is needed, the concat filter is a different construction from the demuxer playlist. It lets you define how inputs are joined and encoded, but filter syntax and stream mapping depend on the actual files. Rather than paste a generic filter graph into a 24/7 channel command, make a small representative sequence, establish the desired output format, then inspect the output and listen across joins.
If you are moving from a single recording to a multi-episode channel, the article on streaming pre-recorded videos on YouTube Live explains the distinction between a live feed and a video upload. For an always-on channel, also consider where the FFmpeg process will run and who will notice an error; a repeat option handles input order, not process supervision or network recovery.
Match the output to YouTube’s ingest settings
YouTube accepts supported ingest workflows such as RTMP/RTMPS and HLS, but this example uses an FLV output suited to RTMP-style ingest. Use the protocol and address shown for the actual live stream in YouTube Studio. Do not substitute an address found in an old command or a tutorial if your account settings show a different one.
The encoder settings page lists H.264, H.265/HEVC and AV1 video support, and AAC or MP3 audio support. It recommends constant bitrate (CBR), and keyframes every two seconds, not more than four seconds apart. These are platform recommendations, not a promise that a particular stream will be accepted or look good on every network. See YouTube’s current encoder settings, bitrates and resolutions before choosing values.
In the sample command, -g 60 means a GOP of 60 frames, which corresponds to two seconds only at 30 frames per second. If you change the frame rate, calculate the GOP to keep the intended interval. The example’s bitrate values are illustrative, not a recommended setting for every channel. Select bitrate against the codec, resolution and frame rate you actually plan to send, then check that your upload connection can sustain it with room for ordinary variation.
For context, YouTube’s encoder table currently gives examples for 1080p at 30 fps of 14 Mbps with H.264 and 10 Mbps with AV1 or H.265; for 720p at 30 fps it gives 8 Mbps with H.264 and 6 Mbps with AV1 or H.265. These are YouTube’s listed recommendations, reviewed on 3 October 2026, and they can change. Confirm the current table and your account’s ingest configuration rather than treating those examples as a fixed minimum or a broadband guarantee.
There is a real trade-off between resolution and a stream that your connection can maintain. A crisp 1080p source does not require a 1080p live output if the available upload is unstable or shared with other household use. The bitrate guide for 24/7 YouTube streaming on Indian broadband can help you reason about the connection side, but use YouTube’s current encoder guidance for the final settings.
Run a preflight before the channel depends on it
Start with a short test using the exact playlist, command, network and ingest settings planned for the real broadcast. Include motion and representative sound. A static title card will not reveal how a fast-moving clip behaves at the chosen bitrate, and a silent test will not expose an audio mapping problem. YouTube explicitly advises: “Make sure to test before you start your live stream.”
In YouTube Studio’s live control room, confirm that data arrives and that the detected resolution and frame rate match your intent. If you use a custom stream key with manual resolution settings, check those too. Read the health indicator and any messages rather than treating the presence of a preview as the only success criterion. The goal is to catch a bad key, incompatible output, unexpectedly low resolution or unstable upload before viewers depend on the stream.
A practical preflight looks like this:
- Confirm all playlist paths resolve from the directory where FFmpeg will run.
- Check each file for expected audio and video streams, dimensions, frame rate and codec.
- Watch and listen across at least one playlist boundary, including the last-to-first join.
- Verify the ingest URL and stream name against the current live stream settings, keeping the name private.
- Compare outgoing resolution, frame rate, codec, keyframe interval and bitrate with YouTube’s current guidance.
- Run the test long enough to see representative movement and hear representative audio, then review Studio’s messages and stream health.
A playlist that only plays once locally is not a full preflight. It is worth checking the actual loop boundary: if the last clip ends with a spoken sign-off and the first begins abruptly, the sequence may be technically valid but jarring to viewers. For devotional or lofi channels, listen for a moment of silence or a sudden level change. For a news loop, check whether the first item makes sense after the final item.
Do not publish a shell command with a real stream name in a public repository, shared document or screenshot. Shell history can also retain commands, depending on how you run them. Prefer environment variables or an interface that keeps the credential out of visible text, and restrict access to the machine or account that starts the broadcast.
Monitor the live output and plan for recovery
Once live, watch both sides of the chain: FFmpeg’s output and YouTube Studio’s stream health. FFmpeg can report local input, timestamp, encoding or connection errors; Studio can show whether it is receiving data and whether its configuration checks have found an issue. The LiveStreams API also exposes health status for API-based workflows, but a small channel can use Studio rather than building an integration.
A looping playlist is not the same as a self-healing broadcast. If the FFmpeg process exits, the network drops, the computer sleeps or a source file becomes unavailable, -stream_loop -1 does not restart the entire process. Decide who will see an alert and what they can do. If you operate FFmpeg on a local computer, prevent sleep and account for power and broadband interruptions. If the process is remote, test access and recovery arrangements before depending on it.
You can read about a separate failure mode in FFmpeg reconnect options for a continuous YouTube stream. Reconnection options address aspects of a dropped output connection; they do not repair incompatible playlist files or guarantee that YouTube will preserve a live session. Keep the input, output connection and YouTube ingest health as distinct things to troubleshoot.
For a non-technical operator who needs the channel to continue while their own computer is off, StreamNeo removes the specific burden of keeping a local FFmpeg process and machine running: upload the file, provide the YouTube stream key, and the cloud broadcast runs with monitoring and automatic restarts if it drops. It is YouTube-only, so an FFmpeg workflow remains relevant if you need to shape a multi-file playlist yourself or use a different destination.
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 YouTube repeat a video I upload?
No. The pattern here loops files inside FFmpeg and sends the resulting output as a live stream. An uploaded video and a live feed are different workflows; do not expect YouTube to repeat an uploaded source automatically.
Can I use -c copy to avoid re-encoding?
Sometimes, if the files are compatible and their streams already suit the output. Check their layouts and properties, then test the joins; if you need normalisation, use a filter-based concat workflow and re-encode instead of forcing a copy.
Why does the command use -g 60?
It is an example for 30 fps: 60 frames gives a two-second keyframe interval at that frame rate. If you change the frame rate, adjust the GOP and verify the resulting interval against YouTube’s current encoder guidance.
Will this command keep a stream running forever?
It requests indefinite looping of the playlist input, not uninterrupted operation of the whole broadcast. FFmpeg can stop, files can fail, and the network or ingest can drop, so run a preflight and monitor both FFmpeg and YouTube Studio while live.