For a local file, put -stream_loop -1 before that file’s -i to repeat it indefinitely. For file-based live output, put -re before the same input so FFmpeg reads it at its native frame rate; then match the output to the ingest mode selected for your YouTube Live event.
The command below is an illustrative shape, not a tested or universally valid recipe. It uses RTMP-style FLV output; YouTube HLS ingest is a separate, segment-based workflow, not a matter of changing the output filename.
What -stream_loop repeats
FFmpeg’s -stream_loop option controls how many times it repeats a selected input. A value of -1 means repeat indefinitely, while 0 means do not repeat. It applies to an input, rather than magically looping every source or playlist mentioned elsewhere in a command. See the FFmpeg input options for the option’s definition and scope.
That distinction matters because “playlist” can mean two quite different things. You might mean a finished programme made from several clips, or you might mean an HLS manifest file such as an .m3u8 that points to media segments. The loop option repeats the input you give FFmpeg; it does not, by itself, arrange clips into the programme you have in mind or establish that a changing live manifest can be replayed as a finite playlist.
If your source is a single local MP4, the input is straightforward: FFmpeg opens that file and, with the loop option, returns to it when it reaches the end. If your programme consists of several files, first ensure that the input representation actually contains the sequence you want. A playlist assembled from clips may have different stream properties at transitions, which can affect whether it can be joined or encoded consistently. Test the source’s behaviour before relying on an apparently seamless repeat.
A YouTube playlist is yet another thing: it is a sequence of videos presented by YouTube, not necessarily a local media input that FFmpeg can read and repeat as one file. The guide to streaming an exam-prep playlist on YouTube Live addresses the programming idea; here, the important point is to identify the actual file or manifest supplied to FFmpeg.
Put -stream_loop -1 before -i
Input options belong to the input that follows them. For a file called input.mp4, the relevant order is -stream_loop -1 -i input.mp4. If you put the option after that -i, it is no longer positioned as an option for that input, and you should not expect the same looping behaviour.
This becomes more important when a command has several inputs. Each input has its own options, so attach the loop setting to the file that should repeat, not to an unrelated audio track, camera or network source. Read the command from left to right: options before an -i describe that input; options after the inputs generally describe the output or its mapping and encoding.
For one local file, the core shape is:
ffmpeg -stream_loop -1 -i input.mp4 ...
The ellipsis is intentional: this is not a complete command. You still need to choose how to pace, encode or copy the media and which output format and destination suit the event. The FFmpeg command documentation is the primary reference when checking option scope and behaviour; pay particular attention to the options for the version you are using.
Do not assume that placing the flag correctly guarantees a clean transition at the end of every file. The source may have audio and video streams that end at different points, unusual timestamps or other properties that make its loop unsuitable for a particular output. A short local test can reveal whether playback returns to the beginning as expected, but it cannot prove that the same command will meet every YouTube event’s ingest requirements.
Use -re for file-based live output
A file can be read as quickly as the system processes it unless you ask FFmpeg to pace it. For file-based live output, -re reads the input at its native frame rate; FFmpeg documents it as equivalent to -readrate 1. That is why the common shape places it before the file’s -i, alongside the loop setting.
ffmpeg -re -stream_loop -1 -i input.mp4 ...
This gives the file a live-style reading pace instead of allowing FFmpeg to send it as fast as it can process it. Pacing is not encoding. It does not select a codec, set a bitrate, choose keyframes or make an output compatible with YouTube by itself. Those choices depend on the source and the ingest mode.
Use this advice for a file-style input, not blindly for every source. A real-time camera or network feed already arrives according to its own timing; adding file pacing without understanding that input can be inappropriate. The question is whether FFmpeg is reading a stored file that needs to be paced for live output, not whether the final destination happens to be YouTube.
If your file plays too quickly when sent live, first check whether you omitted -re or placed it after the input. If it plays at the expected pace but YouTube rejects or fails to process it, investigate output format, codecs and event ingest settings instead. Keeping those problems separate makes troubleshooting more useful than changing several unrelated flags at once.
For an always-on channel, also consider what happens when the source ends, the network drops or the computer is restarted. A loop flag addresses only repetition of the selected input. It does not monitor the broadcast or restore a stopped process. If keeping a local machine on overnight is the recurring burden, StreamNeo removes that specific need by turning an uploaded file into a YouTube live stream without requiring your computer to stay on. You still need to prepare the programme and select the correct YouTube ingest settings.
Understand the example command’s assumptions
Here is the full illustrative shape for a local file and an RTMP-style destination:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -c:a aac \
-f flv "YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
This example shows the option order and a broad output shape. It assumes that the file can be encoded as H.264 video and AAC audio and that the event is configured for a compatible RTMP-style FLV output. Those assumptions may not fit your file, your FFmpeg build or the ingest mode YouTube offers for your event. Treat the codec settings as an example, not as a universal recommendation.
The placeholder destination is not a real URL. YouTube provides an ingestion address for a live stream; the event’s current setup in Live Control Room is the place to confirm the selected protocol and destination. Do not publish your actual stream key in a public script, screenshot or log. Anyone who obtains it may be able to send a broadcast to the associated stream.
The example also does not specify bitrate, resolution, frame rate, keyframe interval or audio channel layout. No one command can responsibly fill those in for every source and event. Check the current YouTube settings for the event, then make FFmpeg’s output match them. If you copy streams instead of encoding them, confirm that the codecs and container are accepted for that ingest mode; stream copying avoids re-encoding, but it cannot repair incompatible media.
Finally, the command does not promise uninterrupted transmission. A local computer can sleep, lose power, lose its network connection or stop running FFmpeg. A successful local test shows that a particular source and configuration can run under those test conditions; it is not evidence of guaranteed approval or continuous operation.
Choose output options for the media and ingest mode
Start by inspecting what the source contains: video and audio streams, codecs, dimensions, frame rate, duration and whether the audio remains present throughout. Then decide whether those streams should be copied or encoded. Copying can avoid a generation of encoding, but it only works when the source already suits the output. Encoding gives you a way to change the media, at the cost of requiring suitable settings and processing capacity.
The output muxer and destination must also match the protocol selected for the event. In the example, -f flv is part of an RTMP-style output shape. It is not a generic instruction for any YouTube ingest. The -c:v and -c:a options likewise describe an encoding choice, not a guarantee that the event accepts it unchanged.
A practical check is to make a short test with the same source and output path, then inspect the result in YouTube’s Live Control Room before planning an overnight run. A test can uncover a missing audio stream, a rejected configuration or a mismatch between the selected ingest method and the FFmpeg output. It cannot tell you that the process will never fail later, so plan how you will notice and respond to a stopped stream.
If the content needs a continuous order of several clips, solve that at the programme-source stage. A single file that already contains the sequence is easier to reason about than assuming the input loop will construct a playlist from separate items. For a different approach to ordering files in a broadcast, see how a cloud streaming service can preserve video order. The source’s transitions still need checking; ordering alone does not make them seamless.
RTMP/FLV and HLS are different workflows
The example’s FLV output is for an RTMP-style continuous stream. YouTube HLS ingest instead uses media segments described by a media playlist and sent to YouTube over HTTPS. It is not enough to replace -f flv with a filename ending in .m3u8: the HLS workflow has requirements for the playlist, segments, transport and media formats.
YouTube’s HLS ingest help page specifies TS segments lasting 1–4 seconds, a rolling playlist with no more than five outstanding segments, HTTPS POST or PUT, and no encryption other than HTTPS. Its HLS developer guide describes media in M2TS, names H.264 and HEVC as supported video codecs, supports frame rates up to 60 fps, requires a closed GOP and lists AAC as the supported audio codec in that guide. YouTube ingests Media Playlists; Master Playlists are ignored.
The two official HLS references do not describe every audio detail identically. Check the current official requirements for the specific workflow rather than silently combining their lists or treating them as interchangeable. The wider point is that HLS has a defined segment-based delivery shape and format constraints that a simple continuous FLV output does not satisfy.
| Decision | RTMP-style file output | YouTube HLS ingest |
|---|---|---|
| Output shape | Continuous output, such as the illustrative FLV command | Media playlist plus separate segments sent over HTTPS |
| Playlist meaning | The FFmpeg input loop and output protocol are separate choices | A rolling media playlist describes the segment sequence |
| Operational focus | Match the continuous output and media to the event’s current settings | Meet the playlist, segment, format and transport requirements |
| Latency consideration | Follow the mode shown for the event | YouTube describes HLS as higher latency; ultra-low latency is unavailable with HLS |
| When it fits | A straightforward local-file loop for a compatible continuous ingest | A workflow that specifically requires HLS and can meet its additional constraints |
YouTube’s liveStreams documentation describes the ingestion address and backup address associated with a stream. Use the address and mode provided for your event rather than assuming the example’s destination structure applies to every setup. YouTube’s HLS documentation describes a different delivery mechanism, so do not send the RTMP/FLV command unchanged to an HLS endpoint.
An HLS .m3u8 source also should not be confused with YouTube’s HLS output requirements. The fact that FFmpeg can open a manifest does not establish that a changing live playlist is finite, repeatable or appropriate for a looped file programme. The reviewed documentation does not guarantee that an evolving live HLS input can be replayed as if it were a fixed sequence of clips. Verify the behaviour of the source itself and build an HLS output workflow only when that is genuinely the selected ingest mode.
Test and verify in Live Control Room
Before preparing an unattended run, confirm the event’s selected ingest mode and obtain the current ingest details from Live Control Room. Keep the stream key private. Then check that the FFmpeg output format, destination and media settings correspond to that mode. The API documentation can explain the roles of the ingestion and backup addresses, but your live event’s current configuration is the operational reference.
Run a controlled test using the actual source, not just a command copied from an example. Verify that the file is paced as intended, repeats at the end, and carries the expected picture and sound. In Live Control Room, check whether YouTube receives the stream and reports a usable signal. If it does not, change one relevant part at a time: input order and pacing, then media compatibility, then the output and ingest details.
Keep a record of the working command with secrets removed, along with the FFmpeg version, source-file details and event mode. That makes a later failure easier to diagnose without exposing credentials. Do not treat a successful test as a promise of approval for all future events or of uninterrupted operation. YouTube can change its current requirements, and each source or event may differ.
For an always-on broadcast from a local machine, plan for the failure modes the loop flag cannot address: power interruption, a computer entering sleep, network loss, a process exit or a source file changing. Monitoring can help you find out when a stream stops; the guide to alerts when an always-on YouTube stream stops covers that separate problem. An alert tells you something needs attention; it does not itself restart FFmpeg or guarantee recovery.
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 -i for the input you want to repeat. It is an input option, so its position determines which input it applies to. For a local file-based live output, place -re before that same input as well.
Does -stream_loop create a playlist from several files?
No. It repeats the selected input; it does not assemble a programme from separate clips. Use a source representation that actually contains your intended sequence, and check that its streams behave properly at transitions and when the sequence repeats.
Can I use the RTMP/FLV example for YouTube HLS ingest?
No, not unchanged. The example illustrates a continuous RTMP-style FLV output, while HLS uses a media playlist and separate segments sent over HTTPS, with its own format and playlist requirements. Confirm the event’s ingest mode and consult YouTube’s current HLS guidance before building that workflow.
Does a successful test mean the stream will keep running all night?
No. A test can show that a source and configuration work under the conditions tested, but a loop flag does not protect against power, network or process failures. Plan how you will monitor and respond to a stopped stream, and keep the current YouTube settings for the event.