You can use FFmpeg to join local video files into a playlist, repeat that playlist, encode the result and send it to YouTube Live. The basic setup is reproducible, but it is not a guarantee of uninterrupted broadcasting: your computer, power, network, files, FFmpeg process and YouTube ingest all still need to work.
The safest approach is to separate the work into two parts. First, prepare and test the playlist without involving your stream key. Then configure YouTube Live, connect FFmpeg, watch the preview and monitor the process before treating the channel as unattended.
How the FFmpeg-to-YouTube workflow works
There are five parts to the workflow:
- You prepare a group of local media files.
- You list those files in an FFmpeg concat-demuxer playlist.
- FFmpeg reads the playlist at normal playback speed and loops it.
- FFmpeg encodes or copies the media into a YouTube-compatible output.
- FFmpeg sends that output to YouTube over the server URL and stream key.
The playlist is not a YouTube playlist. It is a plain text file on your computer that tells FFmpeg which files to read and in what order. You can change the order without rebuilding the video files, then restart FFmpeg to use the revised list.
The -stream_loop -1 option tells FFmpeg to repeat its input indefinitely. That means the input can return to the first file after the final file, but it does not supervise FFmpeg, restore a failed computer, repair a damaged file or reconnect every possible network failure.
The output is normally sent to an RTMPS address supplied by YouTube. YouTube recommends RTMPS as a secure extension of RTMP in its encoder settings documentation. Your chosen bitrate must be sustainable on the actual upload connection, not merely possible during a short speed test.
This arrangement is useful for a devotional channel with a sequence of recordings, a lofi station with visual loops, a local news replay, or a small business product demonstration. It is less suitable when the content must be changed immediately from a control room or when you need built-in failover without separately designing that system.
If you are still deciding whether local hardware is the right fit, the comparison in cloud streaming versus a PC for YouTube creators in India is a useful place to start. The trade-off is straightforward: FFmpeg gives you control and avoids a separate graphical application, but you remain responsible for the machine that runs it.
Prepare and check your media files
Start with the actual files you intend to broadcast, rather than testing with a single convenient sample. A file that plays correctly in a desktop player can still expose a codec, timestamp, resolution or audio-layout problem when it is joined to another file.
For a reliable concat-demuxer workflow, keep the library consistent. Matching files should normally have the same video dimensions, frame rate, pixel format, audio sample rate, channel layout and stream order. Matching codecs and compatible time bases also matter. The closer the files are to one another, the fewer surprises you are likely to see at a transition.
You can inspect a file with ffprobe, which is included with many FFmpeg distributions:
ffprobe -hide_banner video-01.mp4
Look for the video codec, width and height, frame rate, pixel format, audio codec, sample rate and channel count. Repeat the check for every file that will enter the playlist. You do not need to memorise every field, but you should notice obvious differences such as one file being 1920×1080 at 30 frames per second while another is 1280×720 at 25 frames per second.
A file with no audio is also different from a file with stereo audio. If you send a mixed collection directly through the concat demuxer, FFmpeg may fail at the transition or produce output that does not behave as expected. Normalising the library into a common format before building the final playlist is often easier than debugging a heterogeneous playlist while live.
Check the files for practical problems as well. Play each one from beginning to end, listen for silence or clipping, check that the first and final frames are intentional, and look for a black frame or abrupt change at the end. A rotating stream repeats defects as reliably as it repeats good content.
If your source files have different sizes or codecs, you can create consistent intermediate files by re-encoding them. Another option is an FFmpeg filter workflow that scales and pads video, resamples audio and maps the streams explicitly. That approach is more flexible, but it is also more complex and needs transition testing. FFmpeg’s format documentation explains the concat demuxer and its requirements.
Do not assume that a still image or an audio-only track can be added to the example command unchanged. You need to generate or provide the missing video or audio stream, then map the resulting streams. For a first overnight test, use complete video files with the same basic structure.
Build a concat-demuxer playlist
Create a text file called playlist.txt in a working directory. A simple playlist looks like this:
ffconcat version 1.0
file 'video-01.mp4'
file 'video-02.mp4'
file 'video-03.mp4'
The first line identifies the concat format. Each following line names one input file, in the order in which it should play. Relative filenames make the directory portable: keep playlist.txt and the media files together, then run FFmpeg from that directory.
The concat demuxer uses safe path checking by default. Simple relative paths such as the example above fit the default safe subset. Absolute paths, parent-directory references and other path forms may be rejected. You can either move the files into a suitable working directory or review the safe option before changing it.
A playlist containing trusted local paths can be used with -safe 0, but that option relaxes FFmpeg’s path checks. It should not be treated as a harmless default, particularly if the playlist can be edited by another person or generated from untrusted input. If relative filenames work, leave the safety setting at its default.
Test the playlist without sending anything to YouTube:
ffmpeg -re -stream_loop 0 -f concat -i playlist.txt -f null -
This reads the playlist once and writes no useful media output. Watch the terminal for missing files, invalid timestamps, decoder errors and failures at each transition. You can also use a short output file while checking the first complete pass:
ffmpeg -f concat -i playlist.txt -c copy playlist-test.mp4
Stream copying in this test is only appropriate when the files already meet the concat requirements. If the command reports incompatible streams, fix or normalise the source library instead of hiding the error in the live command.
Keep a backup copy of the playlist and use clear filenames. A numbered naming scheme such as morning-01.mp4, morning-02.mp4 and evening-01.mp4 makes it easier to identify the current order. Remember that editing playlist.txt does not usually alter an FFmpeg process that has already opened it. Stop and restart the process after changing the list, then test the new order.
Loop the playlist with FFmpeg
Once the single-pass test works, use a command shaped like this:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -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 'rtmps://SERVER-URL/STREAM-KEY'
Replace SERVER-URL and STREAM-KEY with the values from YouTube Studio. The command is an illustrative starting point, not a universal recipe for every computer or source library.
-re makes FFmpeg read file input at approximately its normal playback rate instead of sending it as quickly as the machine can decode it. Without it, a prerecorded file can be consumed much faster than real time. -stream_loop -1 repeats the concat input. -f concat selects the concat demuxer, and -f flv selects the output container commonly used for the YouTube ingest connection.
The example re-encodes video with H.264 and audio with AAC. That consumes processing resources, but it gives the output a predictable codec combination when your source files are varied within the limits of the input workflow. Check that your FFmpeg build includes the encoder you select:
ffmpeg -encoders
If libx264 or another chosen encoder is unavailable, use an encoder present in your build or install a suitable current FFmpeg package. Hardware encoders can reduce CPU use on supported machines, but they have their own quality, driver and configuration differences.
The example uses a 4,500 kbps video rate as a starting value only. Your resolution, frame rate, visual motion and sustained upload capacity determine whether that is appropriate. Do not copy it simply because it appears in an example. Compare the selected output with YouTube’s current bitrate and resolution guidance, and leave headroom rather than matching the peak result of a speed test.
At 30 frames per second, -g 60 requests a keyframe interval of about two seconds. YouTube recommends a two-second keyframe frequency and says it should not exceed four seconds. At 60 frames per second, a two-second interval would be represented by -g 120. These settings need to agree with the actual frame rate you send.
If all files are already compatible, stream copying can reduce encoding work:
ffmpeg -re -stream_loop -1 -f concat -i playlist.txt \
-c:v copy -c:a copy -f flv 'rtmps://SERVER-URL/STREAM-KEY'
Use this only after testing the real files. Stream copy does not repair mismatched resolutions, frame rates, codecs, timestamps or audio layouts. Re-encoding is usually the more predictable choice when the library comes from several sources.
Choose compatible audio and video handling
The right output settings depend on what you are broadcasting. A devotional video library may already contain complete stereo video files. A lofi station may use long visual loops with a separate audio source. A business catalogue may contain clips recorded on different phones. These cases should not all be forced through the same assumptions.
For a consistent video library, choose one output resolution and frame rate, then normalise the files before the final run. Scaling every source during the live process can increase CPU use and make a weak machine more likely to fall behind. Preparing intermediate files also gives you a chance to inspect the result before it reaches YouTube.
Audio deserves the same attention. Check whether each source has stereo, mono or multiple audio streams. If the playlist alternates between different layouts, explicitly map the intended audio stream or normalise the files. YouTube’s guidance lists 128 kbps as its recommendation for stereo AAC audio. That is a documented recommendation, not a requirement that makes every source sound good; poor source audio remains poor after encoding.
If you need to keep a source stream unchanged, use -c copy only when the complete playlist and the destination requirements have been validated. It saves encoding work but gives you less control over output consistency. If you use filters, scaling, audio resampling or overlays, the streams must be encoded rather than copied.
A black frame between videos is often caused by the source files themselves, a transition in the processing chain or a mismatch in the playlist. It is not solved by adding a loop flag. Review the final seconds of one file and the first seconds of the next, then test the exact concat path. For more practical transition advice, see how to prevent black frames between videos on a YouTube loop stream.
For a low-motion channel, lowering output complexity may reduce processing load, but the change should be checked against YouTube’s current guidance and your viewers’ needs. A smaller, stable output is generally more useful than a larger output that regularly drops frames or exhausts the upload connection.
Connect FFmpeg to YouTube Live
In YouTube Studio, open Create → Go Live, then create or schedule an encoder stream. YouTube provides a server URL and a stream key for the encoder. Its help page describes stream keys as “like your YouTube stream’s password and address”. Treat the key as confidential credential material.
Do not place the key in a public repository, a tutorial screenshot, a shared chat message or a script that is uploaded with other project files. If you think it has been exposed, reset it in Live Control Room and update the command. A key can be copied by someone else even if the rest of the command looks harmless.
Keep the playlist setup separate from the YouTube configuration. You should be able to validate playlist.txt, the input files and the local FFmpeg output before adding the server URL and key. This separation makes troubleshooting much clearer: an input error is different from an authentication problem, and an encoder failure is different from an ingest failure.
Store the final command in a private, protected location, or supply the sensitive part through an environment variable or another method appropriate to your operating system. Avoid printing the key into logs that are routinely shared. Check the exact RTMPS address provided by the current Live Control Room rather than inventing a server path.
When the command starts, FFmpeg should show that it has opened the input and connected to the output. A successful connection does not prove that viewers are receiving healthy video. Continue to the preview and stream-health checks before making the broadcast public.
If maintaining the machine is the part you do not want to manage, StreamNeo removes the need to keep your own computer running for this particular uploaded-video-to-YouTube workflow, while you still need to prepare the file, provide the key and verify the broadcast.
Test the preview and monitor the stream
Use a private or unlisted test before committing a public channel to the setup. Start FFmpeg, open Live Control Room and wait for the incoming preview. Check the picture, audio, aspect ratio, motion, transitions and approximate timing. Do not treat the presence of a preview thumbnail as proof that a long broadcast will remain healthy.
YouTube’s live-streaming troubleshooting guidance recommends testing the encoder and monitoring stream quality. Use the health indicators in Live Control Room, and compare them with the FFmpeg terminal rather than relying on only one view of the system.
Watch for these signs during the test:
| What you see | Likely area to inspect |
|---|---|
| FFmpeg exits immediately | Playlist path, missing file, unsupported encoder or invalid option |
| Errors at a transition | Mismatched streams, timestamps, codecs or damaged input |
| Video reaches YouTube but audio is absent | Missing audio stream, incorrect mapping or incompatible source layout |
| Dropped frames or unstable health | Upload capacity, network congestion, encoder load or an unsuitable bitrate |
| Preview is delayed or unavailable | Stream configuration, key, server URL or YouTube ingest state |
| CPU remains very high | Re-encoding settings, resolution, frame rate or hardware capability |
Keep the terminal output available. FFmpeg reports decoder errors, encoder errors, connection failures and other useful details. If you run the process in a terminal that closes when you sign out, the stream will stop with it. A long-running setup therefore needs an appropriate session arrangement or service manager, but that is process management rather than something -stream_loop provides.
Test a complete cycle through the playlist. A three-file test is not complete when the third file has started; it is complete when the output returns to the first file and the transition remains clean. If your library is long, test representative files from the start, middle and end, then run the full cycle before publishing.
For channels aimed at viewers in India, measure your sustained upload at the location where the encoder will run. A connection can show a good peak speed and still fluctuate during the hours when you need the channel most. This bitrate testing checklist can help you structure that check. Leave room for normal household or office traffic, or isolate the streaming connection where practical.
You should also decide what happens when FFmpeg stops. A service manager or watchdog may restart a failed process, but a restart can interrupt the broadcast or require a new ingest session. It does not provide power backup, internet failover or YouTube recovery by itself. Add such measures only after the basic playlist, encoder and monitoring workflow is stable.
If your priority is reducing local electricity use rather than learning every FFmpeg option, compare it with ways to reduce electricity use when streaming prerecorded videos on YouTube 24/7. The best choice depends on the cost and reliability of the computer, power and connection you already have.
YouTube says streams under 12 hours are automatically archived. Do not extend that statement into a promise that an uninterrupted 24-hour stream will be archived in full. If the recording matters, keep a local copy or another recording plan and check YouTube’s current archive behaviour before relying on it.
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 loop a playlist forever?
-stream_loop -1 requests infinite looping of the input. It does not guarantee that the FFmpeg process, computer, power supply, network or YouTube ingest will remain available, so you still need testing and monitoring.
Do all files in the playlist need the same format?
They should have compatible streams, codecs, parameters, time bases and layouts for the concat demuxer to behave predictably. If they differ, normalise them first or build a filter and re-encoding workflow, then test the transitions with the actual files.
Should I use -c copy or re-encode?
Stream copying can reduce processing work when every input is already compatible and acceptable to YouTube. Re-encoding gives you more control over codec, frame rate, resolution, audio and keyframe settings, but it uses more processing capacity.
Is a 24/7 FFmpeg stream unattended once the command starts?
No. A running command still depends on the host, files, process, network and YouTube ingest. Watch the Live Control Room health indicators and FFmpeg logs, and separately test any restart or failover arrangement before relying on it.