To repeat an ocean video while FFmpeg sends it to YouTube Live, put -stream_loop -1 before the input file’s -i option. Use -re before that input as well so FFmpeg reads it at its native rate, then choose output settings for the YouTube ingest protocol you actually selected.
The command below is an illustrative starting point, not a universally tested recipe. Looping the file does not guarantee an uninterrupted broadcast: the source, encoding load, upload connection, FFmpeg process and YouTube ingest all matter.
Check the input video and audio
Before building a command, play the ocean video from beginning to end, including the point where it will return to the opening. Check that the picture is the version you intend to broadcast and listen to the audio track. A video with no audio track will not acquire one simply because FFmpeg loops it. If you want sound, decide whether the source should be silent or whether you need to add a separate audio input and configure it deliberately.
Consider the loop seam too. A wave that changes abruptly back to the start, a jump in ambient sound, or a brief silence may be noticeable even when the file repeats correctly. -stream_loop repeats the input; it does not blend the end into the beginning. If you need a smoother transition, edit the source or prepare a version with a crossfade and test that edit before sending it live.
Check basic properties such as resolution, frame rate, and whether audio is present. FFmpeg can probe media with ffprobe, which is distributed with many FFmpeg builds. For example, ffprobe -hide_banner ocean.mp4 prints stream information in the terminal. The exact output depends on the file. Do not assume that a high-resolution source is automatically the right output: encoding and uploading it require suitable capacity, and YouTube’s current guidance should inform the choice.
It is worth keeping a copy of the original file and testing with a duplicate or a short representative export. If you change the resolution, frame rate, audio, or loop seam, make the change explicit in your workflow rather than expecting the loop option to correct a source problem. For a broader pre-broadcast routine, see this checklist for testing a 24/7 Indian music stream before going live.
Place -stream_loop -1 before the input
FFmpeg options have scope. -stream_loop is an input option, so place it before the -i that names the file it should repeat. The FFmpeg command-line documentation describes -stream_loop as controlling the number of times an input stream is looped, with -1 meaning an infinite number of repetitions.
In a simple command, the relevant placement looks like this:
ffmpeg -stream_loop -1 -i ocean.mp4 ...
The position is functional, not cosmetic. If you put the option after -i ocean.mp4, it may no longer apply to that input as intended. If you later add another input, such as a separate audio file, make sure the option is before the particular -i whose media you mean to repeat. Input-specific options should not be treated as global decoration.
This option is not the same thing as FFmpeg’s video-loop filter. The filter works in a filter graph on video frames; -stream_loop repeats an input stream. For the straightforward case of replaying an entire ocean file, the input option is the mechanism shown here. If your task is to repeat only a section, combine media, or make a transition, that is a different editing problem and needs its own filter or source preparation.
Indefinite repetition means FFmpeg is asked to keep reading the input again; it does not establish that every downstream part will remain healthy. A machine can run out of resources, a network can falter, or the ingest can reject output settings. Keep the distinction clear: looping handles repetition of the source, while maintaining a live broadcast is a larger operational job.
Use -re for native-rate reading
-re tells FFmpeg to read input at its native frame rate rather than consuming a file as quickly as it can be processed. Place it before the relevant -i, alongside other input-side options:
ffmpeg -re -stream_loop -1 -i ocean.mp4 ...
For a file-based live-style output, this helps pace the input as it would be presented over time. Without pacing, FFmpeg may process a local file faster than real time, which is not what you usually intend when sending a live feed. The option does not make an underpowered computer faster, improve an unstable connection, or set YouTube’s accepted encoding parameters.
If the command has more than one input, think through how each source is read and synchronised. A separate music or narration file may have its own duration and repetition needs. Do not add options by habit: decide which input each one applies to, and test the actual combination. The sample later in this article is intentionally limited to one video file with its own audio, if present.
A practical check is to run the command briefly and compare elapsed broadcast time with the media progression. If a ten-minute section appears to be consumed in seconds, the input is not being paced as expected. If FFmpeg reports decoding or timing problems, resolve those before interpreting YouTube’s ingest messages.
Choose compatible video and audio encoders
FFmpeg must encode the output in a format accepted by the protocol and settings you choose. For RTMP or RTMPS, YouTube’s live encoder settings list supported video codecs, including H.264, H.265/HEVC, and AV1, and AAC or MP3 audio. The same guidance covers frame rates, bitrate mode, keyframe timing, and recommended bitrate ranges. Check that current page rather than treating any single command as a permanent specification.
The illustrative command uses libx264 for H.264 video and AAC audio. That is a common FFmpeg pairing for an RTMP-family example, not a claim that it is the right choice for every machine or protocol. Your FFmpeg build must include the encoder you name. If FFmpeg says that an encoder is unavailable, check the build and local documentation rather than substituting an arbitrary codec.
For RTMP/RTMPS, YouTube’s guidance calls for constant bitrate (CBR) and recommends a two-second keyframe interval, with keyframes no more than four seconds apart. A command’s -g value is measured in frames, so it depends on frame rate. At 30 frames per second, -g 60 represents two seconds; at another frame rate, 60 frames represents a different duration. Set the GOP to fit the selected frame rate and the current YouTube guidance, rather than copying 60 without checking.
Audio settings need the same care. The sample uses AAC, 128 kbps and 44.1 kHz, values reflected in YouTube’s advanced encoder guidance for stereo audio. If the source audio is absent, mono, or at another rate, decide whether the intended output should preserve, convert, or supply audio. Listen to the result in the test stream; a technically accepted audio track can still be the wrong mix or have an obvious seam.
The trade-off is between matching source quality and producing a stream the encoder and connection can sustain. Higher output resolution or bitrate can preserve more detail, but it also demands more encoding capability and upload capacity. Use YouTube’s current bitrate table for the chosen resolution and frame rate, then check that your reliable upload capacity can support the planned output. The resolution-versus-bitrate guide can help frame that decision without replacing YouTube’s live recommendations.
Set output parameters for the ingest protocol
The output options must match the ingest protocol configured for the YouTube stream. RTMPS is YouTube’s recommended choice for RTMP-family ingestion in its encoder guidance. HLS is also documented, but it has a separate setup and higher latency because it sends video in segments. Do not take an RTMP/RTMPS command and assume its output format and URL can be reused for HLS.
| Choice | What to check | Practical implication |
|---|---|---|
| RTMPS | The RTMP-family codec and encoder guidance, CBR, keyframe interval, URL and key | The straightforward example below uses -f flv and a placeholder RTMPS destination. |
| HLS | HLS-specific protocol setup, supported codecs and HTTPS destination | Follow YouTube’s HLS setup; do not reuse the RTMPS destination or assume the same command applies. |
The current YouTube guidance for HLS ingestion describes its protocol requirements and setup. Consult it if HLS is needed for your workflow. YouTube describes higher latency for HLS than RTMP-family ingestion, so that difference may matter if viewers need a more immediate feed. The protocol is not merely a different spelling of the same URL.
In the sample, -f flv selects an output container commonly used for RTMP-family delivery. The video and audio codecs, bitrate controls, GOP, and output destination still need to agree with the selected ingest and the source. A container setting on its own does not make the stream compatible. If YouTube reports a configuration issue, compare the complete output and protocol against the current official instructions.
Adapt the illustrative command
For an RTMPS-style example with a video file that contains the audio you want, the command can be written as follows:
ffmpeg -re -stream_loop -1 -i ocean.mp4 \
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \
-g 60 -c:a aac -b:a 128k -ar 44100 \
-f flv 'rtmps://YOUR_INGESTION_URL/YOUR_STREAM_KEY'
This is illustrative only. It has not been tested universally, and the example bitrate and GOP are not suitable for every resolution, frame rate, encoder build, network, or YouTube stream. In particular, -g 60 is a two-second interval only at 30 fps. Choose a bitrate using YouTube’s current recommendations for your output and a realistic assessment of sustained upload capacity. Select a GOP in frames that yields the intended interval at your actual frame rate.
The options before -i ocean.mp4 apply to the input: -re paces reading and -stream_loop -1 requests indefinite repetition. The options after the input describe output encoding and delivery. -c:v libx264 selects the video encoder, -preset veryfast is an encoder speed/efficiency choice, and -b:v, -maxrate, and -bufsize are rate-control parameters. The sample uses AAC audio and specifies its bitrate and sample rate. The values are there to make the command legible, not to promise a particular result.
Replace ocean.mp4 with the exact local path to your file. Replace the placeholder destination with the ingest URL and stream key shown for the selected broadcast in YouTube Live Control Room. The YouTube Live API documentation describes the ingestion address as the destination for a stream, but for a normal setup use the values associated with your stream in the Control Room. Keep the stream key private: do not put a working key in a public tutorial, screenshot, shared terminal recording, or support post.
If the input has no audio, the sample’s -c:a aac does not invent meaningful sound. If FFmpeg errors on a missing audio stream, either configure output for the intended silent-stream behaviour or add a separate audio source with deliberate mapping and timing. Likewise, if you use HLS, start from its official setup rather than changing only the URL in this example.
For a 24/7 channel, also plan what happens if FFmpeg exits, the computer sleeps, or the network disconnects. This command does not supervise or restart itself, and a successful loop does not guarantee YouTube will continue accepting the feed. StreamNeo can remove the need to keep your own computer running for this particular uploaded-file loop, which is useful when the practical worry is an overnight machine or connection failure rather than editing the source.
Replace the ingest URL and protect the key
The placeholder is deliberately not a real destination. YouTube provides the ingestion URL and key through Live Control Room for the configured stream. Make sure you choose the protocol first, then use the corresponding URL and key; a valid key paired with a URL for a different protocol is not a working configuration. YouTube’s Live Streams API reference also explains ingestion information in the context of stream resources.
Treat the key like a password that can transmit to your channel. Avoid pasting it into a public command, a screenshot, a shared document, or a message that others can access. If you have exposed it, use YouTube’s controls to manage or replace the key and check that your local command has the current value. When sharing a diagnostic, redact the key and any URL component that embeds it.
A secure local workflow can keep the destination out of a script you plan to publish, but the exact method depends on your shell and operating system. Whatever approach you use, confirm the final command locally before running it and be cautious with shell history, screen sharing, and logs. Do not test with a live key in a public demonstration.
Run a short test and inspect output
Run a private or unlisted test before a public broadcast. YouTube recommends testing with audio and movement similar to the actual stream, checking upload capacity, and monitoring stream health and messages during transmission. A static ocean scene still needs representative motion and audio: use the actual file or a representative segment rather than a silent placeholder if the live version contains sound.
Watch the FFmpeg terminal for errors and confirm that YouTube receives the stream. In Live Control Room, inspect stream health, warnings, and the audio and video preview. Check whether the picture remains in motion, audio is present and at the intended level, and the stream reaches the expected output resolution. Observe a file boundary if the test runs long enough to reach the loop; a visible jump or audio discontinuity is a media issue, not something -stream_loop repairs.
If the broadcast stutters or drops, do not assume the loop syntax is at fault. Check sustained upload capacity, reduce output resolution or bitrate if the connection cannot carry the current output reliably, and compare the codec, bitrate mode, frame rate, keyframe interval, and audio settings with YouTube’s current requirements. The guide to why YouTube may end a live stream can help distinguish a stream-configuration or platform issue from an FFmpeg process stopping locally.
A test is evidence about that configuration and that moment, not a guarantee for a later overnight run. Long-running operation also depends on process supervision, power, machine sleep settings, network stability, and the ability to recover after a fault. YouTube’s documentation on loop syntax and ingest settings does not promise uninterrupted service for a particular command. Build and test a recovery plan if you need the channel to remain available around the clock.
If keeping a local computer and network available is the part you cannot reliably manage, a hosted approach may be worth considering. Compare it against running and supervising FFmpeg yourself, and be clear about which part of the job it removes and which responsibilities remain yours, including preparing the file, checking rights, and monitoring the channel.
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 a YouTube stream run continuously?
It asks FFmpeg to repeat the input indefinitely. It does not guarantee that the encoder, computer, connection, or YouTube ingest will keep working without interruption. Test the whole path and plan how you will detect and recover from a stopped process.
Where do I put -stream_loop -1 and -re?
Put both before the -i for the input they should affect, for example ffmpeg -re -stream_loop -1 -i ocean.mp4. If you have multiple inputs, check that each option precedes the correct input rather than assuming it applies to every file.
Can I use the sample command unchanged?
No. It is an illustrative RTMPS-style example, not a universally tested command. Match the codec, bitrate, frame rate, keyframe interval, audio and URL to your source, FFmpeg build, upload capacity and YouTube’s current requirements.
What if the picture or sound jumps at the loop point?
The loop option repeats the source; it does not create a seamless transition. Edit or crossfade the file if needed, then test the end-to-start boundary with the audio you intend to broadcast.