For a prerecorded gaming VOD, use -stream_loop -1 before the input file to repeat it, and -re before the input when you want FFmpeg to read it at its native rate. These flags govern how FFmpeg reads the source; they do not, by themselves, reconnect a failed YouTube broadcast.
The word “reconnect” can refer to different parts of the path. FFmpeg documents a set of reconnect options for HTTP inputs, while publishing a stream to YouTube uses an outbound connection. Treat those as separate problems, then validate the encoder settings, source and connection you will actually use.
What looping and reconnect flags address
Looping and reconnecting solve different problems. Looping tells FFmpeg what to do when it reaches the end of a file. Reconnection tells a client what to do after a connection or response problem, and the meaning depends on the protocol and whether FFmpeg is reading or publishing.
For a local file, -stream_loop -1 asks FFmpeg to repeat the input indefinitely. It does not repair a broken network connection, improve a rough edit, or guarantee that the last frame and first frame join cleanly. If the video ends on a cut and begins with a different scene, viewers will see that cut each time around. Audio may click, pause or change level at the boundary if the file is not edited for repetition.
Reconnect controls are not universal switches. The documented reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error, reconnect_streamed, and retry timing or count options belong to FFmpeg’s HTTP protocol. They address recovery while reading HTTP content, subject to the selected options and the installed FFmpeg build. They should not be presented as generic output flags that restore a dropped YouTube RTMP or RTMPS publish.
This distinction matters for an overnight channel. A local VOD can loop perfectly while the publishing connection still fails. Conversely, a network retry for an HTTP-hosted source might restore that input but do nothing about an error on the separate connection carrying the programme to YouTube. If you are comparing approaches for a continuous prerecorded broadcast, the overview of YouTube Live Control Room alternatives for always-on prerecorded streams is useful context, but you still need to establish what happens at each failure point in your chosen setup.
Place -stream_loop before the input
FFmpeg’s -stream_loop is an input option: it applies to the input that follows it. For a local file, place it before that file’s -i argument:
ffmpeg -stream_loop -1 -i "gaming-vod.mp4" ...
The value -1 means repeat indefinitely; 0 means do not repeat. The placement is not decorative. FFmpeg processes options in relation to inputs and outputs, so options placed in the wrong position may not affect the file you intended. If your command has multiple inputs, be deliberate about which -i each input option precedes.
If you leave out -stream_loop -1, FFmpeg reads the file once and reaches the end. That may be correct for a one-off event, but it is not the same as an endless programme. If you use a finite loop count in your own configuration, decide what should happen when it runs out; do not assume that a finite number means “keep the broadcast alive”.
A loop is also not an edit. Check the ending and opening shots together, including game audio, voice commentary and any music. A loading screen or pause at the file boundary can be especially noticeable in a gaming stream. Looping a file does not itself prove that video timestamps, audio continuity or the viewer experience will be seamless. Make an actual test with the selected file and inspect the boundary rather than inferring quality from the command line.
For a single local video, this is usually the key loop setting. If instead your programme is made from multiple clips or scheduled segments, a playlist or scene workflow may be more suitable than repeating one file. For another example of a dedicated machine approach, see the guide to using OBS Studio Portable Mode for a dedicated loop-stream PC. The choice depends on how often you change content and how much manual operation you want to manage.
Use -re for native-rate file reading
For a prerecorded file being sent as a live-like source, -re tells FFmpeg to read at the file’s native rate. It is equivalent to -readrate 1. Place it with the input options, before the relevant -i:
ffmpeg -re -stream_loop -1 -i "gaming-vod.mp4" ...
Without rate limiting, a file can be read faster than real time, which is generally not the intended behaviour when feeding a live encoder from a prerecorded programme. The point of -re is to pace file reading; it is not an encoder-quality setting and does not set the frame rate of the source. If a file contains footage recorded at one frame rate, -re does not transform it into footage captured at another.
Do not apply -re casually to an actual live capture or network input. FFmpeg cautions that low read rates on actual live inputs may cause packet loss. A camera or other live source already arrives according to real-world timing; slowing its read rate is not a substitute for managing that source correctly. Identify the input type before adding the flag.
A simple way to reason about the two flags is that -stream_loop -1 decides whether a file starts again at its end, while -re decides how quickly FFmpeg reads it. Neither controls whether an outbound YouTube connection can recover after failure. If you are diagnosing an audiovisual problem rather than configuring a loop, the checks in how to fix audio drifting out of sync in a 24/7 forest stream can help you separate source timing symptoms from other issues.
Review the illustrative command
The following command brings the ideas together, but it is an illustrative starting point, not a tested command or a guaranteed preset. Adjust it for your source, installed FFmpeg build, current YouTube Live settings and available upload bandwidth.
ffmpeg -re -stream_loop -1 -i "gaming-vod.mp4" \
-c:v libx264 -preset veryfast -b:v 6000k -maxrate 6000k -bufsize 12000k \
-pix_fmt yuv420p -g 120 \
-c:a aac -b:a 128k \
-f flv "$YOUTUBE_INGEST_URL/$STREAM_KEY"
The opening options pace and repeat the local file. -i identifies that input. The options after it select video and audio encoding, pixel format, keyframe interval and output format. The final address combines an ingest URL and a stream key represented by placeholders. Do not paste a real key into a public example, shared document or command history that other people can access.
The example’s values are not a recommendation for every gaming VOD. A 1080p high-motion capture, a lower-resolution replay and a file with variable frame rate or unusual audio may call for different choices. Some options can also interact: the bitrate and rate-control settings need to fit the picture and the upload connection, and the keyframe interval needs to agree with current platform guidance and the chosen frame rate. Treat each value as something to verify, not something made correct by appearing in a familiar command.
The command uses -f flv and an output address placeholder to illustrate a common shape, but confirm the ingest URL and protocol supplied by the current YouTube Live setup. YouTube Help recommends RTMPS, described as a secure extension to RTMP, in its encoder settings, bitrates and resolutions guidance. Use the current instructions in Live Control Room rather than assuming an old saved URL or key remains appropriate.
Do not add HTTP reconnect flags to this local-file command as a talisman. There is no HTTP VOD input here for those options to recover. If your source is a remote HTTP(S) file instead, consult the installed build with ffmpeg -h protocol=http, place relevant protocol options before that input’s -i, and confirm behaviour for that source. If the YouTube publishing leg fails, investigate that output path separately; the HTTP input documentation does not establish a universal RTMP or RTMPS output retry recipe.
Match encoding settings to source and YouTube
Start with the file’s properties and the intended viewing experience. Check its resolution, frame rate, video codec, audio layout and whether it has a stable frame rate. A command cannot make a source more detailed than it is, and forcing a mismatched output can add scaling or frame conversion without improving the picture. For fast gameplay, motion detail and readable interface text may matter more than they do for a static slide, so inspect the result rather than selecting settings by habit.
Then check YouTube’s current encoder guidance and the settings shown for the live stream you are configuring. YouTube’s guidance covers supported protocol, codecs, frame rate, keyframes, bitrate mode and audio. Requirements and recommendations can change, so use the official page and current Live Control Room values when you set up the event. Its live encoder setup instructions also explain entering the live server URL and stream key in the encoder settings.
The sample specifies H.264 video through libx264, AAC audio, yuv420p pixel format and a keyframe interval. Those are decisions to check against platform guidance and the source, not a guarantee of acceptance or picture quality. Likewise, a named preset is an encoder speed-versus-compression choice; it does not mean that a command is safe to run unattended on every computer or for every resolution. Verify that your hardware can encode the selected output continuously if encoding locally.
For a gaming VOD, test representative motion and sound, not just a title screen. Include a busy scene, a quiet scene, commentary if present and the file’s loop boundary. YouTube advises testing with representative audio and motion and monitoring stream health during the event. A brief test helps expose a black picture, muted audio, dropped frames or a boundary problem before you plan around the stream. A test does not prove that every future network or source condition will behave the same way.
Check upload bandwidth and ingest details
The outbound video and audio must fit the upload connection available to the encoder. Compare the configured output with the connection under the conditions in which you will stream, not only with an ideal result from a speed test. Other devices, cloud backups and household use can compete for upload capacity. A setting that appears fine on a quiet afternoon may behave differently when the connection is busy overnight.
Do not choose a bitrate solely because it appears in the illustrative command. Use YouTube’s current guidance for the output resolution and frame rate, then leave practical headroom for the connection’s normal variation. If the connection cannot sustain the planned output, reduce the output demand or improve the connection before relying on a long-running broadcast. Monitor the stream’s health while testing so you can distinguish upload instability from an encoding overload or a source issue.
Confirm the ingest URL and key in the active YouTube Live setup. YouTube’s setup instructions say to enter the live server URL and stream key in the encoder settings; use the values provided for the event rather than copying credentials from an old tutorial. Where Live Control Room offers choices or displays health information, check the current interface and follow its guidance. Do not assume that a stored ingest address, protocol choice or stream configuration remains current indefinitely.
A file can be served from a computer that is otherwise idle, but the computer still has to read the file, encode it if encoding is being done locally, and send the outgoing stream. If the machine sleeps, reboots for updates or loses network access, looping the input will not keep the broadcast going. For an always-on workflow, decide who or what notices a failed process, how it is restarted, and how you learn that the picture or sound has stopped. Do not confuse an FFmpeg input option with process supervision or a proven output recovery plan.
Keep reconnect recovery and key security separate
The HTTP reconnect family is useful only in the context it documents: HTTP input behaviour. For an HTTP(S) VOD, options such as retrying a network error or selected HTTP response codes may be relevant, but check the exact option support and syntax in the FFmpeg build you are running. The source may not be seekable, may respond differently at EOF, or may have service-specific behaviour. Test the input under realistic conditions rather than assuming that a retry setting guarantees continuous playback.
For a local file, HTTP reconnect settings are irrelevant. For a dropped YouTube publish, distinguish an FFmpeg process restart or external supervision from any in-process reconnect behaviour of the output protocol. The reviewed official material does not establish a general command that automatically restores every RTMP or RTMPS publishing failure. If unattended recovery is essential, verify your actual output path and recovery behaviour with a controlled test, and make sure you can tell whether a restart was successful.
Keep the stream key private. Treat it as a credential that can let someone publish to your channel’s live setup. Use a placeholder in examples, avoid posting it in screenshots or shared logs, and check the permissions of any file or script where it is stored. If you think it has been exposed, use YouTube’s current account and Live Control Room controls to replace or revoke it, then update the encoder configuration. YouTube’s official setup guidance is the right place to confirm the current way to retrieve and manage live stream credentials.
If maintaining the machine, FFmpeg process, network and recovery checks through every overnight interruption is the part that tends to fail, StreamNeo can remove that specific computer-running-and-restarting burden by turning an uploaded file into a YouTube live stream that continues with your computer switched off. It remains YouTube-only, and you still need to check your source rights, live setup and stream health.
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?
For a local file, put -stream_loop -1 before its -i input. Add -re before the input if you need FFmpeg to read the prerecorded file at its native rate. Confirm the output settings against the current YouTube Live setup and test the file, including its ending-to-opening transition.
Which FFmpeg reconnect flags should I use?
First identify which connection you want to recover. FFmpeg’s documented reconnect family described here is for HTTP inputs; those options do not automatically restore an outbound YouTube RTMP or RTMPS publishing connection. Check the protocol documentation for your installed build and test the relevant input or output path before relying on recovery.
Does -stream_loop -1 make the video loop seamlessly?
No. It repeats the input indefinitely, but it does not edit the end and beginning into a smooth transition. Check picture, audio and timestamps at the boundary in a real test.
Can I use -re with a live capture?
Do not add it without a reason. -re is useful for pacing a prerecorded file at its native rate, while FFmpeg cautions that low read rates on actual live inputs may cause packet loss. Identify the input type and follow the guidance for that source.