A prerecorded file can be looped into a YouTube Live event with FFmpeg running on an Oracle Cloud compute instance. This creates a live broadcast fed by an encoder; it does not make an ordinary YouTube upload play repeatedly.
The basic sequence is to prepare the cloud instance, create the Live Control Room event, configure FFmpeg to read the file in real time, and send the output to YouTube over RTMPS. Treat the command below as a starting template to validate on your own instance, not as a tested performance guarantee.
How a looping live stream works
There are two different ideas that are often described as “looping a video on YouTube”. The first is an ordinary upload. You upload a file, and viewers watch that video from its YouTube page. YouTube does not turn that upload into an endlessly repeating live channel merely because the file contains a loop or because a player is left open.
The second is a live-ingestion workflow. FFmpeg opens a local file on your cloud machine, reaches the end, opens it again, and sends the resulting audio and video packets to a YouTube Live event. YouTube receives an encoder feed and publishes it as a live broadcast. That is the workflow covered here.
The distinction matters operationally. A normal upload can finish without an encoder, ingest URL or stream key. A live stream needs the channel to be eligible for live streaming, a configured event, a running encoder and a network connection that can keep sending data. If FFmpeg stops, the live feed stops even though the source file still exists.
YouTube’s live-streaming requirements and guidance should be checked before you plan a long broadcast. Confirm that live streaming is enabled and that the channel has no relevant restriction in the preceding 90 days. YouTube’s current rules and interface can change, so use the official page rather than relying on an old tutorial.
This approach suits a single long programme, such as a devotional recording, ambience video or lecture loop. If you need to rotate several files, add new items while the channel is running, or edit a schedule from a browser, the design becomes more involved. A useful comparison is the difference between FFmpeg scripts and playlist plugins for a 24/7 cartoon stream. The right choice depends on whether you value a small command-line setup or easier content changes.
Prepare an OCI compute instance
Create an Oracle Cloud Infrastructure compute instance in a region where you can actually obtain the required capacity. If you are relying on an Always Free allowance, Oracle documents that Always Free compute instances must be created in the tenancy home region. The allowance does not mean that a suitable shape will always be available, nor does it establish that the workload will encode comfortably.
Before uploading a large file, check four things:
- The instance can read the media from local storage or from the storage location you have chosen.
- The selected shape has enough CPU for the codec, resolution and frame rate you intend to use.
- Your tenancy limits and current capacity allow the instance to be created and kept running.
- The account’s current billing state and outbound transfer terms match your plan.
Oracle’s Always Free resources documentation lists the available allowances, including the documented outbound transfer allowance. Read the current page before relying on any allowance. A transfer allowance is not the same as a promise that a particular instance will have the CPU, network behaviour or availability needed for a sustained encoder workload.
Choose the operating system you can maintain. A minimal Linux image is often easier to administer remotely, but simplicity does not remove the need to apply security updates and protect access. Use an SSH key rather than sharing a password, restrict administrative access where practical, and avoid opening unrelated inbound ports.
Copy the source file to the instance and confirm that its size is plausible. A file that is still transferring, truncated or unreadable will produce a problem that looks like an FFmpeg or YouTube problem later. You can inspect the file with FFmpeg before creating the live event:
ffprobe input.mp4
The command should show the streams, duration, frame rate, dimensions and audio format. Keep a local copy of the original file. If you re-encode or replace the cloud copy while troubleshooting, you want a known source with which to compare.
The low-power PC discussion for a 24/7 YouTube stream covers a related decision from a local-machine perspective. The same practical question applies on OCI: can the chosen compute resource process the selected output continuously, with enough room for variation, rather than merely starting the command once.
Set up the YouTube Live event
Open YouTube Studio and use Live Control Room to create or schedule the broadcast. The exact labels can vary between the stream setup views, but you need the event’s ingest details before FFmpeg can connect.
Select the stream settings that match the output you intend to send. Note the resolution, frame rate, latency choice and visibility setting. For a first test, an unlisted event is usually easier to inspect without sending an unfinished broadcast to your audience. Once the feed is behaving as expected, create the public schedule you actually need.
YouTube recommends RTMPS for live streaming. The event provides the RTMPS server URL and a stream key. Copy both from Live Control Room and keep them private. A real stream key is a credential for the channel’s ingest connection, so do not paste it into a public article, screenshot, issue tracker or shared chat.
Do not guess the URL path. YouTube supplies the endpoint associated with the event, and you should paste that value into your local configuration. The YouTube encoder settings guide explains the current ingest options and settings to use for the selected resolution and frame rate.
YouTube’s encoder guidance includes constant bitrate and a recommended two-second keyframe interval, with the interval not exceeding four seconds. The correct video bitrate depends on the resolution, frame rate and codec. For example, the current YouTube table lists 10 Mbps as a recommended H.264 bitrate for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps. Do not transfer either figure blindly to a different output.
You also need upload headroom. YouTube recommends leaving 20% spare bandwidth. If your encoder sends a 4,500 kbps video stream plus audio, your connection should have room above the total rather than operating at its limit. On OCI, consider the outbound path and your account’s current terms, then confirm the actual behaviour with a test.
Install and check FFmpeg
Install FFmpeg using the package method supported by your chosen operating system, or use a trusted build appropriate for that image. Package names and available versions vary, so follow the distribution’s current documentation rather than copying an installation command meant for another release.
After installation, check that the executable is available:
ffmpeg -version
ffprobe -version
The relevant capabilities include reading common containers, decoding your source, encoding H.264 and AAC, and writing an FLV stream to an RTMPS destination. The FFmpeg documentation describes the command-line structure, while the FFmpeg protocol documentation covers protocol handling. The exact list shown by your build is what matters on the instance.
Inspect the encoders if you are unsure whether the build includes the ones used below:
ffmpeg -encoders | grep -E 'libx264|aac'
If libx264 is missing, do not assume that another H.264 encoder will accept exactly the same options. Choose an encoder available in your build and then compare its output with YouTube’s current requirements. Hardware encoding may reduce CPU use, but its options and quality vary by instance and image. The OCI allowance alone does not prove that either software or hardware encoding will sustain your chosen settings.
Loop a prerecorded input with FFmpeg
The key input option is -stream_loop -1. The -1 means to repeat the input indefinitely. Put this option before the corresponding -i, because it is an input option. The -re option reads a file at its native rate instead of sending it as quickly as the machine can process it. For a file-based live feed, that helps the packet timing resemble a real-time source.
A minimal illustrative command is:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \
-pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -f flv \
'rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Replace input.mp4 with the actual path. Replace the destination with the RTMPS URL and key copied from Live Control Room. Keep the destination out of shell history where possible, and make sure any configuration file containing it has restrictive permissions.
This exact command is not a universal YouTube profile. The -b:v, -maxrate and -bufsize values are examples that must be compared with the current YouTube matrix and with the capacity of your instance and network. The example’s -g 60 produces a two-second GOP only when the source is 30 fps. At 25 fps, 50 frames would represent two seconds; at 60 fps, 120 frames would. Select the GOP value to match the actual output frame rate and YouTube’s guidance.
The source’s native frame rate is important. If the file is 30 fps, the example may be a reasonable shape for a 30 fps test. If it is 24, 25 or 60 fps, decide whether to preserve that rate or explicitly convert it, then choose the bitrate and keyframe interval accordingly. Check the result with ffprobe and the preview in Live Control Room.
The audio settings also need checking. The example asks FFmpeg to encode AAC at 128 kbps, but your source may have no audio, multiple audio streams or an unusual sample rate. If the input contains several tracks, add explicit mapping rather than assuming the first streams are the ones you want:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-map 0:v:0 -map 0:a:0 \
-c:v libx264 -preset veryfast -c:a aac -b:a 128k \
-f flv 'rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Use the second form only when the selected audio stream exists. If the source has no audio, the mapping will fail and you need a deliberate silent-audio or video-only design that matches YouTube’s current requirements.
You can choose stream copy instead of re-encoding only when the source codecs, timing, container behaviour and output requirements are compatible. Copying may reduce CPU work, but it gives you less control over bitrate, pixel format, frame rate and keyframes. Re-encoding gives control but uses compute. Validate either path on your instance.
Do not apply -re indiscriminately to a genuine live capture input. It is useful here because the input is a file being used as a simulated live source. A real capture device already has its own timing and should be handled differently.
Send the feed and validate ingest settings
Start with a short, unlisted or otherwise controlled test event. Run the command, then open Live Control Room and wait for the preview. Check that motion is smooth, audio is present, the resolution is what you selected and the stream health indicators do not report a sustained problem.
The order matters. First confirm the channel and event, then prepare the file and command, then start FFmpeg, then inspect the preview and health. If you start the encoder before the event is ready, you may spend time diagnosing a rejected or incomplete event rather than a media problem.
Compare the observed output with YouTube’s live encoder recommendations. Look at the reported incoming bitrate and frame rate rather than judging only the local CPU graph. A machine can have spare CPU while the outbound connection is unsuitable, or show a healthy network while the encoder cannot maintain its requested frame rate.
YouTube also recommends testing the stream and monitoring stream health. A 20% bandwidth margin is a recommendation, not a substitute for observation. Run the test during the conditions in which you expect to operate. If the audience is mainly in India but the machine is in another region, the audience location does not by itself determine the encoder’s outbound path; the instance’s connection to YouTube is the immediate concern.
If you need HLS for a particular workflow or codec, consult YouTube’s current documentation rather than changing the RTMPS command casually. The general encoder guidance recommends RTMPS, and the event’s supplied ingest details should take priority over a URL copied from a different tutorial.
For a larger operating plan, it can help to read about scheduling a continuous prerecorded stream on YouTube. Scheduling is separate from keeping FFmpeg alive, but both need to be planned if you want the broadcast to begin at a particular time.
Supervise the process and inspect logs
A terminal command that works once is not yet an operating setup. If the SSH session closes, the process may stop unless you deliberately run it under a service manager or terminal multiplexer. A service manager is usually clearer for a long-running process because it can start the command at boot, capture logs and attempt a restart after a process exit.
Keep the stream key in a protected environment file or service configuration rather than placing it in a public script. Restrict permissions on that file. If you suspect the key has been exposed, rotate it in YouTube Live Control Room and update the service.
Capture FFmpeg’s standard error output. It contains useful information about input detection, encoder speed, reconnect behaviour and output errors. For a first run, save a log file while also watching the console:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \
-pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -f flv \
'rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY' \
2>&1 | tee -a ffmpeg.log
Watch for repeated reconnects, input starvation, encoder speed below real time, dropped frames and messages showing that the output has stopped advancing. Also inspect the Live Control Room health view. Local logs and YouTube’s view answer different questions: FFmpeg tells you what the process believes it is doing, while YouTube shows what is arriving at the ingest service.
FFmpeg documents FIFO output options that can help retry after some temporary network failures. These options are an optional hardening path, not a promise that a YouTube broadcast will remain uninterrupted. They cannot repair a stopped host, an invalid stream key, a full disk or an instance that lacks encoding capacity. Test any recovery configuration on your own event before depending on it.
Plan what happens after an interruption. Decide who will notice the alert, how the process will be restarted, and whether the YouTube event needs attention after the connection returns. An automatic restart of FFmpeg is not the same as a guarantee that the live event will resume exactly as viewers expect. The practical lessons in fixing a YouTube Live network error on a VPS are relevant here because the symptoms can be similar even when the hosting provider differs.
Remember the archive boundary as well. YouTube says streams under 12 hours are automatically archived. That statement should not be read as a promise that one uninterrupted broadcast longer than 12 hours will produce one automatic archive. If the recording matters, plan how you will preserve the source file and how you will handle the live event’s archive behaviour.
If maintaining an OCI instance, watching logs and responding to failures is more work than you want, StreamNeo removes the particular burden of keeping your own encoder process running: you upload the file once, provide the YouTube connection details, and the cloud broadcast can be monitored and restarted without your computer staying on. It remains a YouTube-only workflow, and you should still check your content, channel and live-stream requirements yourself.
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?
Use FFmpeg’s -stream_loop -1 before the input’s -i option, then send the encoded output to the RTMPS URL supplied by YouTube Live Control Room. This creates a live broadcast from a repeating file; it does not make a normal YouTube upload loop automatically.
Can I run a YouTube live stream from Oracle Cloud?
Yes, provided your channel is eligible, the OCI instance can read and encode the file, and its outbound connection can reach YouTube reliably. Oracle’s documented free allowances do not prove that a particular shape has capacity or that it will sustain your chosen encoding settings, so validate the workload on your own instance.
What does -re do in this command?
For a file input, -re makes FFmpeg read at the file’s native rate instead of sending the file as fast as possible. That is useful when using a prerecorded file as a live source. It should not be added automatically to a genuine live capture input that already supplies real-time timing.
How long can the YouTube archive be?
YouTube states that streams under 12 hours are automatically archived. Do not use that statement to promise a single automatic archive for a longer uninterrupted broadcast. Check YouTube’s current help guidance and keep your own source file if the recording is important.