If FFmpeg reaches the end of one video file, add -stream_loop -1 before that file’s -i option to tell FFmpeg to loop the input. That keeps the input available to a running process, but it does not prevent encoder failures, repair a broken connection, or make every playlist repeat.
The right command depends on the source file, the way audio and video are mapped, your output settings, and the YouTube ingest configuration. Treat the example below as a structure to adapt and test, not as a universally tested or complete production command. Keep your YouTube stream key private.
Why a finite input ends the stream
A video file has an end. When FFmpeg reads through a finite input and reaches end-of-file, it has no more media from that input to send. Unless the command or the input workflow supplies something else, FFmpeg can finish its work and exit. YouTube may then show that the live feed has ended or stopped, depending on the stream state and timing.
That is different from a command that fails before reaching the end. An encoder error, unreadable file, full disk, process termination, or network problem can stop a broadcast even if the input is configured to loop. A loop only addresses the normal end of a loopable input while FFmpeg is still running.
Start by identifying which situation you have. If a single file plays once and FFmpeg exits cleanly at its end, an input loop may be appropriate. If you are using a playlist or concat workflow, inspect how that playlist is built and what happens after its last item. If FFmpeg reports an error or exits unexpectedly, inspect its exit status and logs. If FFmpeg is still sending media but YouTube reports an ingest problem, check the message in YouTube Live Control Room rather than assuming the file ended.
These distinctions matter because restarting a command is not the same as looping media. A supervisor can relaunch a failed FFmpeg process, but it does not stop a successful process from reaching the end of a finite file. Conversely, looping the input cannot recover from a process crash or a broken output connection. For broader diagnosis, see this guide to a 24/7 stream that stops after a few hours.
Loop a single input with stream_loop
FFmpeg’s -stream_loop option controls how many times it repeats an input. The value -1 means to loop indefinitely. For one video file, the basic structure looks like this:
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-c:v libx264 -c:a aac -f flv "$YOUTUBE_INGEST_URL"
This is an illustrative structure, not a complete command for every source or a claim that it has been tested with your media. The codecs shown are examples only. Your source may have no audio, may need explicit stream mapping, or may require different encoding, bitrate, frame-rate, timing, or output choices. The output URL also has to match the ingest details YouTube provides for your broadcast.
The important part for the input loop is its position: -stream_loop -1 is immediately before -i input.mp4. It applies to that input. If the command has several inputs, such as a video file and a separate audio file, decide deliberately which input should repeat. Looping the video while the separate audio reaches its end can leave the overall command without the audio you intended to provide.
Repeating a file is an editorial choice as well as a technical one. A bhajan channel might intentionally repeat a long programme, while a local news loop may need new material at a defined time. A short visual or audible transition at the repeat point may be noticeable even if the stream connection remains active. Watch and listen across the loop boundary before using it for an audience.
If the source is a playlist, -stream_loop -1 on one input should not be assumed to loop the entire playlist. Playlist formats and demuxers behave differently, and a loop option attached to an input is not a universal playlist hot-reload method. If you need several videos in a fixed order, verify the playlist workflow itself and test what happens after its last item. This FFmpeg playlist switching guide may help frame that separate problem.
Place input options before the matching input
FFmpeg’s command line is organised into inputs and outputs. Options apply to the next input or output they govern, and input options are reset between files. In practical terms, put -stream_loop -1 before the -i for the file you want to repeat, not after it and not casually at the end of the command. The FFmpeg command-line documentation explains how options apply to inputs and outputs.
For example, this ordering makes the intended relationship clear:
ffmpeg -re -stream_loop -1 -i input.mp4 ...output options... "$YOUTUBE_INGEST_URL"
If you have more than one input, keep each input’s options next to its own -i:
ffmpeg [options for first input] -i video.mp4 \\
[options for second input] -i music.wav \\
[output options] "$YOUTUBE_INGEST_URL"
The bracketed text is explanatory, not literal command syntax. It is there to show placement. If both inputs should loop, the relevant loop option needs to be placed before each matching -i. If only one should loop, do not accidentally apply it to the other input. Options for encoding and output belong with the output they configure, after the inputs.
This ordering can be hard to see in a long one-line command. Break the command over lines with shell continuations, label a private working copy, and check each -i against the options immediately before it. Do not paste a rearranged command into a live session simply because the option name appears somewhere in it. The position determines what it controls.
Check output codecs, mapping, and audio
Looping changes how FFmpeg reads an input; it does not decide how to encode or send it. The example’s libx264, aac, and FLV container are not a promise that those choices fit your file or stream. Check the current YouTube encoder guidance for the supported protocol and settings for the resolution, frame rate, and ingest mode you are using. YouTube lists RTMP and RTMPS as protocols and recommends constant bitrate encoding; its current encoder settings guidance gives the details to verify. Guidance can change, so use the current official page rather than copying an old command from a forum.
Mapping determines which input streams FFmpeg sends. A file can contain more than one video or audio stream, or no audio at all. Automatic selection may not match your intent. Inspect the source and, when needed, specify -map deliberately. A command that asks for an audio stream when none exists may fail; a command that selects the wrong track may send commentary, silence, or the wrong language. If audio comes from a separate input, ensure it continues for as long as the video and that timestamps remain suitable when the file loops.
Audio deserves a separate listening test. A seamless visual loop can still produce a click, a gap, or a sudden change in loudness at the boundary. If your channel depends on uninterrupted music, compare the end of the file with its beginning and listen to repeated transitions, not just the first playback. The practical considerations in this guide to preventing silence between podcast episodes also apply when you are deciding how transitions should sound.
YouTube’s encoder guidance recommends a two-second keyframe frequency and says not to exceed four seconds. Do not treat that as a universal bitrate or codec prescription: YouTube’s bitrate recommendations vary by resolution, frame rate, and codec. Check the table for the actual output mode, then confirm the encoder options in your command agree with it. Where supported, YouTube describes RTMPS as an encrypted extension of RTMP; use the secure ingest option shown for your stream when available.
Keep the stream key out of examples and logs
A YouTube stream key is a credential for sending a feed to your live stream. Do not publish it in an article, screenshot, terminal recording, support post, or copied command. Anyone who obtains it may be able to send content to the associated stream. If you believe it has been exposed, use YouTube’s current controls to manage or replace it and check the official instructions.
The example uses a placeholder variable, YOUTUBE_INGEST_URL, so the key is not written into the command shown here. A real FFmpeg command may require an ingest address and a key in a particular format; follow the details from YouTube and your chosen client. Avoid putting a real key in shell history or in a script that is readable by other users. The exact safe storage method depends on your operating system and how the job is run, so check that the account running FFmpeg can access the secret without exposing it unnecessarily.
Logs are useful when diagnosing an exit, but inspect them before sharing. Some command lines or diagnostic output may include destination details. Redact credentials and other account-specific information from excerpts. Do not turn on verbose logging in a public environment without checking what it records, and do not assume that a variable name alone makes a real secret safe if the expanded command is captured elsewhere.
Protecting the key does not replace checking stream health. YouTube Live Control Room can show ingest status and specific warnings. Treat that information as a separate signal from FFmpeg’s process status: a command can still be running while YouTube reports a problem, and FFmpeg can exit even if the ingest had previously been healthy.
Test the command with the actual source
Test the exact file, FFmpeg build, and command shape you intend to use before scheduling a live broadcast. A structurally correct option can still meet a source-specific issue, such as timestamps that behave poorly at the repeat boundary, a missing audio stream, or an unexpected stream selection. Do not assume the example behaves identically on every operating system, FFmpeg version, or media file.
First test locally or against a private/unlisted setup appropriate to your workflow. Confirm that video continues across the point where the file ends and begins again. Listen for silence, clicks, or other discontinuities. Check that FFmpeg remains running and review its exit status if it stops. A short test that never reaches the file’s end cannot tell you whether the loop boundary works.
Then test the output with audio and movement similar to what viewers will receive. YouTube advises testing before going live and monitoring stream health during the event; use its live encoder setup guidance and the Live Control Room’s current messages. Confirm that the selected ingest protocol, resolution, frame rate, audio, and keyframe behaviour match the intended stream. Do not infer healthy ingest merely from a local preview or from FFmpeg printing progress.
Plan monitoring separately from looping. If the machine, network, or process can fail, decide who or what will notice and what action should follow. A process supervisor can restart a failed command, while an alert can tell you that attention is needed; neither one makes the finite input infinite on its own. Likewise, a loop does not restart a dead process. For a PC-based setup, this always-on music stream guide for India covers some of the practical operating considerations around keeping a source machine available.
If the file is intentionally repeated for long periods, consider whether one file is the right editorial unit. A longer programme, a playlist with a verified next item, or a fallback slate can be a better fit. Each adds its own configuration and testing needs. A fallback must provide compatible media streams and be deliberately wired into the workflow; do not assume a simple input-loop option will switch to new material that arrives later.
YouTube says that streams under twelve hours are automatically archived on its encoder setup page. That is an archive statement, not a promise that FFmpeg will keep running or that a single uninterrupted feed will be accepted indefinitely. If the archive matters, check YouTube’s current guidance and plan how you will handle long-running broadcasts independently of the input loop. This explanation of YouTube live-stream archive retention covers the archive question separately.
If managing a local computer overnight is the specific problem, a workflow that runs without that computer can remove the need to keep it powered on; StreamNeo takes an uploaded video and runs it as a YouTube live stream, so you do not have to leave your own machine on for the broadcast. That does not remove the need to check that the file and channel are ready or to monitor the stream.
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 keep FFmpeg running after a video ends?
It tells FFmpeg to repeat the input indefinitely, so a running process need not reach the normal end of that one file. It does not guarantee continuous output or keep FFmpeg alive after a crash, invalid input, or broken connection. Test the actual file and output path.
Can I use it to loop a playlist?
Do not assume that looping one input makes every playlist workflow repeat as intended. The result depends on how the playlist is built and which demuxer or input method is used. Test the whole playlist through its final item and verify what follows.
Why does FFmpeg still stop when the input is set to loop?
The loop option only addresses input end-of-file. Check FFmpeg’s exit status and logs for other failures, then check YouTube Live Control Room for ingest errors as a separate diagnostic. Redact stream keys and credentials before sharing any command or log excerpt.
Does YouTube archive a long-running loop automatically?
YouTube’s guidance says streams under twelve hours are automatically archived, but this does not guarantee FFmpeg uptime or indefinite ingest acceptance. Check the current official archive and streaming guidance when planning a long broadcast.