If an FFmpeg stream reaches the end of a prerecorded file, -stream_loop -1 should make that input repeat indefinitely. The option must be placed before the input's -i; if the command still ends, inspect FFmpeg and YouTube separately rather than assuming the loop flag failed.
For a file being sent as a live feed, -re is also important because it makes FFmpeg read the file at its native frame rate. These two options address input handling and pacing, but they do not repair an encoder crash, a broken network connection, an invalid stream key, or a YouTube broadcast setting.
Check whether the source reaches its end
Start by deciding what actually stopped. A prerecorded file ending normally is different from FFmpeg terminating with an error, and both are different from FFmpeg remaining open while YouTube stops receiving the feed.
A simple command without looping will normally read the file once and then finish. Depending on the other options, FFmpeg may print progress until the final frame, close the output, and return you to the shell. That is an orderly end. It does not show that YouTube interrupted the stream or that the encoder crashed.
Look at the final lines printed by FFmpeg. Keep the complete terminal output rather than only copying the first warning. The ending may show that the input reached its duration, that an output duration was imposed, that the shortest stream ended, or that an encoder or output error occurred. You cannot identify the cause reliably from the fact that the YouTube page stopped changing.
Check the source file as well. Confirm that it opens from the path used in the command, has the expected video and audio streams, and plays through to its end in a local player. A damaged file can fail before the loop is tested. A file with no audio may also expose an assumption in a command that maps or encodes an audio stream.
If you use separate video and audio files, treat them as separate inputs. Looping the video does not automatically loop a finite audio input. When the command has more than one -i, identify which input supplies each output stream and whether every required finite input has an appropriate loop setting. Also look for -shortest, an output duration, or another condition that can make the output finish when one stream ends.
The exact command matters more than a shortened description such as “I added the loop flag”. Save a redacted copy with the FFmpeg version, the input sections, the mapping options, and the last part of stderr. Remove the actual YouTube stream key before sharing it.
Put -stream_loop -1 before the input’s -i
-stream_loop -1 tells FFmpeg to repeat the input indefinitely. It is an input option, so its position is significant. For a single file, put it in the input-option group before the file it controls:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -c:a aac \
-f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY"
This is a template, not a tested command for every file or computer. Replace input.mp4, the destination, and the encoding choices with values suited to your source. Do not paste a real stream key into an article, support ticket, screenshot, or public command. YouTube treats the key as part of the information the encoder uses to send the feed, so keep it private. The official YouTube encoder guidance explains the role of the stream URL and key.
The important part for this problem is the relationship between the option and -i:
-stream_loop -1 -i input.mp4
FFmpeg's command-line options are generally applied to the next input or output file. Because -stream_loop is an input option, placing it after -i input.mp4 does not configure that earlier input in the same way. It may instead be interpreted in relation to a later file or fail as an invalid arrangement, depending on the complete command and FFmpeg version.
The FFmpeg documentation is the primary reference for option scope and placement. Read the command from left to right, marking each input and output. If there is a second input, use a separate input-option group, for example:
ffmpeg -re -stream_loop -1 -i video.mp4 \
-re -stream_loop -1 -i audio.mp3 \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -c:a aac \
-f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY"
This second example is illustrative rather than a universal recipe. It assumes that the audio and video can be combined, that the stream mapping is correct, and that both inputs can be read at the required rate. Do not add a second loop merely because a command contains two inputs. First establish which input is finite and whether it is supposed to continue.
Do not confuse an input loop with a YouTube replay feature. FFmpeg must keep producing the feed. YouTube receives the repeated media as new incoming content; it does not need to know that the source file has returned to its first frame.
Use -re to pace a local file
A file can be read faster than real time unless you tell FFmpeg to pace it. For a prerecorded file used as a live source, put -re before the relevant input so FFmpeg reads at the file's native frame rate:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -c:a aac \
-f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY"
Without -re, FFmpeg may process the file as quickly as the computer and encoding settings allow. That can make the input reach its end quickly, overload the output path, or send media in a way that is not suitable for a live ingest. A loop can therefore be correctly configured while the overall command is still unsuitable for continuous delivery.
-re controls reading and pacing. It does not make a broken file repeat, and it does not reconnect a failed output. It also does not guarantee that the computer can encode quickly enough. Watch whether FFmpeg can maintain progress in real time and whether the output connection remains active.
Use this option for a local file, not automatically for every kind of input. FFmpeg's documentation warns that applying a low read rate to an actual live input or network source can cause packet loss. A camera, capture device, or existing live feed already has its own timing. Adding file-style pacing to such an input can create a different problem.
The encoding portion also needs inspection. The example re-encodes video with libx264 and audio with aac because that is a broadly understandable illustration, not because those exact settings are correct for every source. Stream copying may work in some workflows and fail in others if the source codecs, timestamps, pixel format, or container do not suit the output. Re-encoding can improve compatibility but uses more processing capacity.
If FFmpeg reports that it cannot keep up, do not respond by adding more loop flags. Check the input resolution, frame rate, codec settings, audio settings, and available processing capacity. The bitrate testing checklist is useful for separating a local preparation problem from an ingest problem, even though bitrate testing alone does not prove that looping is correct.
Confirm FFmpeg is still running
When the YouTube page appears to stop, first check the machine running FFmpeg. Is the process still present, and is the terminal still showing progress? If the process has exited, the next question is why it exited.
An orderly exit near the source duration points towards an input or output condition in the command. An exit accompanied by messages about an encoder, invalid argument, broken pipe, connection failure, or inability to write packets points towards a different layer. Do not hide stderr or close the terminal until the result has been recorded.
If you run FFmpeg through a script, scheduled task, terminal session, or remote connection, inspect that wrapper too. A shell can close, a session can be disconnected, or a supervisor can stop the process even though the FFmpeg command itself is valid. A command that works in an interactive test is not automatically a process that will survive an overnight run.
Check for command-level stopping conditions. Common possibilities include:
- an output duration such as
-tor-to -shortestending the output when one mapped stream finishes- a second input that is not looped
- a filter or stream map that produces no usable output after a transition
- a script that sends a termination signal
- a disk, memory, or processing failure
These are diagnostic branches, not conclusions about your command. The title alone cannot reveal whether one is present.
If the process remains alive, check whether it is actually writing packets. A frozen progress display, repeated output errors, or a process consuming resources without sending useful media may indicate a delivery or encoding problem rather than a loop problem. Record the time, the last visible FFmpeg messages, and whether the local input is still being read.
For a 24/7 channel, consider how you will observe a failure rather than assuming the terminal will be watched all night. A local process can be useful when you need direct control and can monitor it. A managed workflow such as StreamNeo removes the need to leave your own computer running once the video and YouTube connection are configured, while still leaving the content, channel settings, and platform requirements for you to check.
If you need to stop and restart a local process, protect the key and avoid copying it into shell history where possible. The internal guide on where to paste the YouTube RTMP address and why it fails covers the destination side of this setup.
Check the outgoing feed and YouTube stream status
Once you know what FFmpeg is doing, inspect YouTube separately. YouTube's encoder guidance states that stopping the encoder's content ends the stream. That means a feed that stops at YouTube may reflect FFmpeg exiting, FFmpeg losing its output connection, or another failure between the process and the ingest service. The loop option addresses only one possible cause.
Open YouTube Live Control Room and check the incoming stream or preview state while FFmpeg is running. Compare the timing with the local logs. If FFmpeg ends at the same moment that the incoming feed disappears, investigate the process and output connection. If FFmpeg continues but the preview stops receiving data, investigate delivery and ingest status separately.
Check the destination string carefully. The RTMP address and stream key must belong together, and the key must be current. Keep the key redacted in diagnostic material. If you need a refresher on how the destination is assembled, use the internal RTMP address guide, but confirm the current fields in YouTube's own interface.
Do not treat an archived video as proof that the source loop worked. An archive can show that YouTube received content for part of the session, but it does not tell you whether FFmpeg repeated the file, whether the process stopped normally, or whether the feed later failed. Compare the local file duration, the FFmpeg log, and the Live Control Room state.
Also separate delivery from content policy and channel settings. A technically valid, repeating file may still be unsuitable for your channel if you do not have the necessary rights, if the broadcast settings are wrong, or if the content requires a different audience declaration. For recorded devotional or darshan material, the guide to re-broadcasting recorded temple darshan discusses the separate content and rights questions. It does not replace YouTube's current official guidance.
If the stream key may have been exposed, rotate or replace it through YouTube rather than continuing to publish it in logs. A new key will not fix an input loop, but it can remove a credential problem from the diagnostic path.
Test the corrected command before relying on it
Do not make the first test an overnight broadcast. Use a controlled run with the same source, input options, output settings, and destination type that you expect to use later. The aim is to prove each layer in order.
First, run the command against the local file and watch whether it passes the original end of the file. If the source is short enough to test, wait until it should have finished once, then confirm that FFmpeg continues reading and encoding. A progress counter that keeps advancing beyond the first source duration is useful evidence that the input loop is active, but it does not by itself prove successful YouTube delivery.
Next, check the output while FFmpeg remains active. Confirm that YouTube shows incoming data and that the preview behaves as expected. Keep the terminal visible during this test. If YouTube stops receiving content, note whether FFmpeg also exits and preserve the final stderr lines.
Then test interruption handling separately. A loop flag is not a reconnect policy. If the connection drops or the encoder process stops, the command may need a supervisor, a restart procedure, or a different workflow. Decide how you will notice and recover from that event instead of describing the stream as protected by the loop option.
If you use audio and video from separate files, test them with the actual mapping. Listen for silence, check whether the audio ends before the video, and inspect any -shortest or duration options. For a channel with music or devotional audio, the audio settings guide for 24/7 streams can help with the separate questions of sample rate, silence, and loudness.
Keep a short test record containing the FFmpeg version, the redacted command, the source format, the start and stop times, the last stderr lines, and what Live Control Room displayed. If the basic correction does not solve the issue, those details are more useful than a screenshot saying “it stopped”. Include the full command structure but never include the stream key.
A practical order for diagnosis
Use this order when the stream ends, because it prevents a delivery problem from being mistaken for a loop problem:
| What you observe | First question | Likely area to inspect |
|---|---|---|
| FFmpeg exits at the file duration | Was -stream_loop -1 before the correct -i? |
Input options and source selection |
| FFmpeg exits with an error | What do the final stderr lines and exit status say? | Encoder, filter, mapping, or output |
| FFmpeg stays open but progress stops | Is it still reading and writing packets? | Processing capacity or a stalled output |
| FFmpeg stays active but YouTube loses the preview | Does the output connection report an error? | RTMP destination, key, or ingest path |
| Video continues but audio ends | Is the audio a separate finite input? | Audio loop, mapping, and shortest settings |
| A local test works but overnight use fails | What stops the process or session? | Wrapper, computer, connection, or monitoring |
This table is a starting point, not a diagnosis without logs. The same visible symptom can have different causes. In particular, -stream_loop -1 cannot repair an encoder crash, a network interruption, or a YouTube broadcast setting.
For a local FFmpeg setup, keep the command readable and group options by input. Avoid changing the loop, pacing, codec, mapping, and destination all at once. Change one layer, test it, and record what changed. That approach takes longer than copying a one-line fix, but it gives you evidence that can survive the next failure.
If the stream is important to your channel, decide whether maintaining the local process is worth the monitoring and recovery work. A local setup gives you direct access to logs and commands. A cloud-based workflow can remove the need to keep your own computer on, but you still need to prepare the file, connect the correct YouTube channel, and check the platform's current requirements.
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 work after -i?
For the input it is meant to control, place -stream_loop -1 before that input's -i. It is an input option, so putting it after the input may not apply it to the file you intended.
Do I need both -re and -stream_loop -1?
They do different jobs for a local prerecorded file. -stream_loop -1 repeats the input, while -re paces reading at the file's native frame rate so it behaves more like a live source. Do not automatically use -re on an actual live capture or network input, because low-rate reading can cause packet loss.
Why does YouTube stop even though FFmpeg is still open?
An open process does not prove that it is sending usable packets. Check FFmpeg's latest progress and error output, then compare it with YouTube Live Control Room's incoming stream state. If YouTube is no longer receiving data, investigate the output connection and ingest path separately from the input loop.
What should I share when asking for help?
Share the redacted command, FFmpeg version, input and output details, stream mapping, relevant options around every -i, and the final stderr lines. Include whether FFmpeg exited and what YouTube displayed, but remove the actual stream key and any other credentials.