When YouTube drops an FFmpeg live connection, a practical recovery pattern is to run FFmpeg under a supervisor or retry loop that starts a fresh process after it exits. The new process can publish again using the same Live Control Room ingest URL and stream key, but playback may be interrupted and a prerecorded cartoon may restart from its beginning.
Do not assume FFmpeg's reconnect options solve this for RTMP(S) output. Those documented options belong to the HTTP protocol; restarting the publisher process is a separate recovery strategy, not a promise of seamless reconnection or of YouTube preserving the same live event state.
Identify the publishing failure
A cartoon can keep playing locally while YouTube stops receiving the broadcast. That points towards a publishing-path failure, but it does not identify the cause by itself. FFmpeg may have exited after a network interruption, YouTube may no longer accept the supplied key, or the input file may have ended or become unreadable. Start by finding out whether the FFmpeg process is still running and whether its log reports an output error, an input error, or normal completion.
The distinction matters because a restart loop reacts to process exit, not to every possible unhealthy condition. If FFmpeg remains alive while output is stalled, a simple loop that waits for it to exit will do nothing. You would need a separate health check or a deliberate timeout policy to detect that condition, and should validate that behaviour before depending on it overnight.
Check YouTube's Live Control Room at the same time. Its stream-health view can show whether the incoming signal has resumed and whether YouTube is flagging a stream issue. Compare that with the local FFmpeg log and the visible preview; do not treat one green indicator as proof that the entire broadcast is healthy. For a broader view of source and encoding symptoms, see common causes of poor YouTube stream quality.
A restart is most useful when the fault is transient: for example, a brief loss of network connectivity that causes the FFmpeg process to stop. It cannot repair a missing cartoon file, incorrect output settings, a revoked key, a malformed URL, or a network that remains unavailable. Repeatedly launching the same broken command can obscure the real issue and fill logs without restoring the stream.
Check the ingest URL, key and FFmpeg exit
Before building retries, confirm the exact server URL and stream key shown for the event in YouTube Live Control Room. Copy them carefully into the relaunch configuration. Prefer the RTMPS ingest URL when the encoder supports it. Treat the stream key as a credential: keep it out of public posts, screenshots and ordinary logs, and avoid pasting it into places where another user or process can read it.
Read the FFmpeg exit status and the last useful log lines after a drop. An exit status tells you whether the command ended successfully or reported an error, but it does not explain the error on its own. The surrounding log may point to a connection failure, an input read problem, an unsupported encoder, or an output configuration issue. If the process exits successfully because the input ended, that may be normal for a finite broadcast; a retry policy should not turn every successful completion into an endless restart.
Check that the file path exists and is readable by the account running FFmpeg. Verify that the build has the encoder you selected, and that the output is configured for the intended YouTube ingest path. Keep the URL and key separate from the command text where your operating system or service manager permits secure environment configuration. Avoid echoing the full destination into a diagnostic log if it contains the key.
YouTube's live encoder settings guidance describes supported ingest settings and current recommendations. Match the row for your selected codec, resolution and frame rate instead of copying a bitrate from an unrelated setup. YouTube recommends constant bitrate and a keyframe interval of two seconds, with a maximum of four seconds; follow the current page in case its guidance changes. A correctly formatted output does not prevent a network drop, but it removes avoidable configuration errors from the diagnosis.
If the FFmpeg message mentions an SSL or RTMPS connection problem, recheck the chosen server URL and whether the encoder supports RTMPS. YouTube's stream connection troubleshooting page advises checking the URL and RTMPS support; for an SSL error, specifying port 443 may help where the encoder supports it. Treat these as checks, not universal fixes.
Why HTTP reconnect options do not ensure RTMP(S) recovery
FFmpeg supports options with names such as -reconnect, -reconnect_streamed and -reconnect_delay_max. Their names can look like a general-purpose answer to a dropped live stream, but the FFmpeg protocol documentation lists and explains them in its HTTP section. They are useful for certain HTTP connections, including some HTTP media inputs; the documentation does not define them as generic RTMP(S) output retry controls.
That scope is the important point. An HTTP input reconnect setting concerns FFmpeg retrieving media through HTTP. A YouTube publishing connection is an output using RTMP or RTMPS. Similar words do not mean the setting applies to both protocols. Consult the FFmpeg protocol documentation for the options and their documented protocol context, and verify any protocol-specific behaviour for the exact build you use rather than assuming an HTTP flag covers it.
For a failed RTMP(S) publisher process, an external supervisor can start a new FFmpeg process. That new process creates a fresh publishing attempt; it does not resume the old connection at the precise frame where it stopped. YouTube may show an interruption, the live event may need attention in Control Room, and viewers may see a gap. The restart pattern is useful because it automates a new attempt, not because it makes a break invisible.
HTTP reconnect options may still be relevant elsewhere in a workflow. If your input is a remote HTTP stream, those settings may affect how FFmpeg reads that input, depending on the protocol and failure. They do not remove the need to handle failure of the RTMP(S) output separately. Keep input recovery and publishing recovery as two distinct problems when reading logs.
Wrap FFmpeg in a supervisor or retry loop
For a simple shell-based arrangement, the basic logic is: launch FFmpeg, collect its exit status, stop if it completed normally, wait briefly after an error, and launch it again. In a more durable setup, an operating-system service manager can supervise the process and provide restart policy, logs and boot-time start behaviour. These are operating choices rather than guarantees about a particular platform; check the manager's documentation and test its shutdown behaviour.
For a local prerecorded cartoon, a command launched by the supervisor can loop the file and pace its reading in real time. The following is illustrative, not a tested universal preset. Replace the example output settings with values appropriate to the cartoon and YouTube's current table, and arrange for the destination to be supplied securely rather than committing a real key into a script.
#./bin/sh
while :; do
ffmpeg -re -stream_loop -1 -i cartoon.mp4 \\
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \\
-g 60 -keyint_min 60 -sc_threshold 0 \\
-c:a aac -b:a 128k -f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
status=$?
[ "$status" -eq 0 ] && exit 0
sleep 5
done
The example values are there to make the shape of the command legible, not to prescribe a bitrate or keyframe interval for every cartoon. Select bitrate for the actual resolution, frame rate and codec from YouTube's current table. Set a keyframe interval of roughly two seconds for the actual frame rate, consistent with YouTube guidance. Confirm that the FFmpeg build includes the chosen video encoder and that the RTMPS URL and key form the expected destination.
The short fixed wait illustrates a retry, but repeated failures should not cause a rapid, endless launch cycle. Add an increasing delay after successive failures and cap that delay so recovery attempts remain periodic. Decide how to reset the failure count after a sustained healthy run, and how to alert you if attempts continue. The process needs a way to distinguish intentional shutdown from a fault; otherwise an operator asking it to stop may trigger another launch.
| Approach | Useful when | Trade-off to plan for |
|---|---|---|
| Shell retry loop | You need a small, understandable wrapper for a single process | You must handle signals, logs, backoff and normal completion yourself |
| Service manager | The stream should start at boot and be monitored as a long-running service | You need to configure its restart policy, credentials and intentional stop behaviour |
| Manual relaunch | You are diagnosing a one-off failure | Someone must notice the drop and act; it is not unattended recovery |
If FFmpeg is already running on a remote machine, keeping its process alive across a dropped SSH session is a separate concern from recovering a YouTube publishing connection. The guide to keeping FFmpeg running after SSH disconnects covers that process-lifetime problem. A terminal multiplexer or service manager can help with session persistence, but does not itself make a broken RTMP(S) connection reconnect.
For a one-off test, a shell loop may be enough. For a channel expected to run unattended, a service manager is generally easier to operate persistently because it can own process supervision and boot behaviour. Whichever you choose, keep the stream key private, configure a bounded retry delay, and write logs somewhere you can inspect after a night. If you want to avoid maintaining an encoder process on your own computer, StreamNeo removes that specific burden by running an uploaded video as a YouTube live stream without keeping your computer switched on; it does not change YouTube's event rules or remove the need to check channel health.
Relaunch with the Live Control Room settings
A restart uses the settings configured in the new FFmpeg process. It does not fetch the event's current URL or key automatically unless you have built a safe mechanism to provide them. Keep the exact values associated with the intended live event in the relaunch configuration, and verify that you have not copied credentials from a different event. Never paste the actual key into an article, public issue or shared command example.
For a local file, -stream_loop -1 requests repeated input and -re paces file reading in real time. These are input-side choices for a prerecorded file. Do not apply them blindly to an already-live input, where the source has its own timing and may require different options. A process restart with a looped file commonly begins at the start of the cartoon rather than continuing from the exact point of disconnection. If continuity through a particular episode matters, consider whether a gap and a restart from the beginning are acceptable before enabling automatic retries.
Check audio and movement, not only a still title card. YouTube's stream settings guidance includes audio recommendations as well as video: for stereo audio it lists a 44.1 kHz sample rate and 128 kbps bitrate. Use the current guidance for your actual output, and verify the source has sound if sound is intended. A cartoon with a silent opening may make it harder to notice that the input is frozen, so observe a representative section during testing.
If the relaunched process cannot connect, do not increase retries indefinitely before checking the underlying settings. Re-copy the server URL and key from Control Room, confirm RTMPS support, inspect connectivity, and verify that the file and encoder remain available. Retrying identical invalid credentials or a missing file cannot repair them. If you use a separate ingest format such as HLS, it is a different publishing configuration rather than an alternative retry flag; choose it only when the use case and encoder support justify that setup.
For a wider setup checklist covering a prerecorded broadcast, use the Live Control Room settings guide. It is useful to review the event configuration before testing relaunch, so the recovery process is not repeatedly reconnecting to the wrong event or an unintended ingest choice.
Test recovery and monitor repeated failures
Test the complete path before relying on it during a scheduled broadcast. Use representative cartoon audio and motion, launch through the same supervisor you expect to use overnight, and confirm the output appears in Live Control Room. Check the FFmpeg log, the Control Room preview and stream-health status together. A test of only the raw FFmpeg command does not verify that the supervisor has the right environment variables, permissions or restart policy.
Exercise a controlled failure only in a test event or at a time when an interruption is acceptable. Confirm that FFmpeg exits, that the supervisor waits as configured, and that a new process attempts the same intended destination. Observe whether the cartoon starts at its beginning and whether Control Room shows a continuing event or a separate state requiring operator action. Do not infer from one successful test that every network fault or YouTube-side condition will recover the same way.
Check the upload path under the intended bitrate and leave margin for normal variation. YouTube recommends matching stream quality to the available connection, and an unstable connection may produce repeated drops even when the command is correct. If the encoder is using unstable Wi-Fi, test a wired Ethernet connection as a diagnosis; a cable cannot repair invalid credentials, a failing source file or an unsuitable output configuration. The FFmpeg Linux streaming guide can help you check the surrounding command and operating setup.
Keep enough logs to answer three questions: did FFmpeg exit, why did it exit, and did the next process connect? Avoid logging the stream key. If you see repeated connection errors, backoff should prevent rapid relaunches while you investigate. If the log instead reports a missing input or encoder failure, stop the loop and fix that cause. Set an alert or a routine check for prolonged failure rather than treating an active retry loop as evidence that viewers are receiving the cartoon.
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
Do FFmpeg's -reconnect flags reconnect a YouTube RTMP stream?
Do not treat them as RTMP(S) output retry settings. FFmpeg documents the commonly cited reconnect options in its HTTP protocol section, so use a protocol-specific verified method or a supervisor that launches a new publisher process after failure.
Will a restart continue the cartoon at the frame where it stopped?
Not necessarily. With a local file loop, a new FFmpeg process may begin the cartoon from its start, and viewers may see a gap. Test whether that is acceptable for your channel before relying on automatic restarts.
Why does FFmpeg keep restarting without restoring the broadcast?
A retry loop can make another attempt, but it cannot correct an invalid key or URL, a missing file, unsupported encoder settings, or persistent network loss. Read the FFmpeg log and check YouTube Live Control Room stream health to identify which problem remains.
Should I use a shell loop or a service manager?
A shell loop is a straightforward wrapper for a limited setup, but you must plan its logs, backoff, shutdown signals and normal completion. A service manager is generally easier for persistent operation and boot-time recovery, provided you configure its restart behaviour and secret handling carefully.