To loop a folder of product demo videos on YouTube Live, put the clips in the order you want in an FFmpeg concat-demuxer list, then use -stream_loop -1 on that input. FFmpeg sends the resulting live feed to the RTMPS URL and stream key shown in YouTube Live Control Room; it is not YouTube replaying an uploaded playlist.
The details that decide whether the setup survives a full sequence are less glamorous: clip compatibility, path handling, an output format that matches YouTube’s current ingest guidance, and a test with the actual files. This guide gives you a reproducible starting point while leaving bitrate and other encoding choices to the resolution, frame rate, and codec you select.
Prepare and order the demo clips
Make a working folder and put only the intended demo assets in it. Give the files clear names such as demo-01.mp4, demo-02.mp4, and demo-03.mp4. A numbered naming scheme is easier to review than relying on whatever order your file manager displays. The playlist itself will establish playback order, but sensible filenames make accidental swaps less likely.
Before building the list, check that the clips can be concatenated directly. The FFmpeg concat demuxer reads files as one virtual input and expects their streams to match, including relevant codec, stream layout, and time-base properties. A folder containing an H.264 video with AAC audio, a clip with a different frame size, and a third with no audio may not behave as a clean sequence. FFmpeg’s concat demuxer documentation explains the matching requirements and notes that duration inaccuracies can produce artifacts at transitions.
If the source clips differ, standardise them before the live run or use a filter-based pipeline designed around their actual streams. Re-encoding each clip to a common size, frame rate, video codec, pixel format, and audio layout takes preparation, but it makes transitions more predictable. Do not assume that changing only the output options can resolve every mismatch in concat input files.
Also check the beginning and end of each clip. A demo that ends on a blank frame, exposes a desktop notification, or leaves several seconds of silence can be technically valid and still look unfinished. If product details, prices, or availability can change, decide whether the loop should use evergreen wording or whether someone will review and replace the files when those details change.
Create the concat-demuxer list
Create a plain-text file named videos.txt in the same folder as the clips. Put the header on the first line, followed by one file entry per clip in playback order:
ffconcat version 1.0
file 'demo-01.mp4'
file 'demo-02.mp4'
file 'demo-03.mp4'
The exact first line lets FFmpeg recognise the format automatically. Keep the list entries relative to the playlist’s directory when possible. This makes the folder easier to move and reduces the chance of the list referring to an old location on one computer.
Names containing spaces or punctuation need careful quoting and escaping. Start with simple filenames if you can. The concat demuxer applies safe-path checks by default; the example command below uses -safe 0 to allow paths that would otherwise be rejected. Use that setting only for a playlist you control, not for a list assembled from untrusted input. If you keep simple relative paths, check whether your installed FFmpeg accepts them with the safer default before adding -safe 0.
Open the text file and inspect the sequence yourself. The order in the file is the order viewers will see, and a duplicate line means a duplicate clip. If you later add a new demo, put it in the list explicitly rather than assuming FFmpeg will scan the folder and include it. This is also why a playlist is more reliable than asking a process to pick up every file matching a broad wildcard.
For a large collection, keep a separate copy of the playlist alongside the source files and name it by revision or purpose. Avoid changing the file while FFmpeg is reading it. To change the showcase, prepare a new list and restart the broadcast in a controlled way rather than editing live input and hoping the running process notices.
Loop the sequence with FFmpeg
The command below is an illustrative starting point for a compatible set of clips and an FFmpeg build with the required demuxer, encoders, and RTMPS support. It is not an official YouTube-prescribed command and has not been tested against your files. Replace the endpoint placeholder with the exact address arrangement required by the URL shown in your Live Control Room:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i videos.txt \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-b:v 4500k -maxrate 4500k -bufsize 9000k \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
The important placement is -stream_loop -1 before -i videos.txt: it applies to that input, and -1 means repeat indefinitely. -re paces file input at its native rate so it is sent in real time rather than as quickly as the computer can read it. The output options after the input describe the encoded feed.
You can check your local build before relying on the command. ffmpeg -version identifies the build; ffmpeg -protocols and ffmpeg -encoders can help establish whether the needed protocol and encoders are available. Package builds differ, so a command copied from another machine may fail if its FFmpeg lacks an encoder or RTMPS support.
The example assumes an audio stream is present. If your clips have no audio, remove the audio output options or add an intentional silent audio source, then validate the result on the installed build. Do not leave audio handling to guesswork: a missing or mismatched track can cause an error or an output that does not behave as intended.
The command is deliberately explicit, but the numeric encoding values are examples rather than universal settings. Choose them only after matching the output to YouTube’s current recommendations and your clips. If you want a different way to keep prerecorded material flowing, the playlist approach using a VPS covers a related operating pattern; the method in this article keeps the sequence in a local concat file.
Choose a YouTube-supported output
Your output has to suit both the clips and YouTube’s current live ingest guidance. YouTube’s encoder settings page lists supported codecs and guidance for frame rate, bitrate, keyframes, and audio. It includes H.264, H.265/HEVC, and AV1, up to 60 fps, and recommends a two-second keyframe interval, with a maximum interval of four seconds. Check the current table for the exact resolution, frame rate, and codec you intend to send; there is no single bitrate that fits every output.
For a straightforward product showcase, H.264 with AAC is a conventional starting choice when your FFmpeg build supports those encoders and the selected ingest path accepts them. The example uses a 30 fps output and a 60-frame GOP, which corresponds to a two-second interval at that frame rate. That relationship is why changing the frame rate without reconsidering the GOP value can make the keyframe interval differ from what you intended. Treat the sample settings as a worked configuration to evaluate, not as a promise of quality or a universal recommendation.
Think about resolution in relation to the source footage and the connection carrying the outgoing stream. Sending a higher resolution than the product footage supports does not restore detail. Conversely, reducing resolution or frame rate can lower the amount of data to encode and upload, at the cost of visible detail or motion smoothness. If the upload connection is shared with customers or staff, test during the conditions in which the channel will actually run.
| Choice | What to consider | Practical approach |
|---|---|---|
| Resolution and frame rate | Source quality, motion, and upload capacity | Start from the source; use YouTube’s current matching bitrate guidance |
| H.264 or another listed codec | FFmpeg encoder availability and ingest compatibility | Prefer a codec your installed build and chosen path both support |
| RTMP or RTMPS | Transport compatibility and encryption | Use RTMPS when available, following YouTube’s guidance |
| Audio output | Whether all inputs have audio and what viewers should hear | Confirm a consistent track or deliberately provide silence |
The stream-quality checklist for blurry 4K 60fps output is useful if you are weighing high resolution against what the connection and encoder can sustain. It is better to choose a modest, consistent output that matches the source than to select a large resolution because it sounds more professional.
Send the feed to YouTube Live
Create or open the live event in YouTube Live Control Room, then copy the stream URL and stream key shown for that event. YouTube’s encoder instructions describe where to find them and how to connect an encoder. The ordinary RTMP URL may be shown by default; if you intend to use RTMPS, reveal and copy the RTMPS address rather than assuming the default is already encrypted. YouTube explains RTMPS as RTMP over TLS/SSL in its RTMPS guidance.
How the URL and key fit together depends on the exact address YouTube gives you and how the installed FFmpeg build handles it. Some endpoint arrangements use a separate base URL and key; another URL may already include a path that should not be duplicated. Follow the current Live Control Room details and your FFmpeg protocol’s expected form. Do not append the key blindly to a URL that already contains it.
Treat the stream key like a password. Keep it out of screenshots, public support posts, committed scripts, and shell history where practical. If you use environment variables as placeholders in the example, set them privately for the session and avoid sharing the resulting command with the key expanded into it. If you think the key has been exposed, replace it in the control room before the next broadcast.
Once the event and endpoint are ready, start the FFmpeg process. The feed should arrive as an encoder input; it does not mean that a scheduled event is automatically public. In particular, YouTube’s instructions may require you to click Go live after the preview appears unless the event’s auto-start settings handle that step. A cloud relay can remove the need to keep a personal computer running, but with this local FFmpeg workflow, the machine running the command and its network connection need to remain available. StreamNeo is relevant when keeping that computer awake is the specific pain: it turns an uploaded video into a YouTube live feed without requiring your computer to run the broadcast.
Test playback and stream health
Do a test before you announce the event or leave it unattended. Use the actual playlist and endpoint, and watch the Live Control Room preview long enough to see more than the opening clip. Confirm the clips appear in the intended order, that the transition into the next file is acceptable, and that audio is present at a sensible level. This catches issues that a successful FFmpeg start alone cannot prove.
Check YouTube’s stream-health feedback while the encoder is sending. If the incoming feed is unstable, distinguish an encoding or upload problem from a playlist issue: a perfectly ordered local file does not fix an upload connection that cannot sustain the selected output. If the preview is clean but the public event has not started, check whether the event still needs a separate Go live action.
Let the test reach a clip boundary. That is where duration mismatches or incompatible media can surface as a pause, repeated frame, or audio discontinuity. If a test fails, stop FFmpeg, correct the source or playlist, and run the same check again. Do not treat a brief preview of the first seconds as evidence that a long loop will be trouble-free.
Plan how you will end the broadcast as well. Stop the FFmpeg process and end the YouTube event when the showcase is over. YouTube’s encoder instructions say streams under 12 hours are automatically archived; check the current official guidance for how your event’s duration and settings affect the archive. A live loop is a broadcast, not a permanent video file, and you should confirm that any replay appears as expected before relying on it.
For a channel that needs to keep running after a local machine restarts, the reboot restart guide addresses a different part of the operating problem. It does not replace testing the feed and sequence described here.
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 Live loop my uploaded product videos?
No. In this setup, FFmpeg reads the local clips in the order in videos.txt, repeats that input sequence, and sends it as a live encoder feed. YouTube receives a live broadcast; it is not looping an uploaded playlist as that broadcast.
Why use -stream_loop -1 with a concat list?
The concat list presents the ordered clips as one input, and -stream_loop -1 tells FFmpeg to repeat that input indefinitely. Keep the option before the corresponding -i so it applies to the playlist input rather than an output.
Can I mix clips with different formats?
The concat demuxer expects matching stream properties, so a mixed folder may fail or show transition problems. Standardise the clips first, or use a filter-based pipeline suited to the actual files; test the entire sequence before going live.
Must I use the sample bitrate and frame rate?
No. The command is an illustration, not a YouTube-mandated or tested configuration. Use YouTube’s current encoder settings for your chosen resolution, frame rate, and codec, and make sure your FFmpeg build and upload connection can support the result.