To repeat one local video on YouTube Live with FFmpeg, create a Live event, check the file, and place -stream_loop -1 before that file’s -i input. YouTube must still accept the encoder feed and show a preview; a correctly formed command alone does not guarantee a successful broadcast.
The workflow below keeps the moving parts separate: YouTube event setup, file inspection, looping and pacing, output settings, and validation. Use a placeholder for your stream key in any saved command, and do not treat a successful FFmpeg connection as proof that your rights, archive, or live status are in order.
Create or schedule the YouTube Live event
In YouTube Studio, open the Live Control Room and create a stream or select one you have already scheduled. Set its title, visibility, audience settings and planned start time in Studio. Those choices belong to the event, not to FFmpeg: FFmpeg sends the audiovisual feed, while YouTube controls the event page and the point at which a scheduled stream becomes public.
Choose the encoder workflow and keep the Live Control Room open while you prepare. YouTube’s guide to creating a live stream with an encoder describes copying the stream URL and stream key into the encoder, starting the encoder, and then checking the preview. For a scheduled stream, you normally use the preview to confirm the incoming picture and sound before selecting Go live.
YouTube supplies a server URL and a stream key. The key is credential-like: YouTube describes it as the password and address used by an encoder to send a stream. Keep it private, out of screenshots and public scripts, and replace it in examples with a label such as STREAM-KEY. If you expose a real key, reset it in the Live Control Room rather than assuming it is harmless because the video is not yet public.
Decide whether this is a one-off test, a scheduled broadcast or part of a recurring channel routine before you start the encoder. A private or unlisted test event can help you verify the chain without treating the public event as a debugging screen. For channels that mix recurring content, a weekday schedule for devotional live playlists is a separate planning problem from looping one file: an encoder cannot change the event schedule or choose the next programme for you.
Check the local file’s streams and rights
Before looping, establish what the file actually contains. A file named input.mp4 might contain video and audio, video only, or streams with codecs or dimensions that do not suit the output you intend to send. Use FFmpeg’s ffprobe if it is available to inspect stream types, codec names, duration, frame rate, dimensions and audio properties. You can also run ffmpeg -i input.mp4 to see the streams FFmpeg recognises; that command may exit with a non-zero status because no output was requested, which does not by itself mean the input is unreadable.
Check that the file plays from beginning to end in a local player, including the final seconds. A damaged tail, a blank interval, or a hard cut back to the opening frame will repeat each time. If there is no audio stream, do not include an audio mapping or assume YouTube will invent a soundtrack. If the picture is variable frame rate or the audio has a different sample rate from the example below, inspect the result after encoding rather than assuming the sample command fits.
Confirm that you have the necessary rights to broadcast every part of the file, including music, artwork, clips and any embedded third-party material. YouTube says live streams are scanned for third-party content; a match can replace the live image with a placeholder and, if the content remains, YouTube may interrupt or terminate the stream. A licence may not be enough on its own if the rights holder needs to add your channel to a Content ID allowlist. Review YouTube’s current copyright guidance for live streams before relying on permission for a long-running repeat.
Copyright permission and monetisation eligibility are different questions. YouTube’s monetisation policies say reused-content review is separate from copyright enforcement, and permission or a fair-use position does not automatically determine eligibility. A devotional recording, ambient loop or commentary video can be authorised and still need a separate assessment under the current policy. Do not use a successful test stream as evidence that monetisation will be approved.
Loop the file with -stream_loop before -i
FFmpeg defines -stream_loop as an input option. Set it before the -i for the file you want to repeat; -stream_loop -1 tells FFmpeg to loop indefinitely. In a command with more than one input, options placed before an -i apply to that input, so putting the loop option after the file input is not the same instruction.
The smallest useful shape is:
ffmpeg -stream_loop -1 -i input.mp4 -f null -
This is an input check, not a YouTube broadcast. It lets you confirm that FFmpeg can read repeatedly and reach the next pass. Watch the output at the loop point, and stop the test yourself when you have enough information. The command does not validate YouTube ingest, rights, or the final event state.
FFmpeg’s command-line documentation describes the loop option and its placement. The key detail is the position relative to the file input: -stream_loop -1 -i input.mp4. If you later add a separate music bed or logo source as another input, reason about each input independently and place its options before that input’s -i as well.
Do not confuse repeating a file with joining many files into a playlist. A single input loop repeats the same file from its start when it ends. If you need different clips to follow each other, you need a playlist or a different concat workflow, and the transitions and timestamps need their own checks. For a multi-file OBS route, see this guide to looping multiple prerecorded videos in OBS; it covers a different tool and does not replace FFmpeg input-loop syntax.
Use -re for live-paced reading where appropriate
A local file can be read as quickly as the computer can process it unless you pace the input. FFmpeg documents -re as reading at the file’s native frame rate, equivalent to -readrate 1, and notes that this is useful when output packet timing matters, such as live streaming. For a prerecorded file going to a live ingest, put -re before its -i too:
ffmpeg -re -stream_loop -1 -i input.mp4 -f null -
This means the looped input is read at its native rate rather than being consumed as fast as possible. It does not increase the file’s frame rate, repair irregular timestamps, or make the network connection stable. If the source is already a live capture or another input with real-time timing, adding -re can be inappropriate; follow the input’s characteristics rather than copying a flag mechanically.
Looping and pacing do different jobs. -stream_loop -1 says what FFmpeg should do at end of file. -re says how quickly it should read the file. You can have an infinite loop that races through a file, or a paced input that stops when it reaches the end. For a prerecorded feed meant to behave like a live output, you generally need both, but test the transition at the end of the file before using it on a public event.
Add YouTube output settings with a key placeholder
After the input, choose whether to pass through or encode the streams. A pass-through command using -c copy avoids video and audio re-encoding, which can reduce CPU demand, but only works when the source codecs, timestamps and stream layout suit the target ingest. It is not a universal shortcut. Transcoding gives you control over output codecs and bitrate, at the cost of encoder work and the possibility of stressing a modest computer.
YouTube recommends RTMPS for standard encoder ingestion. Its current encoder settings page lists supported video codecs and audio formats and explains that recommended bitrate depends on codec, resolution and frame rate. The example below is a starting shape only, with H.264 video and AAC audio; it is not a universal quality or bandwidth prescription. Check YouTube’s current encoder settings, bitrates and resolutions and match the chosen settings to the file, your encoder and your connection.
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \\
-g 60 -keyint_min 60 -c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://SERVER-URL/STREAM-KEY'
Replace input.mp4 with the file path, and replace the quoted output string with the server URL and stream key YouTube gives you. Keep the credential out of a script that might be shared, synced publicly or captured in a screenshot. The command assumes the input has video and audio and that FFmpeg was built with the libx264 encoder. Check available encoders on your installation; if your file has no audio, adjust the mapping and audio options rather than leaving a mismatched expectation.
The example includes a keyframe interval expressed through GOP options, but its numeric values are not a universal target for every frame rate. YouTube recommends a two-second keyframe interval and says it must not exceed four seconds. Work out the corresponding frame count for the output frame rate you choose, and confirm what your encoder is actually emitting. If you select a different resolution or frame rate, revisit the bitrate recommendation rather than keeping the sample value by habit.
| Choice | What you gain | What you need to check |
|---|---|---|
Stream copy (-c copy) |
Less re-encoding work on the computer | Input codecs, timestamps and layout must suit YouTube ingest |
| Transcode to H.264/AAC | Control over output codec and bitrate | CPU load, output settings and available upload capacity |
| Lower resolution or bitrate | Lower data rate and often less encoder work | Picture detail may be reduced; use YouTube’s current table |
| Higher resolution or bitrate | More picture detail when source and connection support it | Greater processing and upload demand; test before the event |
The practical decision is not “best bitrate” in isolation. A high bitrate does not restore detail missing from a low-resolution source, and a computer that cannot encode steadily may produce a worse feed than a more modest setting. A 1080p versus 1440p bitrate comparison can help frame the resolution trade-off, but use YouTube’s current table for the final configuration.
Verify upload capacity and the YouTube preview
Once your command is ready, test it against a test event or an event whose public start you control. Check FFmpeg’s console for input errors, encoder errors and repeated reconnects. If the feed connects but YouTube reports poor stream health, treat that as a signal to inspect bitrate, encoder load, network variation and output format; do not assume that FFmpeg’s process still running means viewers are receiving a healthy picture.
Your upload connection needs stable capacity above the actual outgoing bitrate, with room for ordinary variation and other devices using the connection. Compare the measured sustained upload performance at the place and time you plan to stream, not only a best-case speed result. In a small office or home, cloud backups, phone updates or another livestream can use capacity unexpectedly. If the connection is marginal, lowering the outgoing bitrate or resolution is often more useful than repeatedly restarting the same command.
In Live Control Room, wait for the incoming preview and inspect both picture and sound. Look for the correct file, a stable image, intelligible audio, and whether the end-to-start transition is acceptable. Check the stream health indicators and resolve warnings before selecting Go live for a scheduled event. YouTube recommends testing before a live event and monitoring stream health; those checks are separate from FFmpeg’s local status messages.
If the preview is black or silent, go back to the input inspection rather than changing multiple output flags at once. Confirm stream presence and mapping, confirm that your chosen encoder exists, and try a short local output file if needed. For a long-running radio-style feed, there are additional failure modes beyond the one-file loop; the FFmpeg long-broadcast troubleshooting guide is relevant when the process itself stops after a period of time.
Plan for archives and confirm the broadcast state
A repeated file can feed an event for as long as the process and ingest continue, but that does not mean every event becomes a useful archive. YouTube’s encoder setup guidance says streams under 12 hours are automatically archived. Do not assume the same for a stream lasting 12 hours or longer; plan to retain the source file and check the event’s archive and visibility settings in Studio.
Decide what viewers should see when the broadcast ends. If this is a scheduled event, use the Live Control Room’s event controls to end it and confirm the resulting state. Stopping FFmpeg ends the encoder feed, but do not assume that it also completes every event action you intend, such as making an archive public or arranging a redirect. Check the event page and the channel’s live list afterwards.
For a genuinely always-on channel, operating the encoder on your own computer means that computer, its power and network connection remain part of the chain. If you want the machine switched off without maintaining a local FFmpeg process, StreamNeo removes that specific burden by taking an uploaded file and running the YouTube broadcast without your computer being on; it does not change YouTube’s rights checks, ingest requirements or event controls. For a local setup, use a restart plan and keep logs so a dropped connection or ended process can be diagnosed rather than mistaken for a completed broadcast.
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
How do I loop a video on YouTube Live with FFmpeg?
Put -stream_loop -1 before -i for the local video, then configure an output compatible with the server URL and stream key shown in YouTube Studio. For a prerecorded file being sent to a live ingest, -re before the input paces reading at the file’s native frame rate. Verify the preview and stream health before going live.
How do I make FFmpeg repeat an MP4 forever?
Use -stream_loop -1 -i input.mp4; the loop option is an input option, so its position before the input matters. To send the repeated file at a live pace, use -re before that same -i. “Forever” describes the input loop, not guaranteed uptime: the process, computer, network and YouTube ingest can still fail.
Where do I find the YouTube Live RTMP URL and stream key?
In YouTube Studio’s Live Control Room, create or select an encoder stream and copy the server URL and stream key shown for it. Treat the key like a password, use a placeholder in examples and private notes, and reset it if it is exposed. YouTube recommends RTMPS for standard encoder ingestion.
Will YouTube archive a 24/7 livestream?
YouTube’s encoder guidance says streams under 12 hours are automatically archived, so do not rely on that automatic archive for a 24/7 broadcast. Retain your source file and check the current event and archive controls in Studio. An archive setting does not establish that you have the rights to broadcast the content or that a repeated stream will qualify for monetisation.