To loop one MP4 on YouTube Live with FFmpeg, put -stream_loop -1 before the file input, pace that input with -re, and send the output as FLV to the RTMP or RTMPS address shown in YouTube Live Control Room. You then check the incoming preview and stream health before starting the public broadcast.
The command below is a starting template, not a tested recipe for every file, FFmpeg build or YouTube account. Your codecs, audio streams, resolution, frame rate, bitrate and upload connection may require changes. A loop can also have a visible or audible join; inspect the transition rather than assuming it will be seamless.
Prepare the MP4 and YouTube Live stream
Keep the MP4 on a computer with a stable internet connection and prevent that computer from sleeping while FFmpeg is running. Check that the file plays locally, that its path is correct, and that it contains the video and audio you expect. If you are on Windows, paths containing spaces need quoting; on macOS or Linux, you can quote them too to avoid shell interpretation problems.
Before encoding, find out what streams the file contains. FFmpeg can report this with ffmpeg -i input.mp4; it may print information and then exit with an error because no output was specified, which is normal for an inspection-only command. Look for a video stream, an audio stream, their codecs, dimensions and frame rate. If there is no audio stream, a command that assumes one may fail or produce unexpected output. If there are multiple audio tracks, decide which one you intend to publish.
In YouTube Studio, open Go Live and create or select an encoder stream. Live Control Room supplies a server URL and a stream key. You need both: the URL identifies the ingest destination and the key identifies the stream YouTube should associate with the incoming feed. YouTube’s encoder setup instructions describe this connection process. Treat the key as a credential. Do not paste it into a public post or share a screenshot that exposes it; if it is exposed, reset it in Live Control Room and update the command.
For a first test, use an unlisted stream if that suits your channel workflow, and confirm the channel is ready to go live. A scheduled stream can show an incoming preview before you press Go live. Keep the Control Room open while you test. If you have not used these values before, this guide to finding YouTube’s RTMP server URL and stream key covers the YouTube-side details.
Build the input with infinite looping
The basic pattern is:
ffmpeg -re -stream_loop -1 -i "input.mp4" \\
-c:v libx264 -c:a aac \\
-f flv "rtmps://SERVER/APP/STREAM_KEY"
Replace input.mp4 with the actual path. Replace the destination placeholder with the complete RTMP or RTMPS URL and key copied from Live Control Room. The example uses RTMPS as the scheme, but that is only correct if the URL YouTube provides is an RTMPS URL. Do not type rtmp[s] literally: choose the actual scheme and destination supplied by YouTube.
The important loop option is -stream_loop -1. FFmpeg documents -stream_loop as an input option: -1 requests infinite looping, while other values describe a finite number of repeats. Its placement before -i associates it with the input that follows. With one MP4, the looped input is the same file on each pass. If you put the option after -i, it may not apply to the intended input. See FFmpeg’s input option documentation for the option’s scope and behaviour.
The example re-encodes video with libx264 and audio with AAC. These are common choices for an RTMP/FLV workflow, but the command depends on your FFmpeg build including those encoders and on the input having an audio stream. If FFmpeg reports an unknown encoder, check the build or select an encoder it supports. If it reports that it cannot find an audio stream, omit -c:a aac or configure an explicit audio source or mapping rather than expecting a track that is not there.
This template leaves several output details to defaults. Depending on the file and your target, you may need explicit stream mapping, scaling, frame-rate conversion, bitrate control, keyframe interval or audio settings. Do not add settings by guesswork. Inspect the input first, then choose output parameters that fit both YouTube’s current encoder guidance and your available upload capacity.
Pace the file in real time
A local file can be read much faster than its playback duration. A live destination needs a stream delivered at approximately playback speed, rather than a burst of the whole file as quickly as the computer can read it. The -re option tells FFmpeg to read the input at its native rate, which is why it appears before -i in the pattern above.
The order therefore has two useful parts: -re paces the file input, and -stream_loop -1 tells that input to repeat indefinitely. Both are placed before the input filename. This is different from placing output options after -i: options in FFmpeg apply according to their position and scope, so changing the order casually can change what they affect. FFmpeg’s streaming examples include an RTMP output using real-time input pacing and FLV formatting.
Real-time pacing does not make the computer or connection reliable by itself. If the machine sleeps, the network drops, FFmpeg exits or the source file cannot be read, the broadcast can stop or become unhealthy. For a one-off test, watch the process and Control Room. For a long-running channel, weigh the maintenance burden of leaving a personal computer running against other approaches. Readers comparing hosted workflows can use this overview of cloud video streaming platforms for YouTube creators, while remembering that service features and channel requirements need checking directly.
Send FLV output to YouTube over RTMP or RTMPS
The -f flv part tells FFmpeg to package the encoded output as FLV, a format used for RTMP publishing. YouTube supports RTMP and recommends the encrypted RTMPS variant. YouTube says on its encoder settings page that it recommends streaming with RTMPS, a secure extension to RTMP. Use the specific URL supplied for your stream; do not substitute a guessed host or path.
The protocol and encoding are separate choices. RTMPS encrypts the connection in transit; it does not fix an unsupported codec, inadequate upload capacity, a wrong key or a malformed command. Likewise, choosing H.264 in the example does not determine the bitrate by itself. YouTube’s published recommendations vary with resolution, frame rate and codec. As listed on YouTube Help’s encoder settings page in October 2026, it recommends a two-second keyframe interval and says not to exceed four seconds; its page also lists frame rates up to 60 fps. Check that page when selecting settings, since the appropriate bitrate depends on the output you intend to send.
An FFmpeg command with no explicit bitrate is useful for demonstrating the connection pattern, but it should not be mistaken for a complete quality configuration. For example, if the MP4 is high resolution and the encoded output exceeds what the connection can sustain, YouTube may report unstable health or the preview may buffer. If you add bitrate and keyframe parameters, set them deliberately for the intended resolution and frame rate, then test rather than assuming the source file’s properties are automatically suitable.
Enter the server URL and stream key
Copy the full server URL from Live Control Room and append or combine the stream key exactly as YouTube’s interface specifies for the chosen encoder destination. In the template, the entire destination is represented by rtmps://SERVER/APP/STREAM_KEY. That text is explanatory only. A real destination is an actual URL and key, with no placeholder words or brackets.
Keep the destination quoted, especially if it contains shell-sensitive characters. The key may include characters that the command line interprets specially, so quoting the whole URL is a sensible default. Avoid putting a real key in material you plan to publish, a shared script, or a screen recording. If you need to keep a reusable command, store the secret privately and replace it only when running the encoder. A key that has been exposed should be reset in YouTube and replaced in the command.
When FFmpeg starts, read its console output. A successful connection should progress to ongoing output rather than immediately exiting with an authentication, protocol or connection error. The console is not a substitute for the YouTube preview: it tells you what FFmpeg is doing, while Live Control Room shows whether YouTube is receiving and processing the feed. If you have a stale key after changing streams, copy the current values again rather than reusing an old destination.
Check the preview and stream health
Wait for the incoming preview in Live Control Room. Check picture, motion, audio level and whether the image is cropped or letterboxed as expected. A static image can make a connection appear fine while hiding a playback or loop problem, so test a section with representative movement and sound. Let the clip reach its end and watch the transition back to the beginning. The loop may not be visually or audibly seamless because of the encoded frame boundaries, timestamps or audio cut; edit the file or adjust the workflow if the join is distracting.
YouTube’s encoder guidance advises testing with representative audio and movement and checking stream health. Review the indicators shown in Control Room rather than judging only from the local FFmpeg process. If the stream is scheduled, the incoming preview is not necessarily the public broadcast: use the Go live control when you are satisfied and ready to publish. To finish, stop sending from FFmpeg and use End Stream in Live Control Room as appropriate.
YouTube says that streams under 12 hours are automatically archived; do not assume the same archive behaviour for longer streams. If preserving a recording matters, make a separate recording plan and check YouTube’s current guidance. A recurring channel also needs a plan for what happens if the local computer, power or broadband fails. This article on keeping a church stream running during Indian power cuts explains why power continuity is a separate issue from a correct FFmpeg command.
StreamNeo addresses a different part of that continuity problem for a file-based channel: you upload the video and provide the YouTube stream key, so the broadcast can keep running without leaving your own computer on, with monitoring and restart handling if it drops. It is YouTube-only, and it does not remove the need to prepare a suitable file or verify the stream in YouTube.
Troubleshoot common connection or playback issues
If FFmpeg says it cannot open the input, first check the filename, path, file permissions and quotes. Run the inspection command against the exact same path. If the file opens but the command fails at encoding, check the encoder names available in your build and whether the input includes the stream you are trying to encode. libx264 and AAC are choices in the example, not a guarantee about every package or file.
If the connection is rejected, copy the current URL and key again from Live Control Room. Check that you used the supplied RTMP or RTMPS scheme, that no placeholder text remains, and that the destination has not been clipped by a shell character or line break. A stream key is sensitive and can be reset; if you reset it, update the command too. YouTube’s documentation is the authority for its connection flow, not a URL copied from an old tutorial.
If the preview appears but is unhealthy, examine upload stability and output settings. Compare your selected resolution and frame rate with YouTube’s current codec and bitrate recommendations. A connection that works for a few moments may still struggle when encoding load increases or network capacity changes. Reducing output resolution or frame rate can be more useful than repeatedly changing unrelated command options, but the correct adjustment depends on the source and channel needs.
If the picture is present but there is no sound, inspect the file for an audio stream and then review FFmpeg’s stream mapping and audio encoder. If the video repeats but the restart sounds abrupt, listen at the boundary and consider preparing a file with a cleaner edit. No command-line loop option can make every MP4’s join seamless. To compare what happens with other repeat workflows, see how OBS can reopen a looping sleep video; its playback mechanism differs from FFmpeg’s input loop, so use it as a related workflow rather than a command substitute.
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 make the MP4 repeat forever?
It asks FFmpeg to repeat that input without a set repeat count while the process continues. It does not keep the computer awake, restore a failed connection or ensure that YouTube keeps the broadcast live. Those depend on the machine, network, command and YouTube-side stream state.
Why does -stream_loop -1 go before -i?
-stream_loop is an input option, so it belongs before the input it should affect. With one input, placing it before -i input.mp4 makes the intended scope clear. FFmpeg options are position-sensitive, so do not move it casually.
Can I use this command unchanged for every MP4?
No. The template assumes an FFmpeg build with the named encoders and an input whose streams suit the command. You may need to change mapping, codecs, scaling, frame rate or bitrate, and should verify the preview and loop boundary with your own file.
Is RTMPS required?
YouTube recommends RTMPS, but use the actual server URL supplied in Live Control Room. The protocol secures transport; it does not guarantee stream health or correct encoding. Check YouTube’s current instructions if the available destination or workflow differs.