When FFmpeg YouTube livestream disconnects on Oracle Cloud Ubuntu, the symptom alone does not identify the cause. First establish whether FFmpeg exited, its input stopped, the VM or network failed, or YouTube stopped receiving a usable feed while FFmpeg remained running.
Do not change several settings at once or assume Oracle Cloud is blocking RTMPS. A timestamped FFmpeg log, process and VM status, a check of the input, and YouTube Live Control Room’s stream-health view can narrow the fault to a useful branch before you make a change.
Record the disconnect, not just the complaint
Start a simple incident record. Note the UTC time when the stream appears to stop, the time YouTube Live Control Room reports a change in health or status, and whether the viewer-facing stream freezes, ends, or resumes. These events may not happen at precisely the same moment: the player can buffer, and the control room may show a receiving or health change after the initial fault.
Also record whether the FFmpeg process is still running. If it exited, note its exit time and status. If it remains alive, check whether its logs continue to advance and whether output counters or progress information change. A process that exists is not proof that it is sending data; a process that stopped is different from one blocked while reading an input.
Keep the exact times together so you can compare different evidence later. For example, if the player freezes at 02:14 UTC, check the FFmpeg stderr immediately before and after that time, system logs, VM monitoring, and YouTube’s health timeline. Avoid relying on a remembered time or a screenshot taken much later.
Use a consistent clock where possible and write down the time zone. UTC makes it easier to compare machine logs and cloud metrics without accidentally shifting the event by the local time offset. If you run a long-lived channel, keep a short incident log with the input, output settings, and recent changes; that is more useful than a general note saying “it dropped overnight”.
Keep sensitive data out of the record. Redact the YouTube stream key and any credentials embedded in an input URL before you save, share, or attach command output. The key is effectively a publishing credential; anyone who obtains it may be able to send video to that live destination.
Capture FFmpeg’s version, command and error
Record the installed FFmpeg version and build configuration from the same Ubuntu VM that runs the stream. Different builds may have different protocol support, so a command copied from another machine is not enough to establish what this binary can do. Save the exact command with the key redacted, and note the input type, output protocol, codec, resolution, frame rate, and configured bitrate.
Capture the complete stderr around a disconnect, not only the final line. FFmpeg often prints useful context before an exit or write failure. A message about an input read, encoder, TLS handshake, socket write, or end of file suggests different next checks, but none is a root-cause finding on its own. Preserve the lines preceding the error as well as those after it.
If FFmpeg is started by a script, cron job, systemd unit, or another supervisor, capture how that wrapper launches it and where it writes output. A shell may discard stderr, rotate logs, or report only the wrapper’s exit status. Make sure the log collection itself survives long enough to record a failure; otherwise a silent gap may mean missing evidence rather than a silent FFmpeg process.
Check the local binary’s help and documentation for any option you plan to use. Do not paste a generic reconnect flag into a production command because it appears in a forum answer. Whether an option applies depends on the installed build, the input protocol, output muxer, and how the process is managed. Test changes with the real source and destination before relying on them overnight.
For YouTube output, verify the ingest URL against the one shown in Live Control Room. If you use RTMPS, confirm the scheme, hostname, port, and key/path arrangement expected by your FFmpeg workflow. YouTube may display an RTMP address by default; use the control room’s RTMPS URL when that is the protocol you intend to send. Never include the actual key in a command shared for troubleshooting.
A careful record also helps when the problem resembles YouTube’s “no data is being received” status. The guide to checking YouTube Live Control Room’s no-data message can help you interpret what the control room is reporting, but pair that status with the encoder-side logs rather than treating it as a diagnosis by itself.
Check whether FFmpeg or the VM stopped
If FFmpeg exited, find out whether it exited cleanly, returned an error, or was terminated by the operating system or a service manager. Check the process supervisor’s logs and Ubuntu system logs around the recorded time. Look for an explicit restart, shutdown, kernel or resource warning, and any service-unit policy that may have stopped the process. Do not infer a VM outage just because the stream vanished.
If the VM itself was unreachable, compare the disconnect with the instance’s state and its monitoring history. Check whether the instance rebooted, was stopped, or experienced resource pressure. CPU saturation can make encoding late or prevent it from keeping up; memory pressure can lead to a process being killed. Those are possibilities to test against monitoring and logs, not facts established by a disconnect.
If FFmpeg is still running, distinguish a stalled input from a stalled output. Check whether input timestamps or progress continue, whether the source file or playlist advances, and whether FFmpeg reports that it is waiting for data. A live capture or network input can stop delivering packets even though the output process remains present. A prerecorded file can reach its end sooner than expected, or a playlist can fail to provide the next item.
For a file loop, verify that the input is actually configured to repeat and that the playlist has readable entries. For a remote input, test the source independently and inspect its own logs or availability. If you use a continuous playlist, the article on keeping an always-on podcast stream running from a Linux desktop is relevant to the input and process-management side, although your cloud VM and command may differ.
Check the encoder workload separately from network delivery. Record the configured output rate and observe CPU use and FFmpeg’s progress during a representative test. If the source is a high-resolution video that needs scaling or encoding, a VM that cannot keep up may show delayed output or missed work. A CPU or input finding should come from measured behaviour near the event, not from the fact that the stream is hosted in the cloud.
Test input continuity and outbound capacity
Establish whether the input is continuous at the time of the drop. For a local file, check that the file remains available, readable, and long enough for the intended loop. For a playlist, check paths and permissions for every entry, not only the first. For a remote feed, compare its availability and timestamps with FFmpeg’s input-side messages. If the input source stops, reconnecting the YouTube output will not restore missing programme material.
Next compare the configured video bitrate with the VM’s sustained outbound capacity. A brief speed test or a cloud interface rate observed at one moment is not proof that the path can sustain the encoder’s rate through a long broadcast. Record the codec, resolution, frame rate, and configured bitrate, then conduct a representative test with audio and motion similar to the planned stream. YouTube recommends testing upload bitrate and monitoring stream health during a test.
YouTube’s current encoder-settings guidance provides recommended bitrate ranges by codec, resolution, and frame rate. For H.264, the page lists 1080p30 at 5 Mbps minimum and 14 Mbps recommended, and 1080p60 at 6 Mbps minimum and 17 Mbps recommended. For 720p30 and 720p60 it lists 3 Mbps minimum and 8 Mbps recommended. These are settings guidance, not a promise that a particular OCI route can sustain those rates. See YouTube’s encoder settings and bitrate guidance.
YouTube also recommends constant bitrate (CBR), a two-second keyframe interval, and a maximum keyframe interval of four seconds. Treat these as encoder settings to verify, not a cure for every disconnect. A controlled test at a lower bitrate can help assess whether upload capacity is involved. If the stream becomes stable, that is evidence worth following up, but it does not identify which part of the path was limiting it.
If your stream uses mixed file formats or resolutions, confirm that the FFmpeg filter and encoding path handle each item as expected. A transition that changes frame rate, dimensions, or timestamps may present as an input or encoding problem rather than a network fault. The guide to streaming mixed-resolution videos in one continuous YouTube Live stream can help you examine that part of the setup.
Review OCI rules and YouTube ingest status
For RTMPS, Google’s ingestion guidance specifies a TLS connection to port 443 and says the destination hostname is required for authentication through SNI. RTMPS is RTMP over a secure connection. A wrong URL, a mismatched protocol, a port issue, or a TLS/SNI problem can lead to errors that look like a timeout or SSL failure. Confirm the actual URL from YouTube Live Control Room and inspect FFmpeg’s error before changing network rules. Read Google’s RTMPS delivery documentation.
Check OCI’s network controls as separate layers: network security groups associated with the VNIC, security lists attached to the subnet, and the Ubuntu guest firewall. An outbound allow rule in one place does not establish that the full route and policy permit the connection. Review the route table and the applicable policies for the VM, and verify the outbound TCP/TLS path to the selected ingest endpoint on port 443 when using RTMPS. Do not apply an inbound-port recipe blindly to a workload that publishes outbound.
If the stream drops intermittently, correlate the incident time with the attached VNIC’s connection-tracking metrics. Oracle documents metrics for packets dropped when a connection-tracking table is full and for connection-tracking utilisation. Oracle’s guidance says a non-zero full-table dropped-packet count indicates a full table; 100% utilisation also indicates it is full. Check the relevant VNIC, metric interval, and time range before drawing a conclusion. See Oracle’s VCN troubleshooting guidance.
Do not assume that Oracle Cloud is blocking RTMPS. A failure could be in FFmpeg, the input, the guest firewall, OCI policy or route, connection tracking, the endpoint configuration, or YouTube’s ingest state. The available facts in a short report such as “it disconnects at night” cannot identify which one. If a network rule is changed, record the prior rule and test the same stream again so you know what changed.
Compare FFmpeg’s timestamps with YouTube Live Control Room’s stream health and status. YouTube recommends testing with representative audio and movement and watching health during the event. A stream that remains connected but becomes unhealthy is different from a TCP/TLS write failure. Check the control room’s current message and the matching encoder logs before deciding whether to adjust bitrate, repair an input, or investigate the route.
Choose recovery and monitoring for the failure mode
Pick a recovery mechanism only after you know which part failed. If a finite input ended, repair the loop or playlist. If a remote input stalled, test whether the input can be reopened safely. If FFmpeg exited after a write error, investigate the output path and decide whether a supervisor should relaunch it. If the VM stopped or rebooted, fix the instance or service behaviour first. A restart cannot correct a persistent bad URL, blocked route, exhausted source, or insufficient capacity.
Do not assume a generic FFmpeg reconnect option will resume the live programme at the interrupted media position. Recovery depends on the installed FFmpeg version, protocol, muxer, input, and wrapper design. The official documentation does not establish a version-independent YouTube resume command. Test an actual failure with your own source and endpoint, and confirm what viewers and Live Control Room see when the process returns.
If you use systemd or another supervisor, configure it deliberately and retain the original FFmpeg stderr. Check that a relaunch does not create duplicate publishers, conceal repeated failure, or enter a rapid restart loop. A delay, restart limit, and clear alert can make a broken service easier to diagnose; the exact policy should match the failure mode and your tolerance for a short interruption. Confirm that a restarted process uses the intended input position and stream destination.
Monitoring should tell you about both the process and the received stream. At minimum, make it possible to learn that FFmpeg exited or stopped advancing, and check YouTube Live Control Room when the stream is reported unhealthy or no data is received. For unattended channels, arrange an alert or a regular check that does not depend on the same process whose failure you need to detect. Keep timestamps and enough log history to diagnose an overnight event.
If the recurring burden is keeping an Ubuntu machine and its FFmpeg process running and watched, StreamNeo removes that particular operating task by turning an uploaded video into a YouTube live stream without your computer running. It does not diagnose a faulty source file or guarantee that YouTube will accept a stream; you still need a ready file, the correct channel details, and to check the live result.
For channels that need a local FFmpeg setup, the guide to running a 24/7 Telugu nursery rhyme channel with FFmpeg offers a useful comparison for the publishing workflow. Whatever approach you use, test the exact source, destination, and recovery behaviour you plan to rely on, then review the evidence from that test rather than assuming it will survive a night unchanged.
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
Why does my FFmpeg YouTube stream keep disconnecting?
The disconnect description does not identify a cause. Check whether FFmpeg exited, its input stalled, the VM stopped, an output or TLS error appeared, or YouTube marked the incoming stream unhealthy. Match timestamped logs and monitoring with Live Control Room status before changing settings.
How do I reconnect FFmpeg to YouTube Live?
There is no single reconnect command that can be assumed to resume every setup correctly. Check the installed build’s help, identify whether the input or output failed, and test any restart or reconnect behaviour with your actual source and YouTube endpoint. Preserve logs and make sure a supervisor does not create duplicate streams or hide a repeated failure.
Is Oracle Cloud blocking my RTMPS stream?
A disconnect alone does not establish that. Verify the YouTube-provided RTMPS URL, port 443 and TLS/SNI details, then inspect the applicable OCI network security groups, subnet security lists, route, guest firewall, and connection-tracking metrics. Correlate any finding with the event time before attributing the fault to OCI.
What should I collect before asking for help?
Share the FFmpeg version and build, a redacted command, input type, relevant stderr before and after the event, UTC timestamps, and whether FFmpeg and the VM remained up. Include the encoder settings and the matching YouTube stream-health status. Remove stream keys and credentials from logs, screenshots, and command lines.