To loop multiple video files in FFmpeg for YouTube Live, put compatible files in a concat-demuxer playlist and apply -stream_loop -1 to that input. If the clips differ in important stream properties, normalise or re-encode them first: direct concatenation is not a reliable way to reconcile mismatched media.
The practical order is to inspect the files, choose the appropriate media path, test the sequence once, and only then send it to YouTube. The examples below are templates; your files, encoding capacity and current YouTube ingest guidance determine the final settings.
Check whether the files can be joined directly
The concat demuxer treats a text playlist as one virtual input. It is useful when each file presents compatible streams with matching parameters, so FFmpeg can move from one file to the next without having to reconcile a new format at every boundary. Matching filenames or the .mp4 extension alone do not establish compatibility.
Inspect representative files before making the playlist. FFmpeg's ffprobe can show the video and audio streams, codecs, dimensions, frame rate, sample rate, channel layout and time-base details. For example:
ffprobe -hide_banner -i clip-01.mp4
Repeat for each clip, or use a script to collect the same information across the folder. Compare the actual streams, not just the container. Two MP4 files might contain different video codecs, frame rates or audio layouts; conversely, files with different container names may still be convertible into a consistent output, but that takes preparation.
Look for differences in codec, resolution, frame rate, audio presence and layout, and time base. A playlist with one 1920×1080, 30 fps clip followed by a 1280×720, 25 fps clip is not a sound candidate for assuming seamless direct concatenation. A clip with no audio can also create a boundary problem if the rest of the programme has audio. These discrepancies may lead to errors, awkward transitions or output that does not behave as intended.
You can read FFmpeg's explanation of the concat demuxer and concat filter before choosing a route. Keep a short sample from the actual playlist for testing; checking only the first file misses faults that appear when FFmpeg reaches a later clip.
Choose direct concatenation or normalise first
Use the concat demuxer for files with compatible stream layouts and parameters, especially when avoiding an extra generation of encoding matters. It reads the listed files as a sequence and is less involved than decoding every clip, applying filters and encoding a common output. It does not make differing inputs uniform by itself.
When properties differ, prepare the files to a common specification or create a filter-and-re-encode workflow. Normalisation can include scaling to one frame size, converting frame rate, setting a common pixel format, and making audio presence, sample rate and channel layout consistent. The right choices depend on your material and the output you intend to send; do not copy settings blindly from one clip to another.
| Route | Best fit | Main trade-off |
|---|---|---|
| Concat demuxer with stream copy | Compatible streams and a desire to avoid re-encoding | Little control over differences; mismatched files may fail or produce a poor transition |
| Concat demuxer with output encoding | Compatible or suitably prepared inputs that need a chosen delivery codec | Encoding adds compute work and may add a generation of quality loss |
| Filter/re-encode workflow | Inputs that need scaling, frame-rate conversion or audio handling | More setup and real-time encoding work, but explicit control over the output format |
The FFmpeg project distinguishes the concat demuxer from the concat filter: the filter is for joining decoded streams in a filtering and re-encoding workflow. If you need filters to align varied sources, build the graph deliberately rather than expecting the demuxer to do it. See the FFmpeg command-line documentation for option behaviour and the filter documentation relevant to your chosen graph.
Consider the machine that will run the job. Stream copying compatible files uses less encoding effort than turning several dissimilar inputs into one output format. A filter pipeline has to decode, process and encode continuously at the selected pace. If the host cannot encode in real time, you may need to prepare standardised files in advance, reduce the output demands, or choose a different operating arrangement. A short test reveals whether it can sustain the actual workload more usefully than assumptions about hardware.
Build a playlist and define repeat behaviour
Create a plain text file such as playlist.txt, with one file line for each clip, in the order you want them to play:
file 'clip-01.mp4'
file 'clip-02.mp4'
file 'clip-03.mp4'
The order in the file is the playback order. Put a short ident or opening clip first if that suits the channel, and arrange the rest as a deliberate programme rather than relying on directory order. For a devotional channel, for example, you might group an opening aarti, bhajans and a closing segment into the sequence you want viewers to encounter again at the next cycle.
To repeat the whole playlist indefinitely, use -stream_loop -1 as an input option before -i. The following skeleton shows how the playlist can feed an encoded YouTube output:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \\
-c:v libx264 -preset veryfast -b:v 6M -maxrate 6M -bufsize 12M \\
-g 60 -r 30 -c:a aac -b:a 128k \\
-f flv 'rtmps://SERVER/APP/STREAM_KEY'
Here -stream_loop -1 requests indefinite repetition of the input sequence; it is not a promise that the process or network connection will stay alive. -re reads file input at its native rate, which is useful when simulating a live source instead of sending a prerecorded file as quickly as possible. Keep input options such as these before -i; encoding and output options follow the input and precede the destination URL. FFmpeg's CLI documentation describes option scope and ordering.
The values in the command are illustrative, not universal recommendations. In this example, -r 30 sets a 30 fps output and -g 60 sets a 60-frame GOP, equivalent to two seconds at that frame rate. If you choose a different output frame rate, set the GOP to match the keyframe interval you intend. The command encodes rather than stream-copies video, which can be useful where you need a consistent output, but it also requires the host to encode in real time.
A continuous playlist also needs a plan for audio. If every clip has compatible audio, the output encoding options may be suitable starting points. If one clip has no audio, or the clips have differing layouts, make an explicit decision: provide silence for silent portions, normalise the tracks, or build an audio filter that produces a consistent stream. Do not assume a silent file will automatically behave like a clip with an audio stream.
Handle paths and playlist formatting
FFmpeg reads each entry from the account and working environment running the process. The playlist file must be readable, and every referenced media file must remain accessible for the whole run. If you use relative paths, FFmpeg resolves them from the process's working directory; launching the same command from a different directory can therefore make a previously working playlist fail.
For a first test, keep the playlist and clips together and use simple filenames. If paths contain spaces or punctuation, quote them according to the concat file format and test a short run. For example:
file 'morning bhajan.mp4'
file 'evening-aarti.mp4'
If a filename itself contains a single quote, backslash or unusual character, do not guess how shell quoting applies: the playlist is parsed by FFmpeg's concat demuxer, not by the shell. Use the syntax described in the FFmpeg concat documentation, and verify that FFmpeg can open each file. A successful shell command does not prove that every playlist entry was parsed as intended.
The -safe 0 option in the example permits paths that the demuxer would otherwise reject as unsafe. Use it only when you control the playlist and its entries. It is not a general fix for misspelled paths, inaccessible folders or badly quoted filenames. If you can keep entries as simple relative paths, that is easier to inspect and maintain.
When you update a playlist, preserve the order and save the file in plain text. Avoid pointing an unattended job at a temporary download location that may be cleaned up, or at removable media that could be disconnected. For a long-running stream, document which directory holds the media and which account runs FFmpeg, then test the command in that same context.
Test the sequence before repeating it
First run the playlist without indefinite looping, so you can see whether every clip loads and how the joins look. Watch the first transition, one in the middle, and the boundary between the last and first entries. Listen for a sudden silence, a level jump, a click, or an audio track that starts late. Check for black frames, frozen pictures, aspect-ratio changes or unexpected gaps.
Use a short representative sequence that includes the most different files, not just three similar clips. If your playlist contains vertical footage, a silent ident and a wide video, include all three in the test. This is where you find out whether normalisation is needed and whether the output settings fit the material.
A local test can reveal decode, path and transition problems, but it cannot confirm that YouTube is receiving the stream correctly. Make a brief private or otherwise appropriate test in YouTube Live Control Room, then inspect the preview and stream-health messages. YouTube Help recommends testing before going live and monitoring stream health. If you want the process to continue overnight, first consider the practical limits of the host and connection described in running a 24/7 YouTube stream from a laptop with the lid closed.
For unattended use, plan how you will notice a stopped process, a missing file or a dropped connection, and who can restart it. FFmpeg looping an input does not by itself guarantee automatic recovery from every failure. Keep logs somewhere you can review, and test the restart procedure rather than relying on a command that has only run successfully once.
Set YouTube Live ingest options
In YouTube Studio's Live Control Room, create or select the stream and use its stream URL and stream key as the FFmpeg output destination. Treat the key like a password: do not publish it in an article, screenshot, shared script or log that others can access. YouTube documents stream-key management and reset options in its live streaming settings.
The command uses FLV output and an RTMPS URL as a common live-ingest pattern. YouTube Help says, “We recommend streaming to YouTube Live with RTMPS.” RTMPS encrypts the connection in transit; confirm the exact server URL and stream-key format shown for your broadcast in YouTube Studio rather than copying the placeholder in the example.
Choose codec, resolution, frame rate, bitrate and keyframe interval using YouTube's current live encoder settings. YouTube's live encoder guidance, accessed in 2026, lists recommended H.264 bitrates of 10 Mbps for 1080p at 30 fps, 12 Mbps for 1080p at 60 fps, and 6 Mbps for 720p at 30 fps. The same guidance recommends 128 Kbps for stereo audio, a keyframe interval of two seconds and CBR; it lists support for H.264, H.265 or AV1 video and AAC or MP3 audio, up to 60 fps. These are ingest recommendations, not guarantees of viewer quality. Check the current official table because guidance can change.
The example's 6 Mbps video setting happens to align with the cited 720p/30 H.264 recommendation, but it is not the right choice for every stream. Match the chosen output to the resolution and frame rate you actually encode, and consider the upload connection available where FFmpeg runs. YouTube advises choosing settings that suit a reliable connection; leave headroom beyond the stream bitrate rather than planning to use the entire measured upload capacity.
For a stream mixing clips with different aspect ratios, decide how to scale and pad or crop them before sending them. A single output size can simplify ingest, but cropping can remove important content and padding changes the presentation. The article on different video aspect ratios in a 24/7 YouTube stream explains the viewing trade-off. If your channel includes music, also check that you have the rights to stream each recording; a working FFmpeg pipeline does not determine whether a rights holder will claim or restrict content.
Troubleshoot format and connection failures
If FFmpeg reports that it cannot open an input, check the working directory, spelling, permissions and playlist quoting. Run a test that names the playlist directly and read the first error carefully. A typo in a later entry may only appear after earlier clips have played, so test the complete sequence before enabling an indefinite loop.
If the transition produces errors, compare the streams at each side of that boundary. Differences in codec, dimensions, frame rate, audio layout or time base point back to the compatibility decision: prepare common-format files or build a filter/re-encode path. Do not treat -safe 0 as a media-conversion switch; it addresses path restrictions, not stream mismatches.
If FFmpeg runs but YouTube does not show a healthy incoming stream, check the stream URL and key, the selected Live Control Room event, the output format and the network connection. Do not paste a key into public logs to make debugging easier. YouTube's preview and health messages help distinguish ingest problems from the case where the stream is received but a viewer experiences buffering; for the latter, see why viewers can see buffering when Live Control Room says excellent connection.
If output stutters or FFmpeg falls behind, determine whether the host can sustain decoding, filters and encoding at the selected settings. A re-encoding workflow can provide uniform output, but the machine has more work to do than in a compatible stream-copy workflow. Try a lower output resolution or a simpler filter chain in a test, and compare the result with YouTube's current ingest table. A network fault, a media decode issue and an overloaded encoder need different remedies; changing bitrate alone will not fix all three.
Make the operating choice that fits the channel
A local FFmpeg process gives you control of the playlist and command, but it also makes the computer, power, connection and process part of the broadcast chain. If the channel depends on a household computer staying available through the night, decide who will notice a failure and how the process will be brought back. The guidance on keeping a Punjabi songs YouTube Live stream running overnight is useful for thinking through that operating routine.
If the files are compatible and your host is reliable, a local playlist may be a sensible route. If the difficulty is specifically keeping a computer on and watching for a stopped broadcast, StreamNeo can remove that particular operational burden by letting you upload the video and provide your YouTube stream key for a stream that runs with your computer switched off. It is YouTube-only, and it does not decide whether your files are compatible, resolve content rights or guarantee an uninterrupted broadcast; prepare and test the media and channel as you would for any workflow.
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
How do I loop multiple videos in FFmpeg for YouTube Live?
Put compatible files in a concat playlist, then place -stream_loop -1 before the playlist's -i option to repeat the input indefinitely. Add output encoding and an RTMPS destination after the input, and test the sequence and ingest before relying on it.
Can I concatenate MP4 files with different resolutions or frame rates?
Do not assume the concat demuxer will reconcile them seamlessly. Normalise the clips to consistent output properties or use a filter/re-encoding workflow, then inspect the transitions in a test run.
Does FFmpeg reconnect automatically if YouTube Live drops?
A looping input means the media sequence repeats; it does not guarantee that every failed connection will recover. Plan to monitor the process and stream health, and test how you will restart the broadcast after a failure.
What bitrate should I use for YouTube Live?
Choose bitrate for the codec, resolution and frame rate you intend to send, using YouTube's current encoder guidance and the upload capacity where the encoder runs. YouTube's guidance accessed in 2026 recommends, for example, 6 Mbps for 720p at 30 fps and 10 Mbps for 1080p at 30 fps with H.264; check the official table for changes before going live.