A finite FFmpeg input ends when FFmpeg has read all of its media. If that file is the source being sent to YouTube and nothing replaces it, the outgoing feed can stop; if the broadcast is set to stop automatically, YouTube may then end the viewer-facing broadcast.
That is a plausible explanation for a stream going offline at the end of a video, not proof of what happened in your case. The command, FFmpeg output and logs, and YouTube’s stream and broadcast settings are needed to distinguish end of file from an encoder error, lost connection or a broadcast-state change.
Why a finite FFmpeg input reaches its end
A video file is finite: it contains a beginning and an end. FFmpeg reads it from the selected input, decodes and processes its audio and video, then reaches end of file (EOF) when there is no more media to read. Unless you have configured a repeat or another continuing source, that input does not produce another pass on its own.
It helps to separate the file reader from the broadcaster. FFmpeg is a process that reads inputs and creates an output. If its only input is one MP4, then the MP4 ending can leave FFmpeg with nothing further to encode. Depending on the command and output behaviour, FFmpeg may exit, or the process may remain for a time while no useful media reaches the output. Check what it actually did rather than assuming the window closing or the YouTube page changing tells the whole story.
For example, suppose you send a recorded evening prayer service to YouTube as a continuous channel. If the command reads the recording once and has no playlist, loop, or replacement input, it can send the service once and then run out of source media. A devotional channel that intends to repeat the same recording needs to specify that behaviour; YouTube cannot infer that the file should start again.
The same distinction matters for a local news loop, an ambience video or a study channel. A file ending is expected. The unexpected part is usually that the source was configured for a single pass when the channel was expected to continue, or that something else stopped the feed or broadcast at about the same time.
How a stopped feed can affect the broadcast
FFmpeg’s output is the incoming video feed. YouTube receives that feed, processes it, and presents a broadcast to viewers. If the feed stops, the broadcast does not necessarily change state at precisely the same instant: the result depends on YouTube’s settings and the broadcast lifecycle.
YouTube documents an automatic-stop behaviour for broadcasts: when incoming video stops, an automatically stopping broadcast can end around a minute later. That delay can make the symptom look as though YouTube ended the session by itself, even if the first event was FFmpeg reaching EOF. It is a useful lead, but not a diagnosis. The command may instead have hit an encoding error, lost its RTMP connection, or continued sending while the broadcast changed state for another reason.
The relevant distinction is temporal. Look at the last FFmpeg messages and process status at the time the media ended, then compare those with the stream and broadcast status in YouTube. If FFmpeg logged EOF and exited, that points towards a finite input without a repeat. If it reports an output error or remains active while YouTube shows no incoming feed, investigate the connection and output path as well. If the feed is still active but the event is no longer live, inspect the broadcast lifecycle and its automatic-stop setting.
YouTube’s live broadcast documentation describes the broadcast as the event presented to viewers and exposes its lifecycle and settings. Use the current YouTube Studio view or API information available to you; do not assume that a symptom alone reveals which setting was active.
A stream feed and a broadcast are not the same thing
YouTube’s terminology can be confusing if you use “stream” to mean the whole session. In the Live Streaming API model, a live stream is the feed sent by an encoder, while a live broadcast is the event viewers watch. A broadcast is associated with a stream, but they have distinct status and lifecycle information.
That is why “FFmpeg is connected” and “the broadcast is live” are not interchangeable checks. The encoder might still be sending a feed when the broadcast is complete, or a broadcast might be waiting to start while its bound stream is not active. If you manage broadcasts through the API, YouTube requires the bound stream’s status.streamStatus to be active before transitions to testing or live can proceed.
A transition to live can also take a little time. YouTube documents an intermediate liveStarting status; its guidance says a transition usually takes 5 to 10 seconds and can take up to a minute. Check for the status to reach live before treating a short transition period as a failed start. These timings describe YouTube’s documented API transition behaviour, not a guarantee about every encoder or connection.
The YouTube broadcast lifecycle guide explains the states and how a broadcast moves through them. If you use Studio rather than the API, the same practical lesson applies: check the incoming feed and the viewer-facing event separately. A green encoder indicator alone does not establish that viewers can see a live broadcast.
Repeat a file with -stream_loop -1
For a finite file that should repeat indefinitely, FFmpeg documents -stream_loop -1 as the input-loop setting. The option applies to an input, so place it before the -i for the file it is meant to repeat. The FFmpeg manual defines loop value -1 as infinite looping; 0 means no loop.
A schematic command looks like this:
ffmpeg -re -stream_loop -1 -i input.mp4 [encoding and audio/video options] -f flv rtmp://your-youtube-ingest-url/your-stream-key
This shows option placement, not a command tested against your file or ingest configuration. Keep the encoding, audio and video mapping, output format, ingest address and stream key appropriate to your channel and YouTube setup. Do not copy the placeholders literally or share your stream key. If the input has no audio, unusual codecs, multiple tracks or a variable frame rate, you may need different options.
For a file being played out as live media, -re reads at the input’s native frame rate; FFmpeg documents it as equivalent to -readrate 1. Without suitable pacing, a file can be read faster than its original playback duration. But it is not a universal option: FFmpeg warns that imposing a low read rate on an already-live source can cause packet loss. Use it for file playback where real-time pacing is needed, not automatically for a camera or another source that is already live.
Looping changes content behaviour, not broadcast health. It makes FFmpeg try to read the file again after it ends; it does not by itself confirm that the output is connected, the stream is active, the broadcast is live, or the audio and video are valid. The current FFmpeg command-line manual is regenerated nightly, so if an option behaves differently on your machine, check ffmpeg -h full or the documentation installed with that FFmpeg version.
If repeating precisely the same recording is not what you want, use a source or process designed to keep providing the content you intend: for example, a playlist, a changing programme, or a truly live source. Those approaches have different restart and monitoring needs. A loop is simple when repetition is acceptable; it is not a substitute for checking that a long-running process and YouTube’s broadcast state remain healthy.
Check the actual command and input ordering
Start with the command that ran when the problem occurred, not an approximate command you remember setting up. Copy it from the script, service definition, scheduled task or terminal history, and redact the stream key before sharing it. Confirm which -i is the file that ends, and whether -stream_loop -1 appears before that input’s -i.
FFmpeg options can apply to a particular input or output depending on their position. If you put the loop option after the file’s -i, it may not control the input you intend. If the command has multiple inputs, placing it before the wrong -i can loop a different source. Read the command left to right, identify each input, and match options to the input they are meant to affect.
Then confirm that the file you think is playing really is the source reaching EOF. A playlist may advance to another file; a wrapper script may launch a different command; a mounted path might point to a shorter or different file than expected. The systemd and FFmpeg live-loop guide is relevant if a service manager starts the process, because it helps you inspect how the configured command is launched and restarted.
Check the FFmpeg process and its stderr or captured output around the failure. Look for a normal end of input, an encoding or decoding error, an output error, a lost RTMP connection, or a process that is still running without sending media. The exact messages vary with FFmpeg version and the command, so do not treat one phrase as conclusive without the surrounding lines.
If your setup uses a script that restarts FFmpeg after it exits, inspect that behaviour too. A restart can make the stream feed appear to return, but repeated restarts may hide the original failure and can affect the broadcast. The guide to reducing buffering on a 24/7 mantra stream covers other points in the path worth checking when media pauses rather than simply ending at the last frame.
Review automatic-stop settings and status
Once you know what happened to the FFmpeg process, check YouTube separately. In Studio, inspect whether the stream is receiving data and whether the broadcast is live, waiting, or ended. If you use the API, review the stream’s status.streamStatus and the broadcast’s lifecycle state rather than relying on a single status label.
For API-managed broadcasts, YouTube documents stopping video transmission and then transitioning the broadcast to complete as the normal explicit end procedure. If the broadcast was configured for automatic stop, a stopped incoming feed can instead result in completion after the documented delay. Find out whether automatic stop is enabled for this broadcast before attributing the outcome to FFmpeg alone.
An inactive stream also matters when starting or restarting a broadcast through the API. YouTube requires the bound stream to be active for a transition to testing or live; if it is not, fix the feed first and then retry the transition. If the broadcast is entering live, allow for the documented liveStarting interval and check again rather than repeatedly issuing transitions.
For a broader check of whether YouTube is receiving and starting the feed, see Stream Stuck on Starting Soon or Waiting for Data. The aim is to follow evidence through the chain: source file, FFmpeg output, incoming stream status, then broadcast status. A healthy result at one point does not confirm every point after it.
Test the loop and verify the feed
Test with a short copy of the media or at a time when a brief interruption is acceptable. First verify that the command reaches the intended input and that the output is paced appropriately. Keep the FFmpeg messages visible or saved so you can see whether the input reaches EOF and starts again, or whether an error interrupts the output.
Observe at least one file boundary. Confirm that the video resumes from its beginning and that audio also continues as intended. Some files have a small pause, black frame or audio discontinuity at the cut; looping cannot remove an edit that is already present in the media. If the file has a silent opening or different audio levels at its beginning, account for that before treating the boundary as an encoder fault.
At the same time, check YouTube’s incoming stream status and the broadcast’s viewer-facing state. For API workflows, confirm the bound stream is active before trying the relevant transition, then wait for live if you see liveStarting. From a viewer’s perspective, verify that the broadcast remains available and that sound and picture continue, not merely that the encoder process still exists.
If the test fails, keep the evidence together: exact command with the key removed, FFmpeg version, relevant stderr lines, YouTube stream status, broadcast status, and whether automatic stop is enabled. This is more useful than changing several settings at once. If the encoder has stopped at EOF, correct the input loop or content plan; if it stays up but loses output, investigate the connection; if the feed is healthy but the broadcast ended, examine broadcast settings and lifecycle.
A continuously running channel also needs a plan for what happens when the process drops, the source becomes unavailable, or a restart is required. For a file-based 24/7 channel where maintaining the machine is the main burden, StreamNeo removes the need to keep your own computer running the uploaded video; it does not change the need to check that the content and YouTube broadcast are configured as intended.
If you decide that repeating the same file is the right behaviour, document the working command and test it after changing the file, FFmpeg version or broadcast setup. If you need varied content, choose a playlist or live source instead and test its end-of-list and restart behaviour. In either case, keep an eye on both the feed and the broadcast rather than assuming one proves the other.
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
Why does my YouTube livestream stop when the video ends?
A finite input is consumed once unless FFmpeg is told to repeat it or another source takes over. If that was the feed sent to YouTube, video can stop arriving; an automatic-stop broadcast may then end around a minute later. Check the command, logs and broadcast settings before concluding that EOF was the cause.
How do I loop an FFmpeg input file for a YouTube livestream?
Use -stream_loop -1 before the -i for the input you want to repeat. For file playback at real-time pace, -re may also be appropriate, but do not add it automatically to a source that is already live. Test a file boundary and verify the incoming feed and broadcast state.
Does -stream_loop -1 guarantee that my broadcast stays live?
No. It addresses repetition of a finite input; it does not guarantee a working encoder output, active YouTube stream or live broadcast. Connection errors, invalid media, broadcast completion and settings can still interrupt the viewer-facing event.
What should I check if FFmpeg is still running but YouTube is offline?
Check whether FFmpeg is still sending output, then inspect YouTube’s stream status and broadcast lifecycle separately. If you use the API, confirm the bound stream is active and allow for liveStarting to reach live. The process being present is not proof that viewers are receiving a live broadcast.