FFmpeg’s reconnect options in its protocol documentation apply to HTTP connections, usually an HTTP input. They do not, by themselves, reconnect an RTMP output to YouTube when publishing is interrupted.
For YouTube, use the current server URL and stream key shown in Live Control Room, then plan separately for an FFmpeg process failure or a broken publishing connection. Keep HTTP reconnect flags with an HTTP input, and verify the behaviour of your installed FFmpeg build rather than relying on a generic command copied from elsewhere.
What FFmpeg reconnect options apply to
FFmpeg documents protocols separately, and that distinction matters more than where a flag happens to appear in an example. The reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error and reconnect_streamed options belong to the HTTP protocol. They describe how FFmpeg handles an HTTP connection, not a universal retry policy for every input or output protocol.
The HTTP options cover different conditions. reconnect asks FFmpeg to reconnect after a disconnection before the input reaches its end. reconnect_at_eof treats end-of-file as an error and attempts to reconnect, which can suit an intended endless source. reconnect_on_network_error relates to connection-level TCP or TLS errors, while reconnect_on_http_error allows selected HTTP status codes to trigger retries. The latter accepts individual codes and groups such as 4xx or 5xx in the documented syntax.
Other HTTP settings shape retry limits and timing. reconnect_delay_max caps the delay before giving up, reconnect_max_retries limits attempts, and reconnect_delay_total_max limits the total retry delay. respect_retry_after concerns an HTTP Retry-After header. Check the FFmpeg protocol documentation for the options supported by the release you use.
These names may look like general-purpose FFmpeg controls, but their protocol scope is decisive. A flag can be recognised in an HTTP context without controlling a separately configured RTMP publisher. If the input is a local file and the output is YouTube RTMP, HTTP input reconnect options have no HTTP connection to manage.
Exact defaults can also vary by release and build. The current FFmpeg trunk HTTP source lists default values for some retry limits, but those implementation details are not a guarantee about your installed binary. Check ffmpeg -version, local help and documentation matching that release if a retry limit matters to your operation.
Use HTTP reconnect options for HTTP inputs
When the source itself is HTTP, place the HTTP options before the matching -i input URL. This is important because FFmpeg options are interpreted in relation to the input or output that follows them. It also makes the command easier to inspect: you can see that the retry behaviour is attached to the source rather than the YouTube destination.
For example, the following is a syntax illustration for an HTTP input:
ffmpeg -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 30 \
-i "https://example.invalid/live-source" \
-c copy -f flv "rtmp://ingest.example.invalid/app/STREAM_KEY"
The .invalid hostnames are placeholders, not working endpoints. Replace them with the HTTP source you are authorised to use and the destination details supplied for your YouTube stream. The example demonstrates option placement only; it does not demonstrate RTMP output retry. Do not publish a real stream key in a command example, screenshot, log or public repository.
Before enabling reconnect_at_eof, establish what EOF means for the source. For an endless HTTP feed, the source ending unexpectedly might be a useful signal to retry. For a finite recording, EOF is the normal end. Treating it as an error can cause FFmpeg to fetch the same finished file repeatedly, which is not the same as keeping a continuous programme running.
It also helps to distinguish a stalled source from an ended source. A finite file can complete normally, while a live feed can disconnect before its intended end. Retry settings do not decide whether replaying content is editorially acceptable, whether a source is available again, or whether a restarted input resumes from the right point. Those depend on the source and how your workflow handles it.
If your source is a playlist or a set of recordings, decide first what should happen when an item ends. A playlist may advance to the next item; an HTTP reconnect may instead retrieve the same endpoint again. For a recorded channel, the practical design questions around sequence and repetition are covered in planning a 24/7 YouTube playlist. A source retry and a content schedule solve different problems.
Why HTTP flags do not retry an RTMP output
RTMP is a separate protocol in FFmpeg’s documentation. FFmpeg’s publishing example uses an RTMP URL and an FLV output, whereas the reconnect family discussed above is documented under HTTP. Putting HTTP flags before an RTMP output URL does not convert them into a retry mechanism for that output.
This distinction answers a common question: “Do FFmpeg reconnect options work with RTMP?” Not as a general RTMP publishing retry. A command may accept some options in a particular position or build, but that alone would not establish that HTTP retry semantics control a failed RTMP connection. Consult the protocol and release documentation, and do not infer recovery behaviour from a command that happens to continue running in one circumstance.
There are at least two different failure cases to consider. The FFmpeg process can exit, for example after an error it cannot continue past. Or the process can remain present while the publishing connection fails. A process supervisor can notice an exited process and start it again, but that is not proof that every failed RTMP output will be retried while the original process remains alive. The appropriate recovery logic depends on which condition you need to detect and handle.
Neither input retries nor a process restart promises gapless continuity. If FFmpeg has to restart, viewers may see a break, and YouTube may need time to reflect the encoder’s return. A retry can also fail again if the original issue remains, such as an unreachable source, invalid key or unstable network. Treat these as separate recovery layers rather than expecting one flag to repair the whole path.
If the output uses RTMPS, that still does not make HTTP options apply to it. RTMPS concerns the transport used for publishing; the HTTP reconnect flags remain HTTP-specific. For a practical walkthrough of the distinct publishing configuration, see configuring YouTube RTMPS in FFmpeg.
Configure the current YouTube ingest workflow
YouTube’s encoder setup asks you to use the server URL and stream key associated with the stream in Live Control Room. Copy the current values into the publishing configuration you are using, and select the protocol allowed for that stream. Do not rely on an old sample’s host, path or protocol setting as if it were permanent.
The YouTube encoder settings page lists current protocol and encoding guidance. It identifies RTMP and RTMPS as streaming protocol choices and recommends RTMPS for encrypted transport. Codec, resolution and frame-rate details affect the appropriate encoding settings, so use the current table for the stream you are preparing instead of copying a generic bitrate or codec line from an unrelated command.
A safe configuration process is to open the intended stream in Live Control Room, copy the displayed server URL and key into the encoder, and verify that the selected output format and encoding match current platform guidance. Keep the key private. If it has been reset, update the encoder with the replacement value from Live Control Room; an old key in a script will not become valid merely because FFmpeg retries.
Test before a scheduled broadcast and watch the stream-health messages in Live Control Room. This checks more than whether FFmpeg launches: it gives you a chance to find an incorrect destination, key, protocol or encoding before viewers depend on the stream. A channel built around ambience or devotional playback may have a stable file source, but the ingest details still need to be current; see the practical context in streaming a bamboo forest ambience video continuously.
Check the output URL and stream key in Live Control Room
When publishing fails, verify the destination before changing retry behaviour. Compare the output URL with the server URL currently shown for the stream, and confirm that the key belongs to that stream. A typo, stale key or copied destination from another broadcast can look like a transient network issue when it is actually a configuration mismatch.
Treat a stream key as a password. Avoid embedding it in examples you share, terminal recordings or logs that are accessible to other people. If a key may have been exposed, use Live Control Room’s current controls to manage it and then update the encoder configuration. A process restart using the same exposed or obsolete key does not solve the underlying problem.
Check the status on both sides. On the FFmpeg side, note whether the process is still running and inspect its error output without posting credentials. On YouTube’s side, read the current health indicators and messages. This separates a stopped local process from a connection that is not being accepted or a stream that is connected but has an encoding or input issue.
YouTube’s guidance also points to the network path. Its streaming tips explain that connectivity disruption can break a stream and recommend leaving upload bandwidth headroom. A wired Ethernet connection can remove a weak Wi-Fi hop from the local path, but it cannot repair an ISP outage, routing problem or issue at the ingest endpoint. If a stream is regularly unstable, measure the actual connection available during broadcast conditions and investigate the relevant segment rather than adding retries blindly.
Plan recovery for an interrupted FFmpeg process
A recovery plan should specify what is expected to notice a failure, what it will restart, and how you will know that publishing has resumed. If FFmpeg exits, an operating-system process supervisor or explicit wrapper logic may be able to restart it. Configure and test that behaviour for your own environment; the HTTP protocol options do not provide it for an RTMP output.
A restart policy needs limits and visibility. Consider whether repeated failures should trigger a delay, how many attempts are sensible before an alert, and where you will inspect the reason for failure. A rapid restart loop can make logs difficult to read and can repeatedly hit the same bad configuration. A long delay can leave a channel offline for longer. There is no single retry schedule that fits every source, network and operating environment.
Also decide what a fresh FFmpeg process should do with the input. If it reads a local file from the beginning, viewers may see the opening again. If it reads a live HTTP input, input-level reconnect behaviour is a separate question. If it reads a playlist, the restart may alter where playback resumes. Document the expected content behaviour as well as the process behaviour, then test the actual failure case before depending on it overnight.
For a small VPS workflow, a terminal multiplexer can help you keep track of a manually managed process, but it is not the same as a tested automatic recovery policy. The tmux guide for keeping an FFmpeg YouTube stream alive covers session persistence; process supervision, retry conditions and alerts still need deliberate planning. If you want a pre-recorded channel without leaving your own computer running, StreamNeo removes the specific burden of keeping that computer on to sustain the broadcast, while you still need to prepare the file and YouTube channel details.
There is also a distinction between restarting the primary encoder and having a backup encoder. YouTube documents backup-encoder workflows and recommends testing failover by stopping the primary or disconnecting its Ethernet connection, then checking whether the player rolls over to the backup. That is a separate setup to validate, not a result guaranteed by FFmpeg’s HTTP flags or by restarting a single process. Review YouTube’s current backup encoder guidance before relying on it.
| Failure layer | What to check or plan | What it does not establish |
|---|---|---|
| HTTP source | Attach relevant HTTP reconnect options to that input; decide whether EOF is an error | RTMP publishing recovery |
| FFmpeg process | Arrange detection, restart limits and an alert if the process exits | Recovery from every connection failure while the process remains alive |
| RTMP or RTMPS publishing | Verify current destination, protocol and key; inspect output errors and YouTube health | A universal retry flag or gapless return |
| Local network | Check available upload capacity and connection stability | Resolution of an ISP or ingest-side fault |
| Backup encoder | Configure and test the documented failover workflow | Automatic continuity without a tested backup path |
Use the table to locate the layer that failed before changing settings. If the source is still being read but the output is rejected, changing HTTP input retries is unlikely to address the symptom. If the process has exited, an output URL check alone will not bring it back. Recovery is most useful when each layer has a clear owner and a practical test.
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 reconnect options work with RTMP output?
The reconnect options covered here are documented for HTTP, not as a general RTMP output retry mechanism. Keep them with an HTTP input where appropriate, and handle RTMP output and process recovery separately.
How do I keep FFmpeg from stopping when my stream drops?
First establish whether FFmpeg exited, the source failed, or the publishing connection failed while the process remained active. HTTP input retries can address some HTTP source failures; use an explicitly configured and tested process recovery plan for an exited process, and check the current YouTube destination and health messages for publishing problems.
Should I use reconnect_at_eof for a video file?
Usually not when EOF means the file has finished normally. That option treats EOF as an error and reconnects, which is intended for cases such as an endless HTTP source rather than ordinary completion of a finite recording.
Where do I get the current YouTube RTMP URL and key?
Get the server URL and stream key from the stream’s Live Control Room, then enter them in your encoder and keep the key private. Check YouTube’s current encoder guidance for the protocol and encoding settings relevant to the stream you are configuring.