To loop a prerecorded video on YouTube Live from Compute Engine, put FFmpeg’s -stream_loop -1 before the file input and use -re so the file is read at its normal playback rate. Then send the output to the stream URL and key currently shown in YouTube Live Control Room, and check the preview and stream health rather than assuming that a looping command guarantees an uninterrupted broadcast.
The loop repeats the input file; it does not repair a broken file, make unsupported codecs compatible, or keep a YouTube event live indefinitely. The workflow below separates those jobs: prepare and inspect the media, set the input options, choose output handling, connect securely, and test the actual feed.
Prepare the prerecorded video file
Start with the exact file you intend to broadcast. Confirm that it plays from beginning to end on a local player, has the intended picture and sound, and does not contain an unwanted blank tail or a damaged ending. If the video is part of a devotional playlist, a local news loop or a study channel, review the transition from its last frame and audio back to its first. A hard cut can be acceptable, but it should be a deliberate part of the programme rather than a surprise discovered after going live.
Check the file’s streams and codecs before writing the output command. FFmpeg’s ffprobe utility can report container, video, audio, resolution, frame rate and duration. For example, run ffprobe -hide_banner -i programme.mp4 in a terminal where FFmpeg tools are installed. The command prints information; it does not prove that YouTube will accept every combination of codecs or that the source is free of corruption. Read the output and compare it with YouTube’s current encoder settings.
Compute Engine is a virtual machine, so place the media somewhere the FFmpeg process can read it: on the VM’s local disk or in a mounted location configured for access. Confirm the path, file permissions and available disk space. Avoid assuming a file on your own laptop is visible to a remote VM. If the file is large or you are working over a constrained connection in India, plan the upload before the broadcast rather than starting it shortly before the scheduled stream; this guide to uploading large videos for a YouTube 24/7 stream covers that separate preparation problem.
You need an eligible YouTube channel and a stream created or selected in Live Control Room. YouTube’s current eligibility requirements include channel verification, no live-streaming restrictions during the preceding 90 days, and a minimum age requirement. The requirements can change, so check YouTube’s live-streaming eligibility page for the current rules before planning a public broadcast. A correct FFmpeg command cannot bypass channel eligibility.
Put the loop option before its input
The essential FFmpeg option is -stream_loop -1. The value -1 means loop indefinitely, as documented by the FFmpeg command-line reference. In practical terms, FFmpeg opens the named input, reaches its end, and starts reading that input again. It does not mean that the stream destination or YouTube event is immortal.
Option order matters. -stream_loop is an input option, so place it before the -i that introduces the file it should repeat. A basic command shape is:
ffmpeg -stream_loop -1 -i /path/to/programme.mp4 [output options] [destination]
The bracketed parts are explanatory placeholders, not text to paste literally. The important relationship is that -stream_loop -1 is on the input side of -i. If you put it after -i, it will not apply to that already-opened input in the intended way. If you later add a separate audio file, image, or other input, review option placement for each input rather than assuming one loop option covers every source.
Test the file itself before connecting YouTube. You can use a short local run or inspect a representative segment to see whether decoding reports errors and whether audio and video are present. A loop cannot fix an incompatible or corrupt input; repeating it will repeat the same fault. If the media has an unsupported stream, repair or convert the file first, and verify the revised file before attempting a live broadcast.
Read the file at real-time speed
For a file input that is meant to become a live feed, add -re before the input as well. FFmpeg describes -re as reading input at its native frame rate. Without real-time pacing, a file can be processed as quickly as the machine and pipeline allow, which is not the behaviour wanted for an ordinary live programme. Pair it with the loop option before -i:
ffmpeg -re -stream_loop -1 -i /path/to/programme.mp4 [output options] [destination]
Both options are input-side settings here. They answer different questions: -stream_loop -1 says what to do at end of file; -re says how quickly to read the file. Neither specifies the video encoder, audio encoder, output bitrate or YouTube destination. Those need to match the source and current ingest requirements.
A prerecorded file may already have been encoded for normal playback, but playback compatibility is not identical to live-ingest suitability. Real-time reading controls pace; it does not convert codecs or guarantee stable frame timing. Observe the FFmpeg log during a test and look for decode errors, repeated warnings or unexpected pauses. A file that plays correctly in one desktop application may still expose a problem when FFmpeg decodes it or sends it through a live output pipeline.
If you are assembling content from several sources instead of repeating one file, the input and transition design changes. A looping single-file command will not create clean joins across a playlist. For browser overlays on a prerecorded broadcast, see how an OBS browser source can be used as an overlay; that is a different production arrangement from a single FFmpeg input.
Choose copy or re-encode deliberately
Whether to copy or encode the media depends on the file’s streams and YouTube’s current ingest specifications. If the codecs and container are already suitable, stream copying may avoid unnecessary transcoding; if they are not, you may need to encode the output. Do not choose copy merely because it uses less CPU, and do not add encoding options blindly: first establish what the input contains, then check YouTube’s latest requirements.
The following is a decision aid, not a claim that either path has been tested on a particular Compute Engine machine:
| Path | What FFmpeg does | Useful when | Main trade-off |
|---|---|---|---|
| Copy compatible streams | Sends the existing audio and video streams without re-encoding | The source streams already meet the destination requirements | Lower encoding work, but incompatible codecs or stream properties remain incompatible |
| Re-encode video and audio | Decodes the source and produces new output streams | The source needs a codec, bitrate, frame-size or audio change | More CPU work and another quality-loss opportunity, but output can be selected to meet the current target |
YouTube’s encoder settings page lists H.264, H.265/HEVC and AV1 video, and AAC or MP3 audio, with a caveat for listed surround-sound configurations. It recommends constant bitrate and a two-second keyframe interval, and says not to exceed four seconds. Use the page’s current details when you choose options; these are YouTube’s published specifications and recommendations, not results from a test on your file.
For a concrete comparison, YouTube’s current settings page lists 720p at 30 fps with a recommended 2 Mbps and maximum 6 Mbps for the relevant codec range, while the H.265/AV1 figures are 3 Mbps recommended and 8 Mbps maximum. These are not universal targets for every resolution or codec, and the values can change. Check the live table and select the row that matches the actual output codec and frame rate rather than treating one bitrate as correct for all feeds.
Transcoding also affects the Compute Engine choice. A machine that can copy streams may not have enough CPU headroom to encode the same file in real time, particularly at higher resolution or with more complex settings. This research does not establish a suitable machine type, region or cost. Compare current Google Cloud options against the processing load and sustained outbound throughput you need, and check current pricing before running a machine continuously. If you want distinct programmes on separate channels, the workflow is not just a second FFmpeg input; this guide to keeping two YouTube 24/7 channels on different video rotations addresses that scheduling problem.
Set the current YouTube destination and key
In YouTube Live Control Room, create or select the stream and copy the current stream URL and stream key into the encoder settings. The YouTube encoder setup instructions explain where those values are shown and used. Do not copy an endpoint from an old tutorial and assume it remains the right destination for your stream. Use the values displayed for the current stream.
Prefer the RTMPS URL when it is offered and your FFmpeg build supports it. YouTube describes RTMPS as an encrypted extension to RTMP and explains how to reveal the RTMPS address in Live Control Room in its RTMPS instructions. If troubleshooting requires a port or host change, follow the current official instructions for the address shown there; do not infer an endpoint from an unrelated example.
Treat the stream key like a password. Do not publish it in an article, screenshot, shared terminal recording or a repository. Avoid leaving it in shell history where other users of the VM can read it. A command shown in an internal runbook should use a placeholder, not a real key. If the key is exposed, use YouTube’s current stream settings to reset it, then update the encoder configuration. YouTube’s stream settings guidance explains management of the key.
A schematic output portion might look like this, with placeholders that you replace privately using the current URL and key:
-c:v libx264 -b:v 2M -maxrate 2M -bufsize 4M \
-g 60 -c:a aac -b:a 128k -f flv \
"rtmps://[current-ingest-host]/[stream-key]"
This is a shape to explain where output settings and destination belong, not a universal command. The illustrative bitrate, keyframe setting and codecs must be checked against the current YouTube table and your frame rate; the command’s exact values may be wrong for a different source. Do not paste the placeholder URL or key. Some FFmpeg builds or output formats may require different options, so validate the command with the FFmpeg documentation and a private test.
Test the feed and monitor stream health
Before making a stream public, start the encoder and inspect the Live Control Room preview. Confirm that the expected image appears, sound is present and in sync, and the title, audience setting and visibility are correct. Let the loop reach its boundary during a controlled test if possible. This is the moment when a bad cut, audio gap or file-decoding issue becomes visible.
Watch YouTube’s stream-health messages and FFmpeg’s own output. A process can remain running while the feed is wrong, and a clean preview at startup does not prove that the programme will stay healthy overnight. Look for network interruptions, encoder errors, unexpected silence, black frames and a stalled picture. When an issue appears, note its timing and compare the logs and preview rather than restarting repeatedly without a diagnosis.
Plan outbound capacity for the configured bitrate. YouTube recommends keeping 20% upload-bandwidth room and checking the available outbound speed; it also notes that shared connections can reduce capacity available to an encoder. This is planning guidance, not a reliability guarantee. A cloud VM’s network path and current throughput still need to be checked in your own environment. YouTube’s streaming tips describe bandwidth planning and related checks.
A process supervisor or restart policy can help recover from a process exit, but it cannot ensure that a failed input, expired event, invalid key or poor connection is corrected. Monitoring must include both the machine and the actual YouTube feed. If YouTube shows a yellow or red health state, use the symptom-specific checks in this guide to fixing stream health in YouTube Studio, then confirm the preview has recovered.
If the broadcast is scheduled as an event, allow time to configure and test the encoder before the planned start. YouTube’s live-streaming tips give advance setup and startup recommendations; check the current official tips page for the applicable guidance. YouTube says streams shorter than 12 hours are automatically archived, but that archive rule is not a promise of indefinite availability or continuous playback. A looped input and a scheduled event have separate lifecycles.
For operators whose recurring difficulty is keeping a personal computer awake, FFmpeg on a cloud VM can remove dependence on that particular desktop staying open, but the VM and process still require setup and observation. StreamNeo can remove the need to keep a local computer running by taking an uploaded file and your YouTube stream key for a cloud-run broadcast, while leaving the need to use a compatible source and check YouTube’s stream health in place.
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 YouTube stream live forever?
No. It tells FFmpeg to repeat an input indefinitely while the process continues. YouTube’s event lifecycle, stream health, key validity, machine operation and network path are separate, so monitor the actual broadcast and do not treat the loop as a guarantee of continuous live status.
Why must -stream_loop -1 come before -i?
It is an input option and applies to the input introduced by -i. Put it before the filename’s -i option so FFmpeg knows to loop that file; placing it on the output side does not express the intended input behaviour.
What does -re change?
For file input, -re asks FFmpeg to read at native frame rate, which is appropriate when the file is being sent out as a live-paced feed. It does not convert the file, fix damaged media or set the destination bitrate.
Can I use the same command for every video?
No. The file’s codecs, frame rate, resolution and audio streams determine whether copying is suitable or transcoding is needed. Inspect the source, consult YouTube’s current encoder settings and test the actual output in Live Control Room before relying on it.