A looping FFmpeg command can repeat a finite video file for a YouTube Live broadcast. The key option is -stream_loop -1, placed before the input file's -i; -re then reads that file at its normal rate rather than sending it as quickly as the computer can process it.
That only solves end-of-file. It does not by itself repair a broken upload connection, a stopped FFmpeg process, an unsuitable encoder setting, or a YouTube event that has another problem. Treat the loop and the rest of the live operation as separate checks.
First establish what stopped
Before changing the command, find out whether FFmpeg reached the end of the file. A normal end-of-file is usually visible in the terminal output: the process finishes after the final timestamp, and the output stops without an input or network error. If the file is being sent once, this is the point where looping is relevant.
A disconnection looks different. You may see messages about a broken pipe, an input/output error, a timeout, a lost connection, or FFmpeg exiting while the source file still has content left. YouTube may also show a warning in Live Control Room while FFmpeg continues trying to write, or FFmpeg may stop after the ingest connection disappears.
This distinction matters because repeating the input cannot restore a network route or restart a process. If the stream stopped after an internet loss, adding -stream_loop -1 may leave the file ready to repeat but still fail to reconnect. If the process was killed because the machine ran out of memory or CPU, the input option does not address that cause either.
For a file that ends cleanly, note its duration and compare it with the stopping time. For an unrelated interruption, save the terminal output and the relevant YouTube stream-health message before making changes. Those details are more useful than repeatedly editing the command at random.
Put -stream_loop -1 before -i
The basic syntax is:
ffmpeg -stream_loop -1 -i input.mp4 ...output-options...
-stream_loop is an input option. The value -1 requests infinite repetition of the input, and it must appear before the -i that introduces that input. Placing it after the input can make it apply incorrectly or fail to produce the intended result. The FFmpeg documentation describes the option and its input scope.
For one local file, the position is straightforward. If a command has several inputs, place the option before the relevant -i, not merely somewhere near the beginning and assume FFmpeg will infer your intention. This is especially important when a separate audio file, logo, microphone, or other source is added later.
For example:
ffmpeg -stream_loop -1 -i devotional.mp4 \
...output-options... \
"rtmps://YOUR_YOUTUBE_INGEST/YOUR_STREAM_NAME"
This repeats devotional.mp4 when FFmpeg reaches its end. It does not create new content, repair an abrupt edit, or make a file suitable for every output format. If the first and last frames do not match visually or sonically, the transition may still be noticeable each time the file loops.
A file with a short fade at the beginning and end may make the transition less abrupt, but that is a media-editing decision rather than an FFmpeg uptime fix. For devotional, lofi, ambience, or study channels, listen to the exact join during a rehearsal. A quiet audio click can be more disruptive than a visible cut.
Add -re for a file-based live output
A local file can be read much faster than its intended playback speed. Without pacing, FFmpeg may consume the file rapidly and send output packets in a way that does not represent a normal live programme. Add -re so FFmpeg reads the file at its native frame rate:
ffmpeg -re -stream_loop -1 -i input.mp4 \
...output-options... \
"rtmps://YOUR_YOUTUBE_INGEST/YOUR_STREAM_NAME"
The FFmpeg documentation equates -re with -readrate 1 and explains that it limits reading to the input's native rate. For a prerecorded file being used as a live source, that is normally the behaviour you want.
Do not add -re automatically to every FFmpeg command. An actual live capture input is already arriving in real time, so slowing it as though it were a file may create a different problem. The flag is useful here because the source is a file and the destination is a live ingest.
Pacing and looping do different jobs. -stream_loop -1 decides what happens at end-of-file. -re decides how quickly FFmpeg reads the file between those loop points. You generally need both for a conventional file-based YouTube live stream.
Use a complete starting command
For a local MP4 source, this is a practical baseline to adapt:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-b:v 4500k -maxrate 4500k -bufsize 9000k -g 60 \
-c:a aac -b:a 128k \
-f flv "rtmps://YOUR_YOUTUBE_INGEST/YOUR_STREAM_NAME"
This is an illustrative template, not a tested universal preset. Replace the destination with the RTMPS ingest address and stream name supplied by YouTube for your configured stream. Do not paste a real stream key into a public script, tutorial, screenshot, or support post.
The command re-encodes the video with H.264 and the audio with AAC, places the result in an FLV output, and sends it to the supplied RTMPS destination. Re-encoding gives you control over the output codec, bitrate, and keyframe interval, but it uses CPU resources. If your computer is already close to its processing limit, the encoder can become the next cause of interruption.
The audio part deserves a specific check. If input.mp4 has no audio stream, -c:a aac -b:a 128k does not magically create useful audio. You may need to add an audio source, create silence deliberately, or adjust the mapping and output options. Run the command with a file that has the streams you intend to broadcast, then inspect FFmpeg's input summary before the upload begins.
If the source codecs, timestamps, resolution, and other properties already match the destination requirements, stream-copy may be considered. That can reduce encoding work, but it is not automatically reliable across loop boundaries or different files. Validate the result rather than assuming that copying will behave correctly for an unattended broadcast.
If you are building a longer FFmpeg workflow, the guide on running a continuous podcast stream with FFmpeg on YouTube covers related decisions around a file-based programme. For this command, keep the first test simple: one known-good file, one video stream, one audio stream, and one destination.
Keep the mapping and encoding options deliberate
Do not remove existing options simply to insert the loop flag. Put -stream_loop -1 before the input and retain the mapping, codec, bitrate, frame-rate, and format choices unless you have a reason to change them.
If the command already contains -map, inspect what each map selects. For example, a video-only map can exclude the audio you expected to send. A map referring to a second input can fail when you reduce the command to one file. The loop flag controls repetition of an input; it does not change which streams are selected.
The same applies to frame rate and the GOP setting. In the example, -g 60 represents a two-second keyframe interval when the output is 30 frames per second. If you use another frame rate, revisit that value. YouTube's current encoder guidance recommends a keyframe interval of two seconds and says it should not exceed four seconds. Check the current YouTube encoder settings before publishing because platform guidance can change.
YouTube lists H.264, H.265/HEVC, and AV1 as supported video codecs, and AAC or MP3 as supported audio choices in its encoder guidance. The sample uses H.264 and AAC because they are a common starting point, not because one command is correct for every computer or channel.
Bitrate should follow the actual resolution, frame rate, codec, and dependable upload capacity. YouTube's listed examples include 8 Mbps recommended for H.264 at 720p30 and 14 Mbps recommended for H.264 at 1080p30. Its table also gives different values for AV1 and H.265. These are YouTube's published configuration recommendations, not a promise that a particular connection or computer will sustain them.
For a modest 720p30 H.264 stream, the sample's 4,500 kbps video bitrate sits within the listed range but below YouTube's recommendation. That may be a reasonable starting point when upload headroom is limited, but measure the connection and watch stream health. Do not select a bitrate merely because it appears in a copied command.
If your computer struggles with the chosen encoder, the stream can become unstable even when the network is fine. Lowering output complexity, changing the preset, reducing the resolution, or using supported hardware encoding may help, but each change should be tested. The practical goal is a stable output that fits both the machine and the connection.
Check the YouTube destination
The final argument must point to the live ingest destination for the stream you configured. Do not invent a hostname or copy a destination from an unrelated tutorial. Obtain the current RTMPS address and stream name from YouTube Live setup. The YouTube LiveStreams API documentation also describes the primary ingestion address and stream name associated with a configured live stream.
Depending on the encoder, YouTube may show these as separate fields or as a URL and stream name that are joined with a slash. In the shell command, they appear as one quoted output URL, such as:
"rtmps://YOUR_YOUTUBE_INGEST/YOUR_STREAM_NAME"
Keep the stream key private. If it is exposed, someone else may be able to send content to the event. If you have published it accidentally, use YouTube's current controls to replace or reset it before testing again.
Confirm that the selected live event is the one you intend to use and that its settings match the output you are sending. A valid FFmpeg command cannot correct a mistaken event selection or an account-side restriction. YouTube's Live Control Room should be part of your check, not an afterthought at the terminal.
For a channel run from India or another location with variable upload capacity, test from the same connection and at a similar busy period to the one in which you expect to operate. The upload speed available to the computer is the relevant constraint, not the headline speed of a broadband plan. YouTube recommends checking upload capacity and monitoring stream health.
Test the loop before relying on it
YouTube Help says, “Make sure to test before you start your live stream.” Treat that as an operational step rather than a formality. Start with a private or otherwise appropriate rehearsal in Live Control Room, then confirm that the incoming video and audio are present and that the stream-health indicators remain acceptable.
Use a file that represents the real programme. Include the normal movement, quiet sections, speech, music, and any captions or graphics that viewers will see. A static test clip may conceal an encoding or audio problem that appears when the real file contains more motion.
Watch through the end of the source file and into the next pass. Check for:
- a visible freeze or black frame at the join
- an audio click, gap, or sudden level change
- a timestamp warning or growing delay in the FFmpeg terminal
- CPU, memory, or temperature pressure on the computer
- upload instability or a YouTube stream-health warning
- an unexpected process exit after the first pass
Keep the terminal open during the rehearsal. The final line alone may not explain what happened several minutes earlier. If you need to compare attempts, save the relevant output, but redact the stream key and other private account details.
A short test can show that the file repeats, but it cannot establish that a machine, network path, FFmpeg process, or YouTube event will remain healthy indefinitely. For a channel that matters overnight, use monitoring and a recovery plan appropriate to your setup. The article on reducing OBS CPU usage during a 24/7 YouTube stream is relevant when another encoder is competing for the same computer's resources.
If you do not want to leave a personal computer running, StreamNeo removes the need to keep the local machine on after you upload the file and connect the YouTube stream, while still leaving the channel and platform checks to you. It is a YouTube-only route for the specific problem of keeping a prepared file available without maintaining an active desktop session.
Diagnose interruptions that looping cannot fix
If the stream stops before the file reaches its end, investigate the other layers in order.
Input and file. Confirm that the file can play from beginning to end locally and that FFmpeg can read it without decoder errors. A damaged file, unsupported stream, changing timestamps, or missing audio can cause trouble unrelated to looping.
Encoding. Look for sustained high CPU use, dropped frames, encoder errors, or a growing delay. Re-encoding a high-resolution file while doing other work on the same machine may leave too little capacity. Test a simpler output rather than assuming the network is at fault.
Upload path. Check whether the connection is dropping or losing upload headroom. Wired networking may be preferable where practical, but no connection method is guaranteed to remain healthy. A router restart, local congestion, or an upstream outage can interrupt the ingest even though FFmpeg is still running.
Destination and event. Check YouTube's stream-health panel and event status. A rejected or disconnected ingest, an incorrectly selected event, or an account-side issue needs attention in YouTube rather than another input flag.
Process recovery. If FFmpeg exits, a supervisor or scheduled restart strategy may be needed for your operating system. The exact command depends on whether you use Windows, Linux, macOS, a VPS, or another environment, so do not paste a generic service configuration into production without testing it. The VPS versus managed service comparison explains why unattended operation involves more than the encoder line.
A looping input is one component of a continuous channel. It addresses a finite file reaching EOF, while monitoring, reconnection handling, process supervision, source quality, upload capacity, and YouTube's current policies address other failure modes. Keep those responsibilities separate when you troubleshoot.
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 -stream_loop -1 loop the output forever?
No. It requests infinite repetition of the selected FFmpeg input. The output can still stop if FFmpeg exits, the computer fails, the network disconnects, the destination rejects the ingest, or the YouTube event has another issue.
Where does -stream_loop -1 go in the command?
Put it before the relevant input declaration, for example -stream_loop -1 -i input.mp4. It is an input option, so its position matters when the command contains more than one input.
Do I need -re with a local video file?
For a prerecorded file used as a live source, -re normally helps FFmpeg read it at its native rate. Do not apply it indiscriminately to an input that is already a live capture, because that source is already arriving in real time.
Why did the stream stop even though the file was looping?
The interruption may have come from the upload connection, encoder load, a file or timestamp error, the RTMPS destination, or the YouTube event. Check the FFmpeg terminal and YouTube stream-health information to identify which layer failed before changing the loop option.