To repeat a gaming VOD as a YouTube Live feed, use FFmpeg’s -stream_loop -1 input option before -i, then send the encoded output to the stream URL and key from Live Control Room. That makes FFmpeg read the file repeatedly; it does not guarantee that the join will be imperceptible to viewers.
The command below is a starting point, not a universal quality preset. The file’s audio and video, chosen resolution and frame rate, available upload bandwidth, and the actual repeat boundary all need checking before you rely on it for a long-running channel.
What the command does
This command reads one local video at a live-style rate, loops it indefinitely, encodes video and audio, and sends the result to YouTube over RTMPS:
ffmpeg -re -stream_loop -1 -i "gaming-vod.mp4" \
-c:v libx264 -b:v 10M -maxrate 10M -bufsize 20M -g 60 \
-c:a aac -b:a 160k \
-f flv "rtmps://SERVER/live2/STREAM_KEY"
Replace gaming-vod.mp4 with the path to your file. Replace the destination with the server URL and stream key shown for your stream in YouTube Live Control Room. The example assumes the input has both video and audio streams; it lets FFmpeg select them automatically. It is not a claim that every gaming VOD has that layout.
The key detail for an indefinite repeat is -stream_loop -1. In FFmpeg’s documentation, -1 means that the input is looped indefinitely. -re paces a file input at its native rate, so the file is fed like a live source rather than read as quickly as the computer can process it. Without careful pacing, the feed may not behave as you expect from a live encoder.
The loop option applies to an input, which is why its placement matters. If the command errors, confirm the option appears before the relevant -i. This recipe addresses one repeated VOD, not a playlist, scheduled programme, or switching between multiple scenes. If your objective is a rerun made from multiple clips, the practical concerns are different; see how to prevent gaps between videos in a gaming rerun.
Prepare the VOD and YouTube Live destination
First check that the file is complete and that its picture and sound are the versions you intend to broadcast. Confirm its video and audio streams and their durations. A file that plays normally from beginning to end can still have a noticeable boundary when it starts again: the final frames, first frames, audio tail, and timestamps all affect what a viewer hears and sees at the join.
Open YouTube Studio and create or select a stream in Live Control Room. YouTube’s stream setup guidance explains how to obtain the stream URL and key used by an encoder. A channel must be eligible for live streaming; YouTube says a verified channel must not have live-streaming restrictions in the previous 90 days, and first-time live-streaming enablement can take up to 24 hours. Check the current official page for your channel rather than assuming it is ready at a particular moment.
Copy the destination carefully. The URL and key are specific to the stream or key you select, so don’t use a value copied from an example or someone else’s setup. Put them together in the output position shown in the command, following the format YouTube presents. Do not add spaces or line breaks inside the destination.
For a first run, use an unlisted or private test where appropriate, and inspect the Live Control Room preview before you promote an event. YouTube’s encoder settings page recommends testing with representative motion and audio and monitoring stream health. A static menu screen is not a useful test of a fast game scene, and a quiet test does not reveal the loudness of game effects or commentary.
If your goal is to keep a whole channel available around the clock, distinguish the repeated file from the process that runs it. A local workstation still needs power, an active network connection, and an FFmpeg process that remains running. Our guide to running FFmpeg on a Debian VPS discusses the separate operational work involved in keeping a local encoder process alive. A hosted workflow can remove the need to keep your own computer switched on; StreamNeo is relevant when the particular burden is leaving that computer and its FFmpeg process running, rather than diagnosing a bad loop boundary in the source file.
Put the loop option before the input
The option order is not cosmetic. FFmpeg options apply according to their scope, and -stream_loop is an input option. In the example, -re -stream_loop -1 appear before -i "gaming-vod.mp4", so they govern that input. Options such as -c:v, -b:v, and -c:a follow the input because they describe output encoding.
A common mistake is to put -stream_loop -1 after the input or after the output destination. That can leave the input unlooped or make the command fail to interpret the option as intended. Keep the input portion together, then the output options, then the output destination. If you add a second input later, reassess which input each option should apply to; do not assume the same line order will mean the same thing for every multi-input command.
The -i value can be a relative filename if you launch FFmpeg from the directory containing the file, or a full path. Paths containing spaces should stay quoted, as in the example. On Windows, use the path syntax your shell accepts and preserve the quotes. The destination is also quoted to keep the shell from splitting or interpreting its special characters.
For diagnosis, reduce the command to the essentials and add options back once the input loops and the destination is accepted. If FFmpeg reports that it cannot open the file, check the path and permissions before changing encoding settings. If it reports an invalid option or unexpected output, inspect the position of the input option and the quoting around both paths.
Read the encoder and output options
The example uses H.264 video via libx264, AAC audio, and FLV output, a conventional combination for sending a live feed to YouTube. YouTube currently lists RTMP/RTMPS ingest; H.264, H.265, or AV1 video; AAC or MP3 audio; constant bitrate encoding; up to 60 frames per second; and a recommended two-second keyframe interval that should not exceed four seconds. Check YouTube’s current encoder guidance before changing codecs or delivery settings.
The illustrative video bitrate is 10 Mbps, with a maximum of 10 Mbps and a 20 Mbps buffer setting. These are not mandatory settings for every stream. YouTube’s H.264 guidance lists 10 Mbps as a recommended example for 1080p30 and 12 Mbps for 1080p60; recommendations depend on resolution and frame rate. The right choice also depends on what the VOD contains and what your connection can sustain. A larger bitrate cannot compensate for unstable upload capacity.
-g 60 sets a group of pictures interval of 60 frames. That corresponds to a two-second interval only at 30 fps. At another frame rate, choose a value that matches the intended interval and YouTube’s current recommendation. Do not copy the number without checking the output frame rate. If you want to match the source, first establish its frame rate and set an output plan deliberately rather than guessing from the filename.
-c:a aac -b:a 160k asks FFmpeg to encode audio as AAC at the example bitrate. That is also illustrative, not a universal requirement. Check the source audio for clipping, silence, commentary levels, and a tail that may extend beyond the last video frame. If a VOD lacks audio, this automatic mapping example may not produce the layout you expect; if it contains multiple audio tracks, FFmpeg’s automatic selection may choose a track you did not intend. In either case, identify the streams and explicitly map the desired ones.
YouTube recommends leaving upload capacity headroom: its guidance calls for 20% headroom for total stream bitrate. Treat that as operational guidance, not a promise that any connection will be stable. Include audio and any other traffic using the same connection in your practical estimate. Test with the stream settings you plan to use, and reduce the output bitrate or resolution if the connection cannot maintain them. For a separate explanation of the resolution side of this decision, see why YouTube may reject a stream resolution.
Protect the stream key
A stream key functions like a password for the encoder. YouTube describes it as information used by the encoder to send the stream, and the destination in this command includes it. Do not paste a real key into a public article, support forum, shared screenshot, or a script repository. The placeholder in the code is deliberately not a working destination.
A command-line argument can be visible to other users or tools on a shared machine, and shell history may retain commands you enter. Consider who can access the account and computer before choosing how to store or enter the key. Avoid printing the full destination in logs or terminal screenshots. If a key is accidentally disclosed, use YouTube Studio’s key controls to manage or replace it, then update the encoder configuration.
When testing, use a key and stream destination you control. Do not assume a test key or a production key will be safe to share because the broadcast is unlisted. Visibility settings affect who can watch; they do not turn a credential into public information that is safe to publish.
Test the repeat boundary and output
Run the command long enough to cross the end of the file and return to its beginning more than once. Watch the join and listen through it, rather than checking only the first few minutes. Look for a pause, frozen frame, abrupt audio cut, repeated frame, click, or mismatch between the end of the sound and the start of the next pass. A boundary that is acceptable for a fast-paced game menu may be distracting over a quiet scene or spoken commentary.
There is no command-line switch here that can promise a seamless perceptual repeat for every source. If the picture pauses, inspect the final and initial frames and source timestamps. If the audio clicks or breaks, listen for a hard waveform cut or a tail that stops at a different time from the picture. Audio and video streams with different durations, packet timestamps, or codec boundaries can contribute to a discontinuity. FFmpeg’s concat demuxer documentation specifically notes that timestamp adjustment can cause gaps when streams do not have exactly the same length, and that concatenated files need matching streams, codecs, and time bases. That is a reason to inspect and test; it does not establish that every single-file loop will fail.
If the streams have different durations, make a corrected source with a deliberate common end point or explicitly map and trim the streams to match. Do not start by adding unrelated hardware: first establish whether the problem is in the file, timestamps, encoding, or the live connection. Test the corrected file locally across its boundary, then test the actual encoder output in Live Control Room and check stream health.
Test representative movement and the loudest expected audio, then confirm the preview is stable. Monitor stream health after starting, especially if you are testing the machine, network, and settings you expect to use for the real event. An unlisted test helps you check ingest and the viewer-facing join without announcing a public event prematurely. Stop the encoder and end the stream in Live Control Room when you finish. YouTube says streams under 12 hours are automatically archived; that archival note is not a guarantee that a stream will run continuously forever.
Troubleshoot common command issues
The file plays once and stops. Check that -stream_loop -1 is before -i and that you have not accidentally placed the input option after the output. Confirm that the command you launched is the one still running and that FFmpeg has not exited with an error. The -1 value means indefinite repetition, not one additional repeat.
FFmpeg cannot find the file. Check the current working directory or use a full path, and quote paths with spaces. Confirm the file is readable by the account running FFmpeg. This is a local file-path issue, not a YouTube ingest setting.
Live Control Room receives no signal. Recheck the stream URL and key from the selected stream, the RTMPS destination format, and whether the encoder process is still running. Make sure the channel is enabled for live streaming and review YouTube’s current setup guidance for account-specific restrictions. Never diagnose by posting the key publicly.
The picture or sound is wrong. Inspect the input streams, output codec, frame rate, and automatic stream selection. If the VOD includes multiple tracks or no audio, explicitly map the intended streams. If only the join is wrong, focus on the source boundary and matching stream durations rather than raising the bitrate.
The stream health warning appears. Compare your total output bitrate with sustainable upload capacity, leaving the headroom YouTube recommends. Reduce bitrate or output resolution if the connection is struggling, then test again with representative movement. High motion can reveal problems a static screen did not show. The settings in the sample are a starting example, not a setting YouTube requires of your channel.
The feed stops when the computer sleeps or loses connection. FFmpeg needs an active process and network path for a local setup. Prevent sleep during a planned broadcast, check power and connectivity, and decide how you will notice and recover from a stopped process. If you want to compare output quality options for a different resolution, the 4K FFmpeg settings guide covers a separate case; do not assume its settings fit this source or connection.
Choose an operating approach
For a short test, running FFmpeg on your own computer gives you direct control and avoids moving the VOD elsewhere. You also take responsibility for keeping that computer awake, maintaining its network connection, protecting the key, and noticing if the process stops. For a channel expected to run through the night, those duties matter as much as the command itself.
A hosted process can make sense if leaving a personal computer on is the specific operational problem. The trade-off is that you must still choose a trustworthy way to handle the stream key, verify the file and output, and monitor what viewers receive. Compare approaches on their actual responsibilities rather than assuming a remote process fixes source-file problems or guarantees an uninterrupted broadcast.
| Approach | What you manage | Main trade-off |
|---|---|---|
| FFmpeg on your computer | Power, sleep settings, connection, process and key access | Direct control, but your machine must remain available |
| FFmpeg on a machine you administer remotely | The remote operating environment, connection, process, updates and key access | Avoids relying on your desk computer, but leaves you responsible for ongoing administration |
| A hosted file-to-live workflow | Source file, destination details, stream checks and account access | Removes the need to keep your own computer running, but does not correct a flawed loop boundary or remove the need to monitor the output |
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 the join gapless?
No. It repeats the input indefinitely, but the file’s ending, beginning, timestamps, audio/video duration, and encoding structure affect the repeat boundary. Test the actual VOD and inspect the boundary; do not infer seamlessness from the loop option alone.
Why must -stream_loop -1 go before -i?
It is an input option, so put it before the input it should control. In the example, it applies to gaming-vod.mp4; options after the input describe the output encoding and destination.
Can I use the example bitrate for any gaming stream?
No. The sample is illustrative, and YouTube’s recommendations vary with resolution, frame rate, and codec. Choose settings your upload connection can sustain, preserve headroom, and test with representative game motion and audio.
Does YouTube archive a loop forever?
YouTube says streams under 12 hours are automatically archived, but that describes archival behaviour, not an unlimited continuous-stream guarantee. Check YouTube’s current guidance and plan how you will monitor and manage a long-running broadcast.