To loop a prerecorded video to YouTube Live with FFmpeg, use -stream_loop -1 before the input and pace the file with -re. The command below is an adaptable template, not a tested, universal recipe: check your file, FFmpeg build, connection and current YouTube settings before relying on it.
A looping process can keep sending a file, but it does not supervise itself or guarantee an uninterrupted broadcast. You must monitor FFmpeg and YouTube’s stream health, and plan separately for what happens if the process or network fails.
Choose the right input and confirm its streams
Start with a local video file that you are entitled to broadcast and that contains the picture and sound you expect. Before setting encoder options, inspect the file with a probe tool such as ffprobe if it is available in your FFmpeg installation. Confirm the video codec, resolution, frame rate, pixel format and duration; check whether there is an audio stream, and note its channel layout and sample rate. The command’s example assumes a file with both video and audio. A silent file needs different audio handling rather than an assumption that an audio stream exists.
A simple first check is to play the file locally from beginning to end, including a section near the end. Look for a blank final frame, an unexpected fade to silence, a different aspect ratio, or a transition that would be distracting every time the loop returns to the start. Looping makes small defects repeat, so it is worth deciding whether the file itself is suitable before testing the broadcast.
Use a real file path in place of input.mp4. On a system with spaces in a path, quote it, for example -i "/home/you/Live files/programme.mp4". The same applies to the destination URL later in the command. Do not treat the example path or any sample destination as credentials you can use as written.
If the source already has acceptable codecs, stream copying may avoid the CPU cost and quality changes of re-encoding. It is not a universal shortcut: the source codecs, timestamps, pixel format and YouTube ingest requirements all matter, and the research for this pattern does not establish a guaranteed -c copy command for every file. If the file is variable-frame-rate, has an unusual audio layout, or produces timestamp warnings, test it rather than assuming it will pass through cleanly.
For a channel with changing tracks or a stream that needs titles from a radio source, a single video-file loop is a different workflow; see using Icecast metadata in a YouTube radio livestream. For a fixed devotional, ambience or study video, a single prepared file is simpler to reason about, but only if its audio and visual loop points are acceptable.
Understand the loop and realtime options
The two options that define the basic behaviour are -stream_loop -1 and -re. FFmpeg documents -stream_loop as an input option: -1 means loop indefinitely. Place it before the -i for the input it applies to. FFmpeg options generally apply to the next specified input or output, so changing their order can change what they affect. The FFmpeg command-line documentation explains this option scope and the read-rate behaviour.
-re reads the prerecorded file at its native frame rate, rather than consuming it as fast as the computer can process it. That pacing is useful when turning a file into a live-like feed. It does not make the source live, improve its quality or recover a failed connection. Do not add it blindly to an actual capture device or already-live input: FFmpeg’s manual warns that a low read rate on real capture/live inputs can cause packet loss.
Because both options relate to the input, the template keeps them before -i. If you have more than one input, make sure each input option is placed with the input it is meant to govern. If you put output options in the wrong place, you may get a different result than intended or an error that is difficult to diagnose by staring only at the final line of the command.
An infinite loop is also not a promise of seamlessness at the edit point. If the end and beginning differ in brightness, music level or scene, viewers will see or hear the jump each time. FFmpeg may also encounter files with awkward timestamps or container behaviour at the loop boundary. A short local test that crosses the end of the file is more useful than assuming that -stream_loop -1 makes every source repeat cleanly.
If you are building a small machine-based setup, the file must remain accessible for the full run and the computer must stay awake and connected. A guide to storage for a 24/7 FFmpeg YouTube stream on a Raspberry Pi is relevant if the input lives on removable media or a small local device. Storage choice does not solve process monitoring, power loss or internet interruptions.
Use an adaptable FFmpeg command template
For a local file containing video and audio, this is a practical H.264/AAC RTMP pattern to adapt:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast \
-b:v 5M -maxrate 5M -bufsize 10M \
-pix_fmt yuv420p -g 60 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmp://YOUR_SERVER/YOUR_STREAM_KEY"
Replace input.mp4 with the path to your file. Replace the quoted destination with the exact server URL and stream key shown in YouTube Live Control Room. Prefer the RTMPS URL when the installed FFmpeg build and destination configuration support it. The example’s rtmp:// text is only a placeholder, not a reason to ignore the RTMPS URL offered by YouTube.
Treat each line as a group of settings to check, not a magic incantation. The input options come first, then video encoding and audio encoding options, then the output format and destination. The final output options apply to the outgoing stream. The command is a researched template; it has not been verified against your file, operating system, FFmpeg build or current Live Control Room session. Confirm those conditions before broadcasting.
The sample bitrate is not suitable for every resolution or frame rate. The -g 60 value assumes 30 frames per second if the aim is a two-second keyframe interval. The audio options assume stereo audio. Check YouTube’s current encoder settings and recommended bitrates, then adapt the numbers to your actual output and available upload capacity.
You can save a multi-line command in a shell script, but line continuation syntax varies between shells. The backslash shown here is for a Unix-like shell; in Windows Command Prompt, PowerShell and other environments, line breaks and quoting rules differ. If the shell reports an error before FFmpeg starts, check how it parsed the command and try a one-line version using the quoting rules for your environment. Keep the destination key out of scripts that you share or commit to a public repository.
Set video and audio encoding options
-c:v libx264 asks FFmpeg to encode the video with H.264, while -c:a aac encodes audio as AAC. YouTube’s current settings page accepts H.264, H.265 and AV1 for RTMP/RTMPS ingestion, and AAC or MP3 audio. H.264/AAC is the example here, not the only permitted combination. The codec you choose must be supported by your FFmpeg build and make sense for your output and ingest route.
-preset veryfast is an illustrative, compatibility-oriented x264 choice. Faster presets generally reduce encoding work at a potential quality cost for a given bitrate; the exact CPU load and picture quality depend on the content and machine. If the computer cannot encode in realtime, changing the preset or using hardware encoding may be worth investigating, but hardware encoders have their own device, driver and quality considerations. Watch FFmpeg’s progress output during a representative test rather than assuming a preset will keep up.
The three video rate-control options work together in the example. -b:v 5M sets the target video bitrate, -maxrate 5M sets a ceiling, and -bufsize 10M sets the rate-control buffer size. These are example values, not a universal recommendation. YouTube Help lists different recommendations by codec, resolution and frame rate; for example, its current H.264 guidance recommends 5 Mbps for 1080p at 30 fps and 8 Mbps for 720p at 60 fps. Choose from the current table for your actual output and leave headroom on the internet connection for other traffic and bitrate variation. YouTube also says to run a speed test to check upload bitrate.
-pix_fmt yuv420p selects a broadly compatible pixel format for the example. It is a deliberate output choice, not a way to fix every source-format issue. Check the resulting stream and YouTube preview; scaling, frame-rate conversion or deinterlacing may be needed for some inputs, but those operations are not included in this basic template because the right values depend on the source.
-g sets the GOP length in frames. A value of 60 is a two-second interval at 30 fps; for a 60 fps stream, 120 frames gives the same interval. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds. That is why GOP length must follow the output frame rate rather than be copied blindly. See the practical discussion of keyframe intervals for 24/7 streams before changing frame rate or GOP values.
For audio, -b:a 128k is the example’s stereo bitrate, and -ar 44100 sets a 44.1 kHz sample rate. YouTube recommends 44.1 kHz for stereo and lists 48 kHz for 5.1 audio; its current recommended audio bitrate is 128 Kbps for stereo and 384 Kbps for 5.1. If your file has no audio, or its channels are not stereo, do not assume that the example’s audio settings describe the output you need. Confirm the source layout and intended output before adding audio mapping or filters.
The output bitrate is not the same as the internet plan’s headline download speed. The upload connection must carry the stream consistently, and other devices or uploads can consume capacity. A short test at the intended resolution, frame rate and representative sound and motion helps reveal whether encoding and upload can keep pace. If the actual output differs from the file’s properties, adjust settings deliberately and test again.
Add the YouTube RTMP destination securely
In Live Control Room, open the stream settings and copy the current server URL and stream key. YouTube recommends RTMPS, which carries RTMP over a TLS/SSL connection. Its RTMPS guidance explains where to reveal the RTMPS URL and advises checking that both the scheme and server are rtmps if an SSL error occurs; it also notes port 443 may be specified if needed. Use the URL displayed for your stream rather than constructing one from memory.
The stream key is a credential that lets an encoder publish to your channel. Keep it private: do not include it in a public post, screenshot, shared script or support message. A shell command may be stored in terminal history, so consider that exposure before pasting a live key into a shared or managed computer. If you believe the key has been exposed, use Live Control Room to change or reset it, then update your encoder.
The template’s -f flv is a common FFmpeg output pattern for RTMP. The YouTube pages cited here describe RTMP/RTMPS ingest but do not establish FLV as a universal requirement, so treat it as a practical part of this example rather than a YouTube mandate. If a particular FFmpeg build or destination rejects the output, check the build’s available formats and the current YouTube setup instructions.
Start the stream from the encoder and watch for the preview in Live Control Room. For a scheduled broadcast, YouTube’s encoder setup instructions say to click Go live in Live Control Room when ready. A successful FFmpeg connection is not by itself proof that viewers see the expected picture and sound; check the preview and stream health before leaving it unattended.
Test the output and inspect logs
Make a test with the actual file and intended output settings before treating the command as ready for an overnight run. Check that FFmpeg starts without an option or codec error, that its progress advances at the expected pace, and that the output does not fall behind realtime. Confirm the preview shows the right resolution and motion, and listen for audio level, channel balance, sync and the transition where the file loops.
Keep the terminal output or redirect it to a log you can review. Look for repeated connection errors, encoder warnings, timestamp problems, or messages that indicate the output has stopped. The exact wording depends on FFmpeg version and build, so interpret messages in context rather than relying on a single copied search result. A process can remain open while the stream is no longer reaching YouTube; compare FFmpeg output with the Live Control Room status.
Run a test long enough to cross the end of the file and enter the next pass. If the stream has a visible or audible break there, revise the source or edit points. Also test the intended resolution and frame rate with representative scene changes and sound. YouTube’s settings page recommends testing representative audio and video motion and running a speed test for upload bitrate; a static menu screen does not reveal how a high-motion scene will behave.
Plan what a failure looks like. -stream_loop -1 repeats the input but does not restart FFmpeg after an exit, restore a failed network route or alert you when YouTube stops receiving data. For a machine-based operation, keep the computer awake, make the file available, monitor the process and stream health, and arrange process supervision or a restart procedure separately. A remote monitoring approach for an unattended 24/7 stream can help frame that operational work even if you use FFmpeg rather than OBS.
Do not assume that an all-day broadcast is archived in the same way as a shorter one. YouTube’s encoder setup page says streams under 12 hours are automatically archived; do not extend that statement to longer streams without checking current official guidance. If keeping a recording matters, make a separate recording plan and verify it independently of the live output.
When a managed service may fit better
Running FFmpeg yourself is a reasonable fit when you want direct control over the command, already have a suitable always-on machine and connection, and can respond when the process or stream needs attention. You decide how to prepare the file and can inspect the encoder output directly. In exchange, you own the computer’s power and sleep settings, software updates, credentials, upload capacity, logs and recovery plan.
A managed 24/7 service may suit you if the specific burden is keeping your own computer running and restarting a broadcast after a process interruption. StreamNeo turns an uploaded video into a YouTube live stream, so you do not have to leave your computer switched on for that file-based broadcast. It does not remove the need to prepare the content, check YouTube’s settings or monitor the channel’s status.
Compare options on practical criteria, not on a general promise of reliability. YouTube’s encoder directory lists Gyre as a cloud-based service for streaming prerecorded video 24/7; that directory entry is not an independent reliability assessment or a statement that every workflow fits your channel. Check any service’s current terms and supported output before committing.
| Consideration | Run FFmpeg on your own machine | Use a managed file-based service |
|---|---|---|
| Computer at your location | Must remain powered, connected and available | Your computer can be off once the file and stream are set up |
| Encoding control | Direct control over FFmpeg options and local files | Depends on the service’s available settings and supported formats |
| Recovery work | You arrange monitoring and restart or supervision | Check what the service monitors and what recovery it offers |
| Troubleshooting | You can inspect your FFmpeg output and system | You rely on the service’s status tools and support process |
| Cost and terms | Hardware, power, connectivity and your time | Recurring service cost and the vendor’s current terms |
The table is a comparison framework, not a claim that one route is better for every channel. If you need custom filters, unusual audio routing or control of multiple local inputs, FFmpeg may fit better. If the objective is to keep one prepared file live without leaving your computer on, a managed service can remove that specific operational task. Confirm the current compatibility, limits and terms directly before choosing.
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 stream run forever?
It tells FFmpeg to loop that input indefinitely while the process continues to run. It does not guarantee that the process, computer, internet connection or YouTube ingest will stay available, so monitoring and recovery need separate planning.
Should -re go before or after -i?
For this prerecorded-file pattern, put -re before the relevant -i; it paces that input at its native frame rate. Likewise, put -stream_loop -1 before the input it should repeat, because FFmpeg treats these as input options.
Is 5 Mbps the right bitrate for every YouTube Live stream?
No. The example’s 5 Mbps video rate is not universal; YouTube’s recommendations depend on codec, resolution and frame rate. Check the current YouTube encoder settings, then test the intended output against your upload capacity.
Can I leave a long stream unattended and rely on the archive?
Do not rely on the loop option as a recovery plan, or assume every long broadcast is archived. YouTube says streams under 12 hours are automatically archived; check current official guidance for longer streams and arrange separate monitoring and recording if needed.