To repeat an MP4 input indefinitely with FFmpeg, put -stream_loop -1 before the -i for that file. The option repeats the input; it does not guarantee that the join will be free of black frames, so inspect the source and test the actual output path.
For example, this is an illustrative continuous-output command:
ffmpeg -stream_loop -1 -i input.mp4 -c:v libx264 -c:a aac -f flv OUTPUT_URL
Replace the output URL, container and codecs with values supported by your destination and FFmpeg build. The command is not a universal recipe for every MP4 or streaming endpoint.
The basic command and what it does
The key part is -stream_loop -1 -i input.mp4. FFmpeg reads the input and, when it reaches its end, begins it again. The FFmpeg command-line documentation describes the option as setting the number of times an input stream is looped; zero means no repeat, while negative one means infinite repeat. See the FFmpeg command-line documentation for the option and its current syntax.
The example adds output choices so the shape of a continuous-output command is visible. -c:v libx264 selects a video encoder, -c:a aac selects an audio encoder, and -f flv requests an FLV output container. Those are illustrative choices, not destination requirements. Your target may expect different codecs or a different container, and your installed FFmpeg must include the chosen encoders.
A repeated input is not the same thing as a finite local file with a chosen duration. If you need a bounded output, choose a finite repeat count or define the intended duration, then check the resulting file. Do not assume that an infinite input loop somehow determines a useful finite duration on its own.
For a long-running YouTube broadcast, the repeated media is only one part of the job. You still need an output configuration accepted by the live destination and a way to keep the process running. If the aim is instead to prepare a media file, choose a finite workflow and verify the file before using it. Readers assembling a longer set of clips may also find the FFmpeg concat workflow for a 24/7 music stream useful; concatenating clips and repeating one file are related but distinct tasks.
Put the loop option before its input
FFmpeg command-line options have scope. Input options are placed before the input they govern, and output options are generally placed before the output they govern. That is why -stream_loop -1 belongs before -i input.mp4 in the example. Put it after that -i and you should not assume it will control the input you intended.
The rule matters more when a command has several inputs. If a command reads a background video, a separate audio file and perhaps an overlay, identify which input should repeat, then place its loop option immediately before that input's -i. A command can be syntactically valid while applying an option to the wrong input or leaving the intended input unlooped.
Check the whole input you want repeated. -stream_loop repeats an input stream or file; it is not a command to select only a segment unless the input itself has already been trimmed or prepared. If your source contains a leader, slate, silence or black tail, those parts are part of what will recur.
Do not confuse this input option with FFmpeg's loop video filter. The filter repeats a buffered range of video frames, which is useful for frame-level effects. The filter documentation shows an example that repeats the first frame indefinitely; that would hold one frame, not replay an entire MP4. The distinction is covered in the FFmpeg filter documentation.
If you are unsure which FFmpeg you have, run ffmpeg -version and consult the local help or documentation. The FFmpeg documentation index notes that online documentation is regenerated nightly and advises users of older versions to consult documentation for their version. The documentation index is a sensible starting point when your installation behaves differently from an online example.
Match output container and codecs to the destination
An input loop says nothing about the output format. The sample command sends encoded video and audio to an FLV output, but a different destination may require different settings. Treat the command as a pattern showing option placement, not a copy-and-paste configuration that works everywhere.
Before choosing output flags, find out what the receiving application or endpoint accepts. Check its current official instructions for the container, video and audio codecs, and any required connection details. Also check your own FFmpeg build: encoder names in an example are not proof that a particular build has those encoders available.
There are two broad ways to handle the media. With stream copy, FFmpeg passes packets through without decoding, filtering or encoding them. That can avoid a processing path, but it means you cannot apply a video filter to those packets. With re-encoding, FFmpeg decodes and encodes the media, which permits processing but changes the workflow and can affect quality or resource use. The FFmpeg documentation on stream handling explains the difference between stream copy and encoding.
A copied stream may be appropriate when the input and target are compatible and no frame changes are needed. If you need a filter, including a frame-level loop effect, stream copy is not a substitute for decoding and encoding. For diagnosis, comparing a copy-based result with a re-encoded test can help narrow down where a problem lies. It does not guarantee that re-encoding will remove a bad transition.
Avoid adding flags just because they appear in a command found online. A setting that makes sense for one file or destination may be unnecessary or unsuitable for another. Keep a record of the input, output options and destination used in each test so you can change one thing at a time.
For a 24/7 channel, the local FFmpeg command and the broader operating arrangement answer different questions. FFmpeg gives you control over the media processing; it does not, by itself, settle how a broadcast is monitored or recovered if the process stops. If switching off your own computer is central to the plan, compare that requirement with the trade-offs of cloud looping for a YouTube live stream. Choose the approach that fits your control, maintenance and recovery needs rather than assuming one method is right for every channel.
Inspect the source file and its boundary
A black transition can begin in the source rather than in the loop option. Watch the end of the file, then watch the start. If the last part is black, the first part is black, or either endpoint contains a fade that you do not want repeated, that material will appear at each join. Check both the video and the audio: a visual transition and an audio pause are different observations and need not have the same cause.
Inspect the endpoints in a player that can advance frame by frame if possible. Look beyond the single last frame: a few dark frames, a fade to black or a brief pause may be easy to miss during normal playback. Note whether the source itself changes cleanly from the final visible image to its opening image, or whether the content is designed to have a pause between repetitions.
The input may also carry timestamps or stream characteristics that interact with the output path. The cause cannot be established from the loop flag alone. The useful first step is observation: does the black portion already appear when you play the original file through its end and start, or only in the generated output? That comparison separates a source-boundary question from an output or player question without assuming a diagnosis.
If the source contains multiple audio or video streams, confirm which ones are being sent. A black image could reflect the selected video stream, and apparent silence may reflect the chosen audio stream. Do not change stream selection blindly; first establish what is present in the file and what the destination is receiving.
A playlist of separate clips raises a related but different boundary problem. If the aim is to move from one item to another rather than repeat a single MP4, prepare and test those joins as part of the playlist workflow. The article on keeping an FFmpeg YouTube Live playlist running addresses the end-of-file issue in that separate setup.
Test playback before continuous output
Do not make the first test an overnight broadcast. Start with a short local or otherwise controlled output, using the same source and the same relevant encoding choices you expect to use later. Check the result around the point where the file restarts. A normal-looking opening and ending when viewed separately does not prove the transition will look right when repeated.
Test in the player or destination that matters. A file that appears acceptable in one player can behave differently in another, and a streaming client may display a transition differently from local playback. If the final target is YouTube Live, inspect the actual receiving path in a private or otherwise appropriate test setup before depending on it for a public schedule. FFmpeg's documentation cannot tell you how every downstream client presents a particular output.
Keep each test small enough to interpret. Record the input file, the placement of -stream_loop, whether you used copy or re-encoding, the output container and codecs, and what you observed at the boundary. If you change several variables at once, a better result will not tell you which change mattered.
For a finite local test, specify a finite repeat count or intended duration and inspect the completed output. The infinite-loop example is meant to illustrate a continuous input, not a complete finite MP4 recipe. If you need a repeatable deliverable, make the duration explicit in your workflow and verify that the output ends where you expect.
Think about the operating test as well as the visual test. A continuous process has to keep running, and a long broadcast introduces practical questions about monitoring and recovery that a short file check cannot answer. StreamNeo can remove the specific burden of keeping your own computer on to relay an uploaded video, while leaving you responsible for choosing and checking the media and YouTube destination. It is a YouTube-only route, not a replacement for testing the loop boundary.
Troubleshoot black frames in a deliberate order
If you see a black frame, avoid treating -stream_loop -1 as a black-frame repair switch. The option repeats the input. The FFmpeg documentation does not promise that it cleans source endpoints, repairs every timestamp pattern or forces every player to display a seamless boundary.
Work through the following checks in order:
- Inspect the original endpoints. Play the source across its final frames and its first frames. If black is already present, edit or prepare a suitable source before expecting a loop to hide it. A black head or tail will return on each repeat.
- Check option placement. Confirm that
-stream_loop -1appears before the-ifor the intended input. In a multi-input command, check that it is attached to the correct file. - Identify copy versus encoding. If the command uses
-c copy, remember that stream copy does not decode, filter or encode. It cannot apply a video filter. Compare against a re-encoded test if you need to investigate whether the processing path is relevant; treat that as a diagnostic, not a guaranteed fix. - Compare local output with the real destination. If the generated file looks clean in one player but the streamed version does not, inspect the receiving client and output configuration. The issue may be specific to that path, and an FFmpeg command alone cannot diagnose it.
- Change one variable and test again. For example, keep the source and destination constant while testing a different processing path. Note the exact difference you observe rather than concluding that one codec or container always causes black frames.
If you cannot reproduce the issue locally, preserve a short sample around the boundary and the command used, then seek help with those details. Redact stream keys and other private connection information before sharing a command. That makes the question answerable without exposing access to your live channel.
For a channel made from a single repeated recording, the boundary is central. For a channel built from several clips, the transition between items deserves its own test. Do not use the video-frame loop filter as a shortcut for repeating an entire programme: its purpose is to repeat selected frames, not to manage a sequence of full files.
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 remove every black frame?
No. It makes FFmpeg repeat the input indefinitely, but does not promise to remove black frames at the join. Inspect the source endpoints and test the resulting output in the player or destination you intend to use.
Why does the position of -stream_loop -1 matter?
It is an input option, so place it before the -i it controls. In a command with multiple inputs, put it before the relevant input rather than assuming it applies globally.
Is the loop filter the same as -stream_loop?
No. -stream_loop repeats an input stream or file. The loop video filter repeats a buffered range of frames; repeating one frame is not the same as replaying a complete MP4.
Can I use the sample command for any destination?
No. Its URL, container and codec choices are illustrative. Check the target's current instructions and your FFmpeg build, then test the actual output path before relying on it continuously.