A single local video can be sent repeatedly to YouTube Live with FFmpeg. Put -stream_loop -1 before the input file’s -i option, and add -re so FFmpeg reads the file at its normal playback rate rather than as fast as the computer can process it.
That command pattern repeats the file, but it does not by itself guarantee a healthy live broadcast. You still need the current YouTube ingest URL, a suitable encoding configuration, enough upload capacity, a protected stream key and a way to notice when the process or connection has stopped.
Prepare the video and YouTube details
Start with the file you actually intend to broadcast. Check its filename, location, duration, resolution, frame rate and audio before building the command. A file that plays correctly in a media player can still cause trouble at the live-output stage if it has unusual timestamps, no audio stream, variable frame rate or a codec that your chosen output cannot use reliably.
You do not need to make the source file perfect before testing, but you should know what it contains. For example, a devotional video with a still image and an audio track has different practical requirements from a 1080p video with frequent movement. The latter generally needs more upload capacity at the same resolution and frame rate.
In YouTube Studio, open Live Control Room and create or select the broadcast. YouTube provides an ingest server URL and a stream key for the encoder. The key functions as a password for the stream, so copy it carefully and do not place it in a public tutorial, screenshot, repository or shared command history. YouTube’s official encoder setup guidance explains where these details appear and how a scheduled broadcast may require you to start it after the preview arrives.
Use the exact URL supplied by Live Control Room rather than guessing an ingest address. YouTube recommends RTMPS, the secure form of RTMP, and the current URL can vary with the setup shown in your account. If your FFmpeg build supports RTMPS, use the RTMPS address that YouTube gives you.
Also confirm that FFmpeg is installed and available in the environment where the command will run. On a desktop, that may be a terminal on your computer. For an always-on channel, it may be a remote machine that remains powered and connected. The command below is an illustrative pattern, not a tested command or a guarantee that your file, build, network and YouTube broadcast will work without adjustment.
Put -stream_loop before the input
The option placement is the part that catches many first-time users. -stream_loop is an input option, so place it before the -i belonging to the file you want to repeat:
ffmpeg -stream_loop -1 -i input.mp4 ...
The value -1 means loop indefinitely. FFmpeg keeps reading the input again when it reaches the end, until you stop the process or another failure interrupts it. The option does not create a new, permanently expanded video file. It tells FFmpeg how to continue consuming the input while the output is running.
The official FFmpeg command-line documentation describes -stream_loop as an input option and defines -1 as an infinite loop. That distinction matters when a command has more than one input. Each input option needs to be positioned so that FFmpeg applies it to the intended input.
For a single file, this is the useful order:
ffmpeg [input pacing] [input loop] -i [input file] [output options] [destination]
For example, this is not equivalent in a reliable way:
ffmpeg -i input.mp4 -stream_loop -1 ...
Here the loop option appears after the input it is meant to control. Depending on the option and FFmpeg version, it may be treated differently from what you intended or fail with an option-placement error. Keeping input options before -i makes the command’s meaning clear and follows the documented usage.
A loop is also different from a playlist. If you later need several files, different durations or scheduled changes, a single -stream_loop option is no longer the whole design. You may need a concat input, a playlist process or a separate workflow. For one video repeated continuously, the input loop is the simpler mechanism.
Read a local file in real time
A local file is normally read as quickly as FFmpeg can decode it. That is useful when converting a file, but it is unsuitable for a live destination. Without pacing, FFmpeg may send several minutes of material in a short period, then finish the file and begin again. YouTube expects a live encoder to provide media according to the selected frame rate and audio clock, not in bursts based on available processing speed.
Add -re before the input:
ffmpeg -re -stream_loop -1 -i input.mp4 ...
FFmpeg documents -re as reading the input at its native frame rate, equivalent to using a read rate of one. In this local-file situation, it makes FFmpeg behave more like a real-time source. It is particularly important when sending a file to a live output.
This advice is specific to the local-file workflow. Do not add -re automatically to every FFmpeg command. A camera, microphone or another genuine live input is already arriving in real time, and applying unnecessary rate control can create a different set of problems. The pacing option is useful here because the source is a file that otherwise can be consumed faster than playback speed.
Pacing does not repair an irregular source. If the input has broken timestamps, a damaged audio stream or a frame rate that changes unexpectedly, the output may still stall or drift. Watch the FFmpeg console for warnings, and test the complete file rather than assuming that the first few minutes represent its behaviour at the loop boundary.
The loop boundary deserves particular attention. When FFmpeg reaches the end, it starts the file again, but the transition can expose timestamp, audio or buffering issues that are not obvious during the first pass. A short test that crosses at least one boundary is more useful than checking only the opening minute.
Choose codecs, bitrate and container settings
A source file’s existing codecs are not automatically the best live-output settings. Stream copying can reduce CPU use because FFmpeg does not re-encode the audio and video, but it depends on the source streams, timestamps and output muxer being suitable. A file that plays locally is not proof that stream copy will produce a stable YouTube input.
Re-encoding gives you control over the output. The illustrative pattern below uses H.264 video, AAC audio and an FLV output container, which are common choices for an RTMP or RTMPS live workflow:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast \
-b:v 4500k -maxrate 4500k -bufsize 9000k -g 60 \
-c:a aac -b:a 128k \
-f flv "rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
This command is a template, not a universal recommendation. It has not been executed or tested against your file, FFmpeg build, computer, upload connection or YouTube account. Replace the destination with the precise URL and key supplied by Live Control Room, and choose the encoding values for the video’s resolution and frame rate.
The -c:v libx264 option selects H.264 video encoding. -preset veryfast is a speed-versus-compression choice. Faster presets generally reduce the work required from the computer, while slower presets can use more processing to achieve similar visual quality at a given bitrate. For an unattended channel, a setting that leaves sensible processing headroom is usually more useful than one that leaves the computer operating at its limit.
The bitrate options should not be copied without checking the current YouTube guidance. YouTube’s encoder settings page lists H.264 guidance of a 5 Mbps minimum and 14 Mbps recommended bitrate for 1080p at 30 frames per second, and a 3 Mbps minimum and 8 Mbps recommended bitrate for 720p at 30 frames per second. Those figures are platform guidance, not a promise that a particular connection or video will work. They may change, and they do not cover every resolution, frame rate and codec combination.
The sample uses a constant-looking video rate through -b:v and -maxrate, with a buffer value and a GOP setting. The -g 60 value only makes sense in relation to the frame rate. At 30 frames per second, it represents a two-second keyframe interval. At another frame rate, the interval changes. YouTube currently recommends a two-second keyframe interval and says it should not exceed four seconds, so calculate the value from the output frame rate rather than treating 60 as a magic number.
The audio setting selects AAC at 128 kbps. Check that the input has an audio stream and that it is acceptable for the content. If the source is silent by design, you may need to decide whether to provide a suitable audio track rather than relying on an absent stream. If the audio has a sample-rate or timestamp problem, re-encoding may help, but it cannot make unsuitable source material editorially acceptable.
YouTube’s current encoder settings also describe supported video and audio choices, frame-rate guidance and the need to match bitrate to the selected output. Review the current YouTube live encoder settings immediately before deployment, because platform recommendations can change.
Send the output to the current YouTube ingest URL
The final argument is the destination. In the pattern above, it is an RTMPS URL containing the server address and stream key supplied by YouTube. Do not substitute a URL found in an old article or copied from another channel. Open the relevant broadcast in Live Control Room and use the values currently displayed there.
The destination often has two conceptual parts: the ingest server address and the secret key. Your account may present them separately, while FFmpeg accepts a combined URL. Follow the format YouTube shows for your encoder. If the key contains characters that have special meaning in a shell, take care when quoting the complete destination. Double quotes around the URL are a practical starting point, but shell rules differ between Windows, macOS and Linux.
A successful FFmpeg process is not the same as a confirmed YouTube broadcast. FFmpeg can connect to an endpoint while YouTube is still waiting for a valid video signal, while the broadcast is scheduled but not public, or while the stream is suffering from insufficient bitrate. Treat the local console and YouTube’s preview as two separate checks.
The output format -f flv in the example tells FFmpeg to use the container commonly used for this type of ingest. It does not mean that every FLV combination is suitable. The codecs, timestamps, frame rate, bitrate and connection all matter. If you alter the command, change one important thing at a time so that a failure remains diagnosable.
For readers using a remote machine, remember that the upload path is the connection from the machine running FFmpeg to YouTube. A fast connection at your home or office is irrelevant if the process actually runs elsewhere. The selected bitrate must leave room for normal connection variation, and the machine must have enough CPU capacity to encode the chosen resolution and frame rate continuously.
Protect the stream key
Treat the YouTube stream key as a credential. Anyone who obtains it may be able to send content to the broadcast until you revoke or replace it. Do not publish a complete command containing the real key in a forum post, screen recording, public Git repository, support ticket or shared document.
Use a placeholder while troubleshooting in public:
rtmps://server-address.example/live/REPLACE_WITH_PRIVATE_KEY
Be careful with shell history as well. A command entered directly into a terminal can remain in the history file, and process listings or logs may expose command arguments depending on the operating system and how the process is started. Limit access to the machine and to any automation files containing the destination.
If you think the key has been exposed, return to YouTube Live Control Room and regenerate or replace it using the controls provided there. Then update the encoder with the new value. Do not assume that deleting a screenshot or editing a post removes copies that may already have been seen or stored elsewhere.
Your video file can also contain information worth checking. Metadata, filenames and visible overlays may reveal a location, a private event or a client’s details. Credential safety and content safety are separate concerns, and both matter when a local file is sent to a public live channel. If the material includes music, worship recordings, news clips or other third-party material, check the permissions and YouTube’s current policies before broadcasting. A looped file does not receive different copyright treatment merely because it is sent live.
Test playback and monitor stream health
Start with a private or otherwise controlled test where that suits your channel and YouTube account. Launch FFmpeg and watch the console for connection errors, encoder failures, repeated timestamp warnings, dropped frames or a process that exits unexpectedly. Then open the incoming preview in Live Control Room.
Check the actual picture and sound, not only the fact that the preview exists. Listen for audio clipping, silence, hum and a mismatch between speech and movement. Look for unexpected black frames, stretched images, broken text and changes at the point where the file loops. Test the same kind of content you plan to run overnight: if the final channel is mostly music with a static visual, test that combination rather than a short high-motion clip.
YouTube’s stream health indicators can reveal issues that the local process does not. Watch for unstable incoming bitrate, warnings about keyframes, missing audio or insufficient upload capacity. The exact labels and interface can change, so use the current controls in Live Control Room rather than relying on an old screenshot.
For a scheduled stream, YouTube may show an incoming preview before the broadcast is publicly live. Follow the control-room instruction to start or go live when the preview is ready. Starting FFmpeg is only the encoder step; the YouTube broadcast state is controlled separately.
Let the test continue beyond the end of the file. Confirm that the second pass begins with the expected picture and audio, and that the process does not accumulate delay or stop at the boundary. A short source creates more frequent loop transitions, so it is especially useful for exposing repeated-start problems before you trust the setup for a longer run.
Also test recovery deliberately. Stop FFmpeg and start it again, disconnect the network only if you can do so safely, and observe what YouTube displays during the interruption. The loop option does not restart a crashed process, repair a failed network route or prevent YouTube from ending a broadcast. If you need a recovery plan, document how the process is restarted and how you verify that the channel is live again. A separate guide on restarting a YouTube 24/7 stream after disconnection covers that operational problem.
For a long-running channel, choose the execution environment with care. A personal laptop can work for a test, but sleep settings, updates, power cuts, Wi-Fi changes and accidental closure make it a fragile unattended host. A remote machine can remove some household interruptions, but it still needs monitoring, access control and a recovery procedure. A Raspberry Pi may suit some low-demand files, while a higher-resolution re-encode may need more processing headroom; the relevant choice depends on the file and settings, not on the loop option itself. You can compare the constraints in Can a YouTube ambience stream run from a Raspberry Pi before choosing where FFmpeg should run.
If the main problem is keeping a computer running, StreamNeo removes that particular maintenance task by taking an uploaded video, your YouTube stream key and the continuous broadcast out of your local desktop workflow. It is still your responsibility to choose lawful content, configure the channel and check that the resulting YouTube stream behaves as intended.
A looped video is also not always the best editorial format. A news channel may need changing material, a study channel may need a schedule and a worship channel may need clear transitions between services or tracks. If your content needs regular replacement rather than endless repetition, see how to keep a news loop fresh without restarting for the operational question of changing material while a channel remains active.
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
What does -stream_loop -1 do?
It tells FFmpeg to repeat the associated input indefinitely. The option belongs before that input’s -i, and the process continues until you stop it or an external problem interrupts it.
Why is -re needed for a local file?
A file can otherwise be read faster than real time. -re paces the local input at its native frame rate, which is appropriate when sending the file to a live destination. It is not a setting you should apply automatically to a genuine camera or microphone input that is already live.
Does looping guarantee that YouTube will stay live?
No. Looping only controls how FFmpeg consumes the file. Network interruptions, an exited process, unsuitable encoding settings, missing audio, ingest problems or YouTube’s broadcast state can still interrupt the stream, so test and monitor the complete setup.
Can I reuse the same stream key?
Use the key shown for the broadcast you are configuring, and keep it private. If it is exposed, replace or regenerate it in YouTube Live Control Room and update FFmpeg before sending content again.