To loop a video file into YouTube Live, put -stream_loop -1 before the input and use -re so FFmpeg reads the file at real-time speed. Then send it to the RTMPS address and stream key from YouTube Live Control Room, with encoding settings adapted to your file and target stream.
That gives you a repeating input, not a guarantee of uninterrupted connectivity. Test the exact file, FFmpeg build, network and YouTube ingest before relying on it overnight; a process that is still running can still be sending a stream with problems.
Get the YouTube RTMPS URL and stream key
In YouTube Studio, open Live Control Room and create a stream or select the stream you intend to use. Find its stream URL and stream key in the encoder settings. The key is a credential: anyone who gets it may be able to send a broadcast to your channel, so do not paste it into a public script, screenshot, support post or shared document.
YouTube may initially show the ordinary RTMP address. Use the control in the Live Control Room settings to reveal the RTMPS address, then copy the address and key into your local command or a suitably protected configuration. YouTube describes RTMPS as a secure extension to RTMP and recommends it for live encoder connections. Check YouTube's encoder settings guidance and its instructions for creating an encoder stream when you set this up; the controls and guidance can change.
Keep the destination placeholder in examples until you are ready to run your own command. In the template below, replace the complete quoted destination with the exact RTMPS URL and key format shown for your stream. Do not assume that a generic URL copied from an old tutorial is the right ingest address for your current broadcast.
If you rotate or replace a stream key, update the local configuration as well. Treat command history and logs as places that could retain a key, particularly on a shared computer. A local file with restricted access or an environment variable can be preferable to repeatedly typing a credential into a shell command, but choose an approach you can manage and secure.
Put -stream_loop -1 before the input
The loop option belongs before the input it affects:
-stream_loop -1 -i input.mp4
-stream_loop -1 tells FFmpeg to repeat the input indefinitely. The position matters because FFmpeg options are applied in relation to inputs and outputs; placing the option after -i input.mp4 is not the same arrangement. The FFmpeg mailing-list example shows this ordering, but it is not a substitute for checking the options available in your installed build. See the FFmpeg-user discussion of looping an input, then check your own version's help if the command reports an unrecognised or misplaced option.
The command assumes a file input. Replace input.mp4 with the path to your media file. If the path contains spaces, quote it, for example -i "Morning Aarti.mp4". The option repeats the file; it does not stitch together separate files into a playlist. For a sequence, use a playlist or another input arrangement and test the transitions. This guide to looping several videos in sequence covers a different input pattern.
A loop boundary is worth checking rather than taking for granted. A file may have audio and video streams with different durations or timestamps, and the hand-off from the end to the start may reveal a pause, click, jump or other discontinuity. The sources do not establish that every file can be looped cleanly or stream-copied across its boundary. Watch and listen to the actual transition during testing.
Use -re for real-time file reading
A file can be read faster than its playback speed. For a live broadcast, that is usually not what you want: FFmpeg needs to pace file reading approximately in real time rather than race through the input. Put -re before the input as shown here:
-stream_loop -1 -re -i input.mp4
This is useful for a prerecorded programme sent as a live stream. It does not create a live camera feed or repair bad timestamps, unsupported codecs or network interruptions. It simply changes how FFmpeg reads the file. If you omit it, do not assume that FFmpeg will automatically pace a local file as a viewer would watch it.
You can check whether the output is progressing at a plausible rate while the command runs, but that alone is not proof of a healthy YouTube stream. Confirm the actual preview and stream-health messages in Live Control Room. An encoder may keep writing output while YouTube reports a warning, or while viewers encounter a problem.
Choose compatible encoding settings
You have two broad choices: copy compatible streams or re-encode them. Stream copy can reduce the work FFmpeg does, but it does not transform a file into a format YouTube accepts. It is only worth trying when the file's video and audio codecs, format and timing already suit the selected ingest settings. Inspect the file first and test the exact command, including a loop boundary.
Re-encoding gives you more control over codec, frame rate, pixel format and bitrate, at the cost of additional processing. The example below uses H.264 video and AAC audio as a starting point. YouTube's current guidance lists H.264, H.265/HEVC and AV1 for video, and AAC or MP3 for audio; available encoder names also depend on how FFmpeg was built. Check your installed build rather than assuming a particular encoder is present.
Bitrate is not a universal constant. YouTube's table varies with codec, resolution and frame rate. For H.264 at 1080p30, YouTube lists 5 Mbps as its recommended video bitrate; that example does not make 5 Mbps appropriate for every source or ingest target. Choose the row that matches your intended stream, and make sure the connection's sustained upload capacity can carry the output along with normal network variation. If your file is lower resolution, a higher output setting will not restore detail that is not in the source.
| Choice | What it changes | When to consider it |
|---|---|---|
Stream copy (-c:v copy -c:a copy) |
Sends existing encoded streams without re-encoding them | The input is already compatible, and testing confirms its timestamps and loop boundary behave as required |
| Re-encode video and audio | Sets output codecs and parameters explicitly | The input needs conversion or you need to control the ingest format |
| RTMPS rather than RTMP | Encrypts the transport connection | The encoder supports the secure URL supplied by Live Control Room |
| Lower or higher target bitrate | Changes output data rate and potentially picture quality | The chosen value matches YouTube's guidance for the output format and your upload connection can sustain it |
The table describes trade-offs, not a ranking. Re-encoding a high-resolution file can put a meaningful load on the computer, while stream copy can fail to meet ingest requirements if the source parameters do not match. If you are comparing other ways to keep a prerecorded loop running, this article on video file-size limits in cloud loop services explains why file and operating constraints matter too.
Set the keyframe interval
YouTube recommends a keyframe interval of two seconds and says not to exceed four seconds. In an FFmpeg command, the common H.264 control -g sets the GOP size in frames. At 30 frames per second, -g 60 corresponds to two seconds if the encoder honours the requested frame rate and GOP setting.
That arithmetic changes with frame rate. At a different frame rate, recalculate the number of frames for the same interval; do not copy -g 60 unchanged and assume it still means two seconds. Also check the encoder's behaviour and YouTube's current guidance. The setting in a command is a request to the encoder, not evidence that the output file or live stream has the expected keyframes.
A two-second interval is a recommended target, not a promise that a particular combination will work. If you are adapting a command from OBS or another encoder, compare the actual frame rate and interval rather than copying a label. This keyframe interval explanation for YouTube reruns can help translate the same idea to another tool.
Build and review an adaptable command
This H.264 example combines the loop, real-time reading and output settings. It is a template, not a tested command for every file, FFmpeg build, account or ingest server:
ffmpeg \\
-stream_loop -1 -re -i input.mp4 \\
-c:v libx264 -pix_fmt yuv420p -r 30 -g 60 \\
-b:v 5M -maxrate 5M -bufsize 10M \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://<server>/<stream-key>'
The sample's 30 fps, 5 Mbps H.264 video bitrate and GOP size of 60 frames are an example aligned to YouTube's H.264 1080p30 bitrate recommendation and two-second keyframe guidance. Change them to match your chosen output resolution, frame rate, codec and YouTube bitrate table. The command does not set every quality or colour parameter you might need: inspect the source, identify the actual target and use the current encoder guidance.
The options have distinct jobs. -stream_loop -1 repeats the input, and -re paces reading. -c:v libx264 selects an H.264 encoder if that encoder is available in your FFmpeg build; -pix_fmt yuv420p requests a common pixel format. -r 30 requests 30 frames per second, while -g 60 requests a 60-frame GOP. The video bitrate controls are examples, not universal settings. The audio options select AAC, set an example bitrate and sample rate. The final format and destination send the muxed output to the ingest address.
YouTube recommends constant bitrate (CBR), progressive scan, square pixels and Rec. 709 for SDR, alongside its codec and bitrate guidance. A short template cannot ensure those properties for every source or encoder. Review the output settings you are actually producing, especially if the source is interlaced, has a non-square pixel aspect ratio, uses HDR or has no audio. Do not add a made-up silent audio track unless your output and ingest needs call for it.
If you choose stream copy, the command's encoding settings need to change, for example to -c:v copy -c:a copy, and the file must already meet your requirements. Copying is not a fallback that makes an incompatible source safe. The boundary between repeats is also part of the test: do not infer reliable looping from a short preview that never reaches the end of the file.
For an unattended broadcast, separate the local FFmpeg process from the platform's view of the stream. Restarting a process after it exits may address one class of failure, but it cannot fix a weak upload connection, an unhealthy input or an ingest warning. If you need to plan for a remote host, the practical points in monitoring a 24/7 stream on a remote server are relevant beyond the command itself.
Test the stream before relying on it
Use a test broadcast before making the stream part of a daily schedule. Where appropriate, set the event to unlisted or otherwise choose an audience setting that suits your test. Start FFmpeg and check YouTube's preview and stream-health panel while the output is running. YouTube recommends testing before going live and monitoring stream health and messages during the event.
Check the picture and audio at the start, then watch the transition when the file loops. Look for a black frame, a gap, a frozen image, an unexpected audio break or a warning in YouTube Studio. Confirm that the output resolution and frame rate are what you intended, and that the stream's data rate is sensible for your chosen settings. If the process exits, read its error output; if it continues but the preview is unhealthy, troubleshoot the ingest or media rather than treating process status as proof of success.
A computer running the command also needs to remain powered, connected and able to do the work of encoding if you are re-encoding. A network outage or operating-system restart can interrupt the broadcast. A script that restarts FFmpeg may help with a process failure, but it does not guarantee reconnection or a clean YouTube stream. Plan who will notice a warning and what they will do when the stream drops. If maintaining a local computer through the night is the specific problem, StreamNeo removes that particular need by letting you upload a video and provide the YouTube stream key for a cloud-run broadcast; it does not remove the need to check the stream and channel settings.
Do not treat “nonstop” as a promise about YouTube's archive. YouTube's encoder setup page says streams under 12 hours are automatically archived. That statement does not establish what happens to an uninterrupted stream that runs longer, or that one long broadcast will be archived as one complete video. If you need a recording, plan an archive approach around YouTube's current documentation and test it separately.
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 go before or after -i?
Put it before the input it should repeat: -stream_loop -1 -i input.mp4. In this use, add -re before the same input to pace file reading in real time. If your installed FFmpeg reports an option error, check that build's help and version rather than assuming every installation has identical options.
Can I use -c copy instead of re-encoding?
Only if the file's existing streams and parameters are compatible with your chosen YouTube ingest settings. Copying saves the work of encoding but does not convert codecs, frame rates or other media properties. Test the complete file and the transition back to its start before relying on it.
Is 5 Mbps the right bitrate for every loop?
No. YouTube lists 5 Mbps as its recommended H.264 bitrate for 1080p at 30 fps, while its table varies by codec, resolution and frame rate. Use the current row for your target format and consider whether your upload connection can sustain that output.
Does a running FFmpeg process mean YouTube is receiving a healthy stream?
No. A live process can still send media that YouTube flags as unhealthy, or lose a useful connection while it remains open. Check the preview and stream-health messages in Live Control Room, and test the actual file and network before leaving the broadcast unattended.