A whole fireplace clip can be repeated in FFmpeg with -stream_loop -1, then stopped at a separate output duration with -t. The basic command is ffmpeg -stream_loop -1 -i fireplace.mp4 -t 01:00:00 -c copy looped.mp4.
That command repeats the file, but it does not remove a black frame already present at the beginning or end. If the picture jumps, freezes or briefly goes dark at the join, inspect the source and decide whether you need a different loop method or an edited, re-encoded file.
Repeat the whole clip with -stream_loop
For a finite repeated file, use the input-level loop option before the input it applies to:
ffmpeg -stream_loop -1 -i fireplace.mp4 -t 01:00:00 -c copy looped.mp4
Here, -stream_loop -1 tells FFmpeg to repeat the input indefinitely. The -1 is the value for an unlimited number of repetitions. The option belongs before -i, because it is an input option and controls the file that follows it.
The -t 01:00:00 part sets the requested output duration. It does not change how many times FFmpeg reads the source. FFmpeg keeps taking another copy of the input until the output reaches the requested length.
-c copy asks FFmpeg to copy the audio and video streams without decoding and re-encoding them. That is useful when you are repeating the whole clip unchanged. It is also why this command cannot repair a bad image: the frames are being passed through rather than edited.
The command creates a file called looped.mp4. It does not by itself create a YouTube broadcast. That distinction matters if your aim is an overnight or 24/7 channel rather than a prepared file.
Before using the command on an important source, make a short test output and watch the boundary. A file that looks fine in the middle can still reveal a black final frame, a timestamp problem or an audio mismatch only when it returns to the beginning.
For a longer discussion of keeping recorded material available as a channel, see this guide to event replay channels after a conference ends. The same separation between prepared media and a live destination applies to a fireplace loop.
Set the output duration separately with -t
-stream_loop and -t solve different problems. The first controls repetition of the input. The second controls how long FFmpeg writes the output. Keeping those jobs separate makes the command easier to reason about.
For example, a two-hour file can be made with:
ffmpeg -stream_loop -1 -i fireplace.mp4 -t 02:00:00 -c copy fireplace-two-hours.mp4
A twelve-hour test can use:
ffmpeg -stream_loop -1 -i fireplace.mp4 -t 12:00:00 -c copy fireplace-twelve-hours.mp4
The source does not need to be twelve hours long. FFmpeg repeats it until the requested output duration is reached. Conversely, if the requested duration ends halfway through a repetition, the output stops there rather than waiting for the source to finish another complete cycle.
Do not confuse -t with a fix for a black frame. Stopping the output earlier can avoid a known bad endpoint in a particular test, but it does not remove that endpoint from the source or make later repetitions seamless. If you need to change which frames are present, you are editing the media rather than merely looping it.
If you retain audio, check the relationship between the audio and video durations. A fireplace video may contain a longer music track, a short ambience track or no audio at all. If the audio continues beyond the video, the output can behave differently at a boundary from a silent video.
For a silent visual loop, explicitly omitting audio may make the intended result clearer:
ffmpeg -stream_loop -1 -i fireplace.mp4 -t 01:00:00 -an -c:v copy silent-loop.mp4
Use -an only when you genuinely want no audio. If the source audio is part of the experience, map and inspect it instead of discarding it as a quick workaround.
Check whether stream copy fits the source and container
Stream copy is not a universal compatibility mode. It works when the source streams can be placed in the chosen output container and when the timestamps and codec behaviour remain acceptable at the repeated boundary.
The command above uses an MP4 input and an MP4 output, but matching extensions alone do not prove that the streams are suitable. A file may contain a codec, audio format or timing arrangement that is awkward for the target container or destination. FFmpeg may report an error, produce warnings or create a file that needs testing in the player where it will actually be used.
Use stream copy when all of the following are true:
- You are repeating the whole source without trimming or changing frames.
- The video and audio streams are already suitable for the output container.
- You have checked the source durations and timestamps.
- The output plays correctly at the loop boundary.
If any of those conditions is uncertain, make a short test first. FFmpeg's official documentation describes the command-line options and how their position affects inputs and outputs. The exact result still depends on your file and your FFmpeg build.
A filtered workflow is different. Once you trim, fade, crossfade, scale or otherwise process decoded frames, stream copy is no longer the appropriate way to write the changed stream. You normally need to encode the filtered output again.
That re-encoding can take more processing time and can alter visual quality if the settings are unsuitable. It is nevertheless the correct route when the boundary itself must change. The FFmpeg FAQ recommends the concat filter when re-encoding is required for concatenating video; see the FFmpeg FAQ before adapting a filter command.
The choice is therefore not simply between a fast command and a slow command. It is between preserving the existing media exactly and producing a new stream whose frames have been changed. A black endpoint cannot be removed by a command that copies that endpoint unchanged.
Inspect the first and last frames
Before diagnosing the loop command, inspect the source itself. Watch the first few seconds and the last few seconds, preferably at the same size and player you will use for the finished output. Look for a literal black image, a fade to black, a freeze, a sudden exposure change or audio continuing after the final visible frame.
A useful test is to create a short copy that includes one boundary, then watch it repeatedly:
ffmpeg -stream_loop 1 -i fireplace.mp4 -t 00:02:00 -c copy boundary-test.mp4
The exact duration should be chosen around the source length rather than copied blindly. The purpose is to view the joining area, not to assume that two minutes is enough for every file.
If the final frame of the source is black, the loop command will repeat that black frame. If the first frame is black, it will appear at the start of each repetition. This is expected behaviour for a copy operation, not evidence that -stream_loop has inserted a new black frame.
A black gap can also be a timing problem rather than a black picture encoded in the file. Review the decoded image at the boundary and check the audio and video durations before changing frame-rate or timestamp flags. Adding timestamp options without understanding the source can hide the actual cause.
If you have a silent fireplace visual, remove unrelated audio from the test so that a longer audio stream cannot make the video appear to hold its last frame. If the source includes sound, inspect the sound separately. A join that looks correct with audio removed may still freeze or drift when the original audio is retained.
The source may also have an intentional fade. That is not automatically an error. A gentle fade can be part of the design, while a single completely black frame inserted between two otherwise continuous images is usually a source or timing issue worth investigating.
Do not assume that a problem seen in a live player originated in the video file. The output file, the player, the ingest connection and the destination can each introduce a different symptom. Test the file locally first, then test the actual broadcast path.
Understand why a repeated clip can still have a seam
“No black frames” and “seamless loop” are separate goals. A clip can have a bright final frame and a bright first frame but still show a visible jump when the two images do not match.
Imagine a fireplace shot where the flames are high on the left at the end and low on the right at the beginning. Neither frame is black, but the viewer will notice the sudden change. Repeating the encoded frames preserves that difference exactly.
There are three common cases:
| What you see | Likely explanation | Appropriate response |
|---|---|---|
| A literal black image at each join | Black is present at an endpoint, or a gap is being produced by timing | Inspect the source frames and timestamps, then trim or rebuild if needed |
| A brightness or flame-position jump | The first and last images do not match | Choose a better source boundary or edit a transition |
| A freeze or delayed restart | Audio/video duration or timestamp mismatch may affect the join | Inspect both streams and test the encoded output |
The FFmpeg video loop filter can repeat decoded frames from a selected section. Its loop, size and start settings determine what is buffered and where repetition begins. The filter is useful when the repeat needs to be part of a processing workflow, but it is not an automatic black-frame detector.
A filter example has the following general shape:
ffmpeg -i fireplace.mp4 -vf "loop=loop=-1:size=300:start=0" -t 01:00:00 -an filtered-loop.mp4
Treat size=300 as an example that must be selected for the source and the section you intend to repeat. It is not a universal setting for fireplace videos. Because the filter works on decoded video frames, the result normally needs video encoding before it can be written as a finished file.
If the source boundary is wrong, trim the unwanted endpoint or create a deliberate transition in an editing workflow. A crossfade may soften a mismatch, but it can also produce a brightness dip or ghosted flame pattern. Preview the result rather than adding a crossfade simply because a seam exists.
A genuinely seamless loop usually comes from footage designed or edited for that purpose. FFmpeg can process the boundary, but it cannot infer which flame movement, brightness level or audio moment your audience will find natural.
For a YouTube channel using several prepared videos, this guide on streaming a YouTube playlist continuously with OBS Studio may help with the broader scheduling problem. It does not remove the need to inspect each source transition.
Distinguish a finite file from a live broadcast
A command that writes looped.mp4 produces a finite file. A live broadcast sends encoded media to a destination while the process is running. Those are different jobs even when both begin with the same fireplace video.
For a file, you choose an output container and duration. For a live broadcast, you also need the destination's ingest address, stream key, authentication and accepted encoding settings. There is no single universal FFmpeg network command that is correct for every service and protocol.
YouTube's official live encoder guidance is the place to confirm the current stream settings for a YouTube broadcast. Use the values shown for your channel and event rather than copying a command intended for another destination.
The live pipeline may also need a process that continues beyond the length of one source clip, a reconnect strategy and monitoring of the actual output. A repeated file that plays correctly locally is a useful input, but it is not proof that the destination will accept or display the broadcast correctly.
If you are using a computer or VPS overnight, plan for the failures that do not appear in a short daytime test: the process may stop, the network may change, the machine may restart or the destination may reject a stream after a setting change. The practical question is not only whether FFmpeg can repeat the clip, but who will notice and recover when the broadcast is no longer moving.
For readers comparing local and hosted approaches, the article on running prerecorded videos on a YouTube live stream from an Indian cloud server covers the operational side separately from the media join itself. Keep the media diagnosis and the hosting decision as two distinct checks.
When the main pain is leaving a computer running, StreamNeo removes that particular operational step by taking the uploaded video, the YouTube stream key and the repeating broadcast into one managed workflow, while still leaving the source file and its endpoint quality for you to check.
Verify the broadcast at the destination
After preparing the file, verify the actual destination output rather than relying only on FFmpeg's console messages. Open the public or preview player and watch through at least one complete boundary. If the source is long, make a shorter test copy that reaches the join sooner.
Check four things in order:
- Does the video reach the end of the source without freezing?
- Does the first frame of the next repetition appear without an unwanted black image?
- Does the audio continue at the expected point, or is it longer than the video?
- Does the destination remain in the intended live state after the join?
If the local file is clean but the destination shows a gap, compare the two paths. Confirm that the live output uses the destination's current ingest settings, then check whether the issue occurs at every source boundary or only after network disruption. A player can buffer or display a temporary state that is not present in the encoded file.
If the destination drops frames or reports an unstable connection, diagnose that separately from a source seam. The guide to dropped frames on YouTube Live explains why network and encoding problems should not be treated as the same symptom.
Keep a small test output and the original source until the broadcast has been checked. If you change several settings at once, you may lose the ability to tell whether the improvement came from trimming the endpoint, changing the container, altering audio or correcting the destination configuration.
For a dependable overnight setup, write down the source filename, the exact command or service settings, the selected audio behaviour and the point at which the loop was observed. That record is more useful than a vague note that the stream was tested once.
A practical decision path
Start with the simplest case: one complete fireplace clip, no edits required, and a finite output file. Use -stream_loop -1, put it before -i, set the output length with -t and try stream copy.
Then inspect the first and last frames. If either endpoint contains unwanted black, trim or rebuild the source. If neither is black but the images differ, call it a seam rather than a black-frame problem and decide whether a different cut or a deliberate transition is appropriate.
Next, check audio. Omit it if the channel is meant to be silent. Otherwise confirm that its duration and boundary behaviour match the video. A longer audio stream can make a video appear to hold its final frame or can make the join appear late.
Finally, decide whether you need a file or a live broadcast. For a file, validate the container and playback. For YouTube, confirm the current destination settings and watch the actual broadcast. Do not treat a successful local file as confirmation that every ingest path will accept it.
This approach keeps three separate questions apart: whether the input repeats, whether the media boundary is clean and whether the destination receives a continuous live signal. Each has a different remedy.
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 a black frame?
No. It repeats the input, including any black frame already encoded at its beginning or end. Inspect and edit the source if an endpoint needs to be removed.
Why does my loop jump even though there is no black frame?
The first and last images may simply be different. A seamless result requires a suitable source boundary or an edited transition, and either option may require re-encoding.
Can I use -c copy for every looped video?
No. Stream copy depends on the source streams, timestamps and target container being compatible. It also cannot perform trimming, filtering or other edits to the frames.
Is the loop command enough for a 24/7 YouTube broadcast?
No. It creates a finite file unless you send the output to a correctly configured live destination. Confirm the destination's current ingest settings and verify the broadcast in its player.