Oracle Cloud provides the virtual machine and network connection, FFmpeg reads or processes your media and sends it, and YouTube Live receives that feed. You can use them together for a continuous broadcast, but “24/7” is an operating goal: none of the three components guarantees an uninterrupted stream.
The practical route is to test each hand-off separately: confirm the VM can sustain the upload, make FFmpeg loop or play the source as intended, and verify the YouTube preview and stream health. Then decide how you will detect and handle a failed process or a dropped ingest connection.
What a continuous FFmpeg stream requires
A file-based stream has three jobs that are easy to confuse. Oracle Cloud Infrastructure (OCI) runs the operating system and provides network access. FFmpeg reads the media, encodes it if needed and sends it to an ingest address. YouTube Live Control Room provides that address and the stream key, then shows whether YouTube is receiving data and lets you control the broadcast.
A working setup therefore needs more than a command that loops a video. You need a source you are entitled to retransmit, an OCI instance with enough resources for the chosen encoding settings, a working outbound route, a private stream key and a plan for observing failures. Decide whether FFmpeg will copy compatible media or re-encode it; encoding uses CPU, while copying avoids that work but may not meet YouTube’s ingest requirements.
“24/7” describes how long you intend the channel to operate, not a property bestowed by a cloud account or a looping flag. A media loop can keep supplying frames while a process is healthy. It cannot, by itself, restart FFmpeg after a crash, restore a lost network route or ensure a YouTube session resumes as before. Treat each of those as a separate behaviour to test.
Before building, confirm that live streaming is enabled for your channel and check the current YouTube guidance for your account. Also check that your media rights cover continuous retransmission. This article explains a technical workflow, not a determination about copyright, channel eligibility or platform approval. If your format is a playlist rather than one long file, compare the practical options in this guide to looping a YouTube live playlist without a black screen.
Check Oracle Cloud VM and network readiness
In the OCI Console, check the tenancy’s current entitlements, home region, quotas and the instance’s actual shape and status before planning around free capacity. Oracle’s Always Free resources page describes eligible compute and networking resources, but eligibility and availability are subject to the current terms and what is available in your tenancy and region. Oracle also warns that temporary host-capacity shortages can prevent instance creation. Confirm the details in your own console rather than treating a published allowance as a promise that a specific VM will be available.
The page currently describes Always Free allowances including up to two E2.1.Micro instances and an A1 Flex allowance equivalent to 2 OCPUs and 12 GB of memory, alongside monthly resource-hour limits. It also lists 10 TB per month of outbound data transfer. These are Oracle’s published allowances, not a guarantee of capacity, continuous service or a particular network speed for your instance. Check the current resource page and your tenancy meter before using them for a production budget.
Pick a supported Linux image and a shape with suitable CPU and memory for your intended encoding mode. An E2.1.Micro’s limited memory and CPU are not interchangeable with a larger shape; if you need to encode a demanding source, measure the load rather than assuming that a VM can handle it. A1 Flex capacity has different resource characteristics. Its network performance depends on the shape and configured OCPUs, so do not infer a fixed internet upload rate from its memory allowance.
Check the virtual cloud network, subnet, route and security rules. FFmpeg needs outbound connectivity to the YouTube ingest endpoint; the RTMPS workflow described below uses port 443. Do not open inbound ports to the public internet merely because the VM is streaming out. Restrict SSH access to the administration method you use, and keep the machine’s credentials separate from YouTube’s stream key.
A speed test taken once is only a snapshot. During a representative test, watch the VM’s CPU and memory, FFmpeg’s output, and sustained outbound throughput. Leave headroom for variation and protocol overhead; if the upload repeatedly falls below the selected stream rate, reduce the bitrate or choose a different source or instance. For a wider view of the machine-side trade-offs, see what streaming hardware you need for YouTube.
Prepare the source and playback loop
Use a local media file that the VM can read reliably. Upload it to a directory with permissions limited to the account that runs FFmpeg, and confirm the file plays and has the audio and picture you expect. Check its dimensions, frame rate, audio format and duration. A file that plays correctly on your desktop may still be a poor streaming source if its encoding is unsupported by your FFmpeg build or does not match your intended output.
For a single-file loop, FFmpeg’s -stream_loop -1 input option repeats the file indefinitely, and -re paces file reading at its native frame rate. Both are input options, so place them before the corresponding -i argument. These flags address playback of that input; neither is a process supervisor or a connection-recovery policy. The FFmpeg command-line documentation explains input options and their ordering.
A loop boundary deserves its own check. Listen and watch across the end and beginning of the file: a brief silence, a flash to black or an abrupt change in audio level will recur every time around. If the content is devotional, lofi or an information loop, review the transition as a viewer would hear it, not just by checking that FFmpeg remains active. If the source needs a title card or ticker, prepare that deliberately; adding filters increases processing work and may change the CPU headroom you need.
YouTube needs an ingest-compatible output, not merely the original file. If the source is already compatible, stream-copying may reduce CPU use, but you must verify its codecs and parameters against the current YouTube recommendations. If you encode, select a resolution and frame rate appropriate to both the source and the VM. Do not upscale low-resolution material simply to choose a larger output setting.
Create a YouTube event and retrieve ingest details
In YouTube Studio, create or open a live stream in Live Control Room. For a scheduled broadcast, set the event up there, then locate its stream settings. Copy the RTMPS server URL and stream key from the control room. YouTube’s RTMPS guidance describes RTMPS as RTMP sent over TLS/SSL and explains how to find the URL and key. Its RTMPS API documentation specifies port 443.
Use the exact URL YouTube supplies; do not construct a path by guessing the ingest host or application name. Keep the key private. It is a credential that allows a sender to publish to the associated stream, so do not include it in a public script, screenshot, shared repository or support message. Avoid putting a real key directly into a shell command that may be saved in command history. A restricted configuration file or environment mechanism is safer, provided its permissions and handling are also controlled.
The event and the outgoing feed are not the same thing. Starting FFmpeg sends data; Live Control Room shows whether YouTube has detected the encoder and can display a preview. Follow the control room’s workflow for taking the event live. A successful upload test is not proof that an event was made public, and an event that is configured does not prove a feed is arriving.
Plan the duration and archive separately from the feed itself. YouTube says streams under 12 hours are automatically archived; do not assume a single 24-hour event will produce one automatic archive. If you need recordings, decide whether to create shorter broadcast segments, make separate local recordings or retain source files, and verify YouTube’s current behaviour before relying on its archive. A segmented schedule also creates hand-offs to plan and test.
Install and configure FFmpeg on the VM
Install FFmpeg from a package source appropriate for your Linux distribution, then check the installed build and its available encoders and protocols. Package versions and build options differ. In particular, confirm that your build includes the video encoder and RTMPS support required by your command. The FFmpeg protocol documentation is a reference for supported protocols and options; the commands available on your VM remain the final check.
Match output settings to YouTube’s current recommendations and your measured VM capacity. YouTube’s live encoder settings recommend constant bitrate (CBR) and a two-second keyframe interval, which should not exceed four seconds. For H.264, the guide’s examples include 6 Mbps for 720p at 30 frames per second and 10 Mbps for 1080p at 30 frames per second. Those are guidance points, not a requirement to select the higher rate; a smaller setting may be the sensible choice if the VM, source or upload cannot sustain it.
A schematic command makes the placement of the loop options and output parameters clear:
ffmpeg -re -stream_loop -1 -i /path/to/owned-or-licensed-source.mp4 \\
-c:v libx264 -b:v 6M -maxrate 6M -bufsize 12M \\
-r 30 -g 60 -pix_fmt yuv420p -c:a aac -b:a 128k \\
-f flv 'rtmps://INGEST_HOST:443/APP/STREAM_KEY'
This is an illustrative starting point, not a tested universal command. Replace the placeholder URL with the RTMPS details from Live Control Room using a method that does not expose the key in a shared or logged command. Confirm that the source dimensions and frame rate make sense for the selected output. The example encodes with libx264; if that encoder is absent, the command will fail, and installing a different build or selecting a supported encoder is necessary. Audio settings also need to match the source and the actual build.
The rate-control values shown are a starting configuration, not a guarantee of quality or ingest stability. For a 720p30 H.264 stream, YouTube lists 6 Mbps as its recommendation; configure the encoder and keyframe interval consistently, then test representative material. Monitor CPU during motion-heavy scenes and check for dropped frames or repeated encoder warnings. If you have little CPU headroom, use a less demanding resolution or frame rate, or a compatible source and encoding path that does less work.
Start the stream and confirm YouTube receives data
Begin with a short test using the actual source, output settings, network path and YouTube event you intend to use. A private or unlisted test can help you inspect the preview without presenting an unfinished broadcast to viewers; choose the appropriate visibility and event workflow in Live Control Room. YouTube recommends testing and checking stream health. Look for a live preview, a healthy ingest status and audio that is audible and in sync before you decide to take the event live.
On the VM, keep FFmpeg’s standard output and error available in a log you can inspect. A running process is not sufficient evidence: check that the output frame count and timestamps continue to advance, that the encoder is not reporting persistent errors, and that network traffic is leaving the machine. In Live Control Room, confirm the feed is detected and that stream health is acceptable. If the preview is absent, check the exact URL and key, outbound connectivity on port 443, supported codecs and whether the correct event is open.
Observe the test long enough to cover the behaviours you intend to rely on. For a looping file, inspect the transition. For a channel that must remain live for extended periods, monitor the VM’s resource use and the YouTube health panel rather than judging from a brief successful start. A one-off successful test does not demonstrate that the next loop boundary, host maintenance event or network interruption will recover without attention.
Once the stream is stable, document a small operational checklist: how to find the FFmpeg log, how to check the event in Live Control Room, how to restart the process and who can access the stream key. If you are learning the workflow with a different broadcaster first, the OBS guide for a YouTube radio station on Indian broadband covers a distinct desktop setup and its connection considerations; it does not replace testing the OCI route.
Keep availability and Always Free limits in perspective
A process supervisor can restart FFmpeg if it exits, but this is not the same as restoring every part of a broadcast. A restarted process may connect to a new or existing ingest session depending on the event state and timing. A network interruption may behave differently from an encoder crash. FFmpeg has documented options for certain protocol and output recovery cases, but their applicability depends on the protocol, build and command structure. Test the failure you expect rather than assuming a generic reconnect option covers it.
For a Linux system service, configure an appropriate restart policy and retain logs, then deliberately test the response to stopping FFmpeg and restarting the VM. Verify whether the service starts, whether it can read the media and credentials, whether it reconnects to YouTube and whether the control room still shows the expected event. Add an alert or a regular human check for conditions a process supervisor cannot diagnose, such as a stream that runs but has no useful picture or audio.
Oracle’s Always Free page says idle Always Free compute may be reclaimed when its specified utilisation measures stay below 20% over seven days; for A1, the described conditions also include memory. Confirm the current policy and monitor the actual metrics for your instance. Streaming usually creates activity, but that does not make the VM immune to reclamation, capacity constraints, service changes or other interruptions. Do not build a plan on the assumption that an Always Free instance will stay online indefinitely.
Check the outbound-data allowance against your chosen rate and what your tenancy meter records. As an arithmetic estimate before protocol overhead, 6 Mbps sends roughly 65 GB of payload in a day and about 1.95 TB over 30 days; 10 Mbps is roughly 108 GB per day and 3.24 TB over 30 days. These estimates come from bitrate multiplied by time, not from Oracle’s measurement of your instance. Include overhead and any other VM egress, and verify how Oracle applies the published transfer allowance to your tenancy before relying on a cost calculation.
If a local VM demands more maintenance than the channel justifies, compare the operating work rather than only the headline compute allowance. With a file and YouTube event ready, StreamNeo removes the need to keep your own computer on and manage a VM process for that uploaded-file workflow; you still need to prepare the media, protect the key and verify the channel’s broadcast. For a broader comparison of a control-room workflow and cloud playout, see YouTube Live Control Room versus cloud playout for a 24/7 lecture stream.
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 keep an FFmpeg stream running 24/7?
Looping the input with -stream_loop -1 keeps a file repeating while FFmpeg is running, and -re paces the read at the file’s native rate. To handle an exited process, use a supervisor and logs; to handle a dropped ingest connection, test the relevant recovery behaviour separately. Monitor YouTube’s preview and stream health, because a running process alone does not show that viewers are receiving the intended programme.
Can I stream to YouTube from an Oracle Cloud VM?
Yes, if the VM can sustain the selected encode and outbound connection and your channel can use YouTube Live. Use the RTMPS URL and key supplied in Live Control Room, and verify the feed in the control room before taking the event live. Shape availability, network performance and account readiness should be checked in your tenancy and channel rather than assumed.
Will an Oracle Cloud Always Free VM stay up all the time?
No such guarantee should be assumed. Oracle describes Always Free eligibility and possible reclamation of qualifying idle compute, and instance availability can depend on region and capacity. Check the current terms and metrics, and have a tested response for interruptions.
Will a 24-hour YouTube stream be archived automatically?
Do not assume that one 24-hour broadcast will be automatically archived as a single recording. YouTube says streams under 12 hours are automatically archived, so decide whether to use shorter segments or make separate recordings and verify the current platform guidance. A stream remaining live and an archive being retained are separate requirements.