A continuous YouTube product demo stream can be built with FFmpeg by placing compatible files in a concat playlist, looping that input indefinitely, pacing playback in real time, and sending the encoded output to YouTube Live over RTMPS. Your computer, files, network connection and YouTube ingest settings must all remain suitable for the workflow; the command alone cannot guarantee uninterrupted delivery.
The practical sequence is to prepare the demos first, test the concat playlist locally, then connect FFmpeg to the server URL and stream key shown in YouTube Live Control Room. Treat the stream key as a password, and use YouTube's preview and stream-health information before making the broadcast public.
Prepare compatible demo files
Start with the media rather than the command. A playlist is only as dependable as the files it reads, and FFmpeg's concat demuxer is not a general-purpose converter that can join arbitrary videos cleanly.
For the simplest workflow, make the demos consistent in their main technical properties:
- the same video codec
- the same audio codec
- the same frame size
- the same frame rate
- the same stream layout
- compatible time bases and timestamps
- reliable duration metadata
For example, three product demos might all be MP4 files containing H.264 video, AAC audio, 1920×1080 frames and 30 frames per second. If one file has no audio, another uses a different frame rate, and a third has unusual timestamps, the concat demuxer may produce warnings, gaps, incorrect transitions or other artefacts.
You can inspect files with ffprobe, which is distributed with FFmpeg. Keep the output for each file and compare the video and audio streams rather than relying only on the filename or what a media player appears to show. A file that plays normally on your desktop can still have metadata that makes sequential concatenation unreliable.
If your source files do not match, normalise them before creating the final playlist. That may mean re-encoding the demos to a common resolution, frame rate, codec and audio arrangement. It takes another processing step, but it moves the difficult compatibility problem away from the overnight broadcast.
Do not alter the original files while testing. Create a separate set of normalised copies, give them simple names such as demo-01.mp4, and keep the source files elsewhere. This makes it easier to replace one demo without accidentally changing the files used by the live command.
The demos should also be content-ready. Check that the final frame of one video does not leave a long silent pause, that product names and prices are current, and that the audio is understandable at the intended viewing volume. If your channel contains a sales sequence, write down the order separately from the technical playlist so a later content change does not require guessing which file is next.
For a broader explanation of the operating choices around prerecorded broadcasts, see how to stream pre-recorded video to YouTube Live from a cloud server. A local FFmpeg process and a cloud-based workflow solve different problems, so decide where the encoder should run before you prepare a permanent schedule.
Create the concat playlist text file
Create a plain text file called playlist.txt in a working directory. Each media file gets one file line, in the order in which it should appear:
file 'demo-01.mp4'
file 'demo-02.mp4'
file 'demo-03.mp4'
The paths are interpreted by the concat demuxer. Relative paths are normally resolved from the location of the playlist file, which makes a folder containing both the manifest and the demos easier to move and test. You can also use absolute paths when needed, but keep the manifest under your control.
A filename containing spaces can be written using the concat demuxer's quoting rules, for example:
file 'demo summer stand.mp4'
file 'demo checkout flow.mp4'
Special characters and quotation marks need more care. Test the actual manifest on the machine that will run FFmpeg rather than assuming that shell quoting and concat-file quoting mean the same thing. The playlist is its own text format, and the shell does not interpret every character in it for you.
The -safe 0 option is often used when the manifest contains paths that FFmpeg would otherwise reject as unsafe. It relaxes the concat demuxer's path-safety restrictions, so use it only with a playlist you created and inspected. Do not point it at a text file that could have been edited by an untrusted user or downloaded from an unknown source.
A useful local check is to create a short output from the manifest before you attempt a live connection:
ffmpeg -f concat -safe 0 -i playlist.txt -c copy playlist-check.mp4
This is a diagnostic starting point, not proof that the final live encode will be healthy. If the files are compatible, stream copying can show whether the sequence opens and whether the transitions occur in the expected order. If it fails, fix the media or manifest before adding looping, encoding and YouTube ingest.
The check may also expose a duration problem. The concat demuxer uses duration information when it adjusts timestamps between files. Incorrect duration metadata can result in a gap, an overlap or a brief visual or audio problem at a transition. A media player that hides the issue is not sufficient evidence that a continuous stream will behave correctly.
Check concat demuxer compatibility
The concat demuxer reads the listed inputs as one sequential media input. It expects the files to have matching streams, codecs and time bases. That requirement is stricter than simply having the same .mp4 extension or the same visible resolution.
Before streaming, compare at least these properties:
| Property | Why it matters | What to do when it differs |
|---|---|---|
| Video codec | The output may not transition cleanly between different stream types | Re-encode the files to one video codec |
| Audio codec and presence | A missing or different audio stream can disrupt the sequence | Give every file a matching audio stream |
| Frame size | Changing dimensions can create an invalid or awkward transition | Scale or crop to one output size |
| Frame rate | Different timing can produce timestamp or pacing issues | Convert to one frame rate |
| Time base and timestamps | The demuxer relies on timing information between files | Normalise timestamps and test transitions |
| Duration metadata | Incorrect durations can create gaps or artefacts | Repair or re-encode the affected files |
The table describes preparation decisions, not a universal repair command. The correct normalisation settings depend on the source media and the output you want. If the demos were exported by different editing applications, inspect them individually instead of assuming they share a format.
You may choose to encode the final output with libx264 and AAC even when the inputs are already compressed. That does not remove the need for compatible concat inputs. The concat demuxer must still read the sequence successfully before the output encoder receives it.
To isolate a troublesome item, build smaller manifests. Test demo-01.mp4 with demo-02.mp4, then add the third file, and so on. This can identify the transition that introduces a warning. Keep notes about the FFmpeg version, file names and warning messages, because a later change in the media set may otherwise look like a network problem.
If you are deciding between FFmpeg and a graphical workflow, streaming a playlist on YouTube with OBS may be easier for a one-off operator who wants a visible preview and manual scene controls. FFmpeg is more direct and scriptable, but it exposes more of the media and process details that you must test yourself.
Loop the playlist and pace playback in real time
Once the manifest works locally, add two input options: -stream_loop -1 and -re. The first tells FFmpeg to repeat the input indefinitely. The value -1 means infinite looping. The second reads the input at its native rate rather than processing a prerecorded file as quickly as the computer can decode it.
Place both options before the concat input:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-b:v 14M -maxrate 14M -bufsize 28M -g 60 \
-c:a aac -b:a 128k -ar 44100 \
-f flv 'rtmps://YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
This is a starting example for an illustrative 1080p30 H.264 stream, not a universal preset. The 14M video rate and -g 60 GOP setting need to match the actual resolution, frame rate, source content, upload capacity and YouTube guidance you are following. Do not copy the values blindly for a 720p stream, a different frame rate or a network with less available capacity.
The order matters. -re and -stream_loop -1 are input options, so putting them after -i playlist.txt does not express the same operation. The concat format declaration also belongs with the input. Output options such as the video codec, audio codec and FLV format are placed after the input.
-re is especially important for a live destination. Without real-time pacing, FFmpeg can read a file faster than its intended duration and send data in bursts. That is suitable for some file conversions but not for representing a live clock to YouTube. Real-time pacing does not repair incompatible timestamps or a weak upload connection; it only controls the rate at which FFmpeg reads the input.
-stream_loop -1 repeats the concat input rather than stopping after the last listed file. It does not mean that every individual file has been validated, and it does not make a crashed process restart. If FFmpeg exits or the network connection fails, a separate operational plan is needed.
Use FFmpeg's format documentation and the documentation for the FFmpeg build you install when checking option behaviour. Command-line details can vary with version and platform, so test the exact command on the machine intended for the broadcast.
Encode for the YouTube Live ingest path
In YouTube Live Control Room, create or select the live stream and copy the server URL and stream key that YouTube provides. The example uses an RTMPS-style destination and an FLV output because that is the conventional software-encoder path for a standard SDR stream. Replace the placeholders only on the machine running FFmpeg.
YouTube's current encoder guidance lists H.264, H.265 and AV1 video, and AAC or MP3 audio for the relevant live workflows. It also recommends constant bitrate encoding and a keyframe interval of two seconds, with no more than four seconds. Check the official YouTube encoder settings guidance before choosing a codec or changing the output settings, because YouTube's requirements and recommendations can change.
For H.264 at 1080p30, YouTube lists 14 Mbps as a recommended video bitrate. For 720p30, it lists 8 Mbps. These are guidance figures, not a reason to force every product demo into 1080p. Match the output to the source and leave upload capacity above the total stream bitrate. YouTube recommends 20% upload headroom, so a connection that barely matches the configured video and audio rates is not a sensible operating margin.
The illustrative command uses -b:v 14M, -maxrate 14M and -bufsize 28M. Those settings express a constant-rate starting point for the example, but they do not measure your real connection or confirm that the encoder can keep up. Watch the machine's CPU load, outbound network behaviour and YouTube's stream-health messages during a representative test.
The command uses -c:v libx264, -pix_fmt yuv420p, AAC audio at 128k, and a 44.1 kHz audio rate. These choices are practical examples for a conventional product-demo feed. They are not a promise that every source, FFmpeg build or YouTube configuration will accept the same combination without adjustment.
RTMPS is the straightforward choice for a typical SDR product-demo stream when your selected codecs and settings fit that ingest path. HLS is a different protocol and output workflow. YouTube describes HLS as useful for cases such as HDR or codecs not supported by RTMP, but it has higher latency because it sends segments. It also uses an HTTPS-based request flow, transport-stream segments and a rolling playlist, rather than accepting an ordinary FLV RTMP command. Do not send the command above to an HLS endpoint.
If you are using FFmpeg on a home or office computer, remember that the live output depends on that computer staying powered, connected and able to encode. A laptop that sleeps, changes networks or installs updates overnight is not an equivalent operating environment to a deliberately maintained broadcast machine. For a cost and responsibility comparison, see what 24/7 streaming really costs.
Protect the stream key and test the feed
A YouTube stream key grants access to the ingest destination associated with it. Treat it like a password. Do not paste a real key into a public tutorial, source repository, support ticket, screenshot or shared shell history.
Keep the command in a private file with appropriate access controls, or provide the key through a protected environment or secret-management method suitable for your operating system. Do not put it in a playlist file or content folder that other people can edit. If you believe the key has been exposed, reset it through YouTube Live Control Room and update the private command.
A short private or unlisted test is more useful than inspecting the FFmpeg console alone. Start the encoder with representative demo footage that includes motion, transitions and normal audio. Then check the preview in Live Control Room, confirm that the video and audio arrive together, and watch the stream-health warnings during transmission.
YouTube's guidance says to test before starting the live stream. Follow that advice after any meaningful change to the media, FFmpeg command, encoder machine, network or ingest configuration. A process that continues printing output is not proof that YouTube is receiving a healthy stream.
Check the first transition between files, the transition back to the first file, text readability, audio continuity and the selected resolution. Leave the test running long enough to exercise more than the first file. If a problem appears only at a transition, return to the compatibility and duration checks rather than treating it as an ingest failure.
A normal FFmpeg run also needs an operational response plan. Decide who will notice a stopped process, where logs will be kept, how the machine will reconnect to the network, and how the stream will be stopped deliberately. The concat loop does not automatically restart a process after a crash, and the evidence available here does not establish a universal recovery recipe for every FFmpeg build, media set or network.
If you want a continuously running channel without leaving a personal computer powered and connected, StreamNeo removes the specific task of keeping the local encoder machine running: upload the prepared video, provide the YouTube stream key, and the broadcast can run from the cloud with monitoring and automatic restart behaviour. You still need to check your content, YouTube access and stream result, and you should not treat any service as a substitute for testing.
Plan the broadcast beyond the first loop
A product-demo playlist can be technically continuous while still becoming stale. Maintain a simple content register with each file's purpose, product version, claims, prices and review date. When a product changes, replace and retest the affected file rather than editing the live directory without checking the next transition.
Do not assume that changing playlist.txt while FFmpeg is already running will safely alter the current broadcast. The material reviewed for this workflow does not establish a general live playlist-update method. Stop and restart through a tested procedure, or use a workflow designed for controlled content changes.
Also separate broadcast continuity from replay and archive planning. YouTube describes continuous live streams from an existing content library, and says streams under 12 hours are automatically archived. That statement does not establish the same archive behaviour for a stream longer than 12 hours. If you need a replay, plan its duration and recording requirements separately rather than assuming that an indefinitely looping feed will produce one complete archive.
If your channel is intended to run for a full day or longer, review the platform considerations in the complete 24/7 YouTube streaming guide. It is particularly important to distinguish a looping file from a service that can observe, restart and maintain the encoder process. Neither approach removes the need to monitor the actual YouTube broadcast.
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 concatenate any MP4 files?
No. The concat demuxer expects compatible streams, codecs and time bases, and it relies on duration information when adjusting timestamps. Normalise files that differ, then test the actual manifest before sending it to YouTube.
Where do -re and -stream_loop -1 go?
Place both before -i playlist.txt because they control how FFmpeg reads the input. -re paces file reading at the native rate, while -stream_loop -1 repeats the concat input indefinitely.
Is the YouTube stream key safe to put in a script?
A private script can be practical, but the key must be protected like a password. Keep the script inaccessible to other users, avoid publishing it or committing it to a repository, and reset the key in Live Control Room if it may have been exposed.
Will this command guarantee an uninterrupted 24/7 stream?
No. It does not guarantee that the source files, encoder, computer, network or YouTube ingest will remain healthy. Test the media and preview, monitor stream health, and create a separate response plan for process, connection and platform failures.