For a prerecorded gameplay file with an audio track, a useful FFmpeg starting point is to loop the input with -stream_loop -1, pace it with -re, and send an H.264/AAC stream to YouTube over RTMPS. The command below is configured for 720p60, but those output values are an example, not a universal best setting; match them to your file, upload connection and YouTube’s current encoder guidance.
This workflow broadcasts a file repeatedly. It does not capture live gameplay from a console or computer, and it does not ensure that the video returns to its first frame without a visible or audible seam. Check the file and test the full broadcast path before relying on it overnight.
When a file-loop command is the right tool
Use FFmpeg’s file-loop approach when you already have a prepared gameplay video and want its contents to repeat as a YouTube Live broadcast. It is useful for a showcase, a replay, or a fixed gameplay sequence that should run while you are not actively playing. The command reads a local file; it is not a capture setup for a game that is being played live.
The key option is -stream_loop -1, placed before the input it applies to. The negative value tells FFmpeg to repeat that input indefinitely. -re, also placed before the input, reads it at its native rate so a file is paced like a real-time stream rather than sent as quickly as the computer can process it. These are separate jobs: one repeats the file, while the other controls the read pace. FFmpeg documents both options in its command-line documentation.
A loop does not make a file seamless. If the last frame or sound does not lead naturally into the first, viewers may see a jump or hear an interruption on every return to the start. Review the file’s beginning and end, including its soundtrack, before broadcasting. If you have several clips rather than one continuous recording, a playlist or concat workflow may suit the material better; see the considerations in choosing a live playlist or a long upload and looping a playlist with FFmpeg concat.
If you need to show what is happening in a game right now, this is the wrong input model. Capturing a live game requires a device or desktop capture input and a different pipeline. Likewise, a video without audio, a file with several unusual audio tracks, or a file whose picture is in HDR needs a deliberate adjustment rather than blind use of the example below.
Baseline command and the values to replace
The following baseline assumes an input file with an audio stream and an FFmpeg build that includes libx264. It re-encodes both picture and sound, and the video output is set to 60 frames per second at 720p. Replace the filename and the YouTube destination placeholders; then review the frame rate, bitrate and audio options against your own source.
ffmpeg \
-stream_loop -1 -re -i "gameplay.mp4" \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-r 60 -g 120 -keyint_min 120 -sc_threshold 0 \
-b:v 8M -maxrate 8M -bufsize 16M \
-c:a aac -b:a 128k -ar 44100 \
-f flv "<RTMPS ingest URL>/<stream key>"
Change gameplay.mp4 to the path and filename of your prepared file. Keep quotes around a path containing spaces, and check that the account running FFmpeg can read it. The last line is a placeholder, not a literal address to copy: use the ingest address and stream key supplied for your broadcast in YouTube Live Control Room. Treat the key as a password. Do not paste a real key into a public article, screenshot, chat or command shared with somebody else.
The order matters. Input options such as -stream_loop and -re appear before -i; the encoder, frame-rate, bitrate and audio options after it describe the output. -c:v libx264 chooses the H.264 video encoder, while -f flv selects the muxer commonly used with the RTMP-style ingest pattern. Use YouTube’s RTMPS endpoint when it is offered. YouTube lists RTMP/RTMPS ingest and recommends RTMPS in its live encoder settings.
This exact line is not for every file or every FFmpeg installation. Check that your build recognises libx264; if it does not, choose an encoder that your build supports and confirm that its output meets YouTube’s current requirements. The command also presumes an audio stream that FFmpeg can map and encode. If your source has no sound or has multiple tracks, specify or omit audio deliberately instead of assuming -c:a aac can work unchanged.
Re-encoding makes the output parameters explicit, but it uses processing resources. If your file is already encoded in formats and settings compatible with the current ingest requirements, stream copy may reduce processing, for example with -c:v copy -c:a copy. That also means you cannot change the copied codec settings, and a compatible-looking file is not proof that its streams meet every ingest requirement. Check the file’s stream details and YouTube’s current guidance first.
Match the output frame rate and keyframes to the source
The baseline’s -r 60 requests an output rate of 60 frames per second. Do not treat that number as a quality upgrade for a source recorded at a lower rate: creating additional output frames cannot recover motion that is not present in the file. For a 30 fps source, for example, set the output rate to 30 if that is the rate you intend to send. YouTube’s encoder guidance allows up to 60 fps; select a rate that makes sense for the source and the stream you plan to deliver.
The GOP options set the spacing of keyframes. In this command, -g 120 and -keyint_min 120 correspond to 120 frames, which is two seconds at 60 fps. For 30 fps output, a two-second interval is 60 frames, so the corresponding values would be -g 60 -keyint_min 60. The calculation is output frames per second multiplied by two; it is not a fixed frame count across all frame rates. YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Verify the current guidance before changing these options.
-sc_threshold 0 disables scene-cut-driven keyframe insertion in this example, keeping the intended interval consistent. Whether you need that precise behaviour depends on your encoder and workflow. The practical point is to check the configured keyframe interval in relation to the actual output rate, rather than copying a pair of frame counts from a different recipe.
Resolution is also a source decision. The command does not explicitly scale the input to 1280 by 720, so do not assume it converts every file to 720p merely because its bitrate is an example for 720p60. If the input resolution differs from the intended output, decide whether to scale it and test the result. Avoid increasing resolution just to match a label if the extra processing or enlarged image does not help your viewers.
Choose bitrate for the output you can sustain
In the baseline, -b:v 8M sets the target video bitrate and -maxrate 8M sets the maximum to the same value. YouTube’s published H.264 recommendations list 8 Mbps for 720p60, 10 Mbps for 1080p30 and 17 Mbps for 1080p60. Those are platform recommendations for particular resolution and frame-rate combinations, not guarantees of picture quality or proof that your internet connection can sustain the stream. Check the relevant entry on YouTube’s current encoder settings page before going live; the guidance may change.
| Intended H.264 output | YouTube-listed video bitrate recommendation | What to check |
|---|---|---|
| 720p60 | 8 Mbps | Source motion and whether your upload can sustain the output |
| 1080p30 | 10 Mbps | Whether the source benefits from the higher resolution at this frame rate |
| 1080p60 | 17 Mbps | Both the available upload capacity and the added processing demand |
The table is a quick comparison of the cited YouTube recommendations, not a promise that these are the right choices for every file. In particular, the 720p60 example is not a universal or guaranteed best setting. A steady 720p30 source may be better kept at its natural frame rate, while an unstable connection may not reliably carry the nominal bitrate for a higher-resolution output.
-bufsize 16M sets the rate-control buffer size in this example. The two equal bitrate options are intended to approximate a constant-rate output, consistent with YouTube’s CBR guidance, but exact rate-control behaviour depends on the encoder and FFmpeg build. Do not infer from the command alone that every build will produce an identical bitrate pattern. Check the encoder’s supported options and observe the resulting stream.
Think about upload capacity as a condition to verify, not a number to guess. The connection must carry the video and audio output with room for ordinary variation and other network use. If your connection is shared, busy, or inconsistent, test at the planned settings and watch YouTube’s health messages. If the stream reports connection problems, reduce the output demands or address the connection before treating a higher bitrate as a fix. For a separate explanation of bitrate stability, see how to choose a stable bitrate when a YouTube stream drops frames.
Confirm the audio stream and encoding
The audio options in the baseline are -c:a aac -b:a 128k -ar 44100: AAC encoding, a 128 Kbps audio bitrate and a 44.1 kHz sample rate. YouTube’s guidance lists AAC or MP3 and recommends 44.1 kHz and 128 Kbps for stereo audio. The example is therefore a reasonable starting point for a file with a conventional stereo track, but inspect your source rather than assuming its layout.
If there is no audio stream, FFmpeg cannot encode one from the input simply because -c:a aac appears in the command. Remove or adjust the audio output options as appropriate, and confirm that the rest of the command maps the streams you intend to send. If the file has commentary on one track and game audio on another, decide which track should be heard and how the tracks should be mixed before the broadcast. Do not let a successful video encode stand in for an audio check.
Listen to a test from the beginning through the loop point. Check for silence, clipping, imbalance between gameplay and commentary, and a sound jump when playback returns to the first frame. A file may play correctly on your computer while still having an awkward transition when repeated. YouTube advises testing with audio and movement similar to the planned stream; a short local preview can help find obvious file issues, but it does not replace a test of the full live path.
If you plan to stream music, commentary or other material alongside gameplay, this command only describes technical encoding. It does not decide whether you have permission to broadcast the material. Check the rights and current platform rules for the content you plan to use.
Get the RTMPS address and stream key from YouTube
Create or open the planned broadcast in YouTube Live Control Room and use the ingest server and stream key shown there. The destination placeholder in the command combines the RTMPS ingest URL with the key in the form expected by the chosen ingest pattern. YouTube’s interface and available settings are the source of truth for your channel; do not copy an endpoint from someone else’s command and assume it applies to your broadcast.
Keep the key private. Anyone who can use it may be able to send a broadcast to your channel, so do not include it in a public tutorial, terminal screenshot, shared script or support message. Use a placeholder when documenting the command, and use the actual value only in the private environment where you run it. If a key has been exposed, review YouTube’s current controls for replacing or resetting it.
Start with a private or unlisted test broadcast where that fits your channel’s workflow. Confirm the destination is the intended broadcast before sending output, particularly if you manage more than one channel or have several scheduled events. YouTube’s settings can vary with account and broadcast configuration, so read the live interface rather than treating a saved command as permanently correct.
A file loop can be left running only while the process and connection remain available. If your computer sleeps, loses its connection, or FFmpeg exits, the outgoing stream can stop. For a single test, that may be a manageable operational detail; for a channel meant to continue when your computer is off, the machine and process would otherwise need to remain available. StreamNeo addresses that specific burden by letting you upload a video and run a YouTube broadcast without keeping your own computer on; it does not change the need to prepare and test the content.
Test the output and inspect stream health
YouTube’s practical instruction is direct: “Make sure to test before you start your live stream.” Run the command in a test setting first, using movement and audio similar to what viewers will receive. Watch the preview, listen to the sound, and confirm that the intended file is playing at the intended resolution and frame rate. In particular, let playback reach its loop point if you need to know whether the transition is acceptable.
During the test, read the messages in Live Control Room and monitor stream health. An encoder or connection warning is a reason to investigate, not something to dismiss because the command resembles a published example. Check that FFmpeg is still running, the file remains readable, the stream key is current, and the upload connection can carry the output. If you change output settings, test them again; changing a single value can affect processing load or ingest behaviour.
Do not use a locally successful FFmpeg exit or an open YouTube preview as the only check. Confirm picture, sound and the broadcast state from the platform side. When the stream is intended to stay on for a long period, consider what happens if the computer restarts, the network drops, or the process stops. A manual FFmpeg command is a process you operate; it does not by itself restart after every failure.
For long-running programming made from multiple pieces of content, think about how you will update it as well as how it starts. A repeated single file is simple, but it is not the same as a schedule that changes by time of day or a stream where clips are added while it runs. If the latter is your aim, the practical choices in adding new bhajans without restarting a live stream illustrate why a single-file loop is not always the right workflow.
What to decide before you copy the command
Before starting, write down the output you actually intend to send: the source’s frame rate and dimensions, whether it has the audio track you want, and the upload conditions available where the stream will run. Then choose a frame rate and resolution that the file can support, derive the GOP from the desired keyframe interval, and select the bitrate recommendation that corresponds to that output. These decisions make the command specific to your file rather than a recipe borrowed from an unrelated setup.
The main trade-off is control versus operating responsibility. Re-encoding lets you set video and audio output deliberately, but requires a compatible encoder and enough local processing capacity. Stream copy can reduce encoding work for a suitable file, but locks you to its existing stream properties. A cloud-based file workflow avoids leaving your own computer on, while a local FFmpeg workflow gives you direct command-line control. Choose based on how you want to operate and what the file and connection support.
Keep a known-good command with placeholders, not with a real stream key. Record the file name, intended output settings, and any adjustments you made for audio or frame rate. That makes it easier to repeat the test without accidentally carrying a private key into a shared document, and it gives you a clear starting point when YouTube changes its guidance or the source file changes.
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
What’s the best FFmpeg command to loop a video on YouTube Live?
There is no single best command for every source. The baseline above is a starting point for a file with audio and an FFmpeg build that supports libx264; adjust the frame rate, GOP, bitrate and audio settings to the file and current YouTube guidance. Test it in YouTube Live Control Room before using it for a real broadcast.
How do I stream a prerecorded gameplay video on repeat?
Put -stream_loop -1 before the input file and -re before -i to loop and pace that file for live output. Supply the ingest details from YouTube Live Control Room and verify that your file has the streams the command expects. This repeats prerecorded material; it does not capture live gameplay.
Can I use this command for a file without audio?
Not unchanged. The baseline’s audio encoder options assume an audio stream to encode, so remove or adapt them and check stream mapping when the file has no sound or has multiple tracks. Test the resulting broadcast’s picture and sound rather than assuming the video options settle audio behaviour.
Does this command guarantee a seamless loop or uninterrupted stream?
No. A loop may have a visible or audible seam, and a local process or connection can stop. Inspect the start and end of the file, test the loop point, and monitor stream health during the broadcast.