If FFmpeg keeps reconnecting during a YouTube Live stream, first find out whether it is losing the source it reads or the YouTube destination it publishes to. The remedy depends on that connection: FFmpeg’s documented reconnect options discussed here are for HTTP inputs, not a universal fix for publishing failures.
Start with the complete log around a disconnect, the protocols used by the input and output, and YouTube Live Control Room’s stream-health messages. Until you have those clues, changing flags is guesswork; a title or symptom alone cannot identify the fault.
Identify which connection is reconnecting
FFmpeg usually has two distinct connections in a streaming command. The input connection brings media into FFmpeg, perhaps from an HTTP URL or a local file. The output connection sends the encoded stream to YouTube’s ingest destination. A message about reading, opening or receiving data may point to the input; a message about writing, sending or connecting to the destination may point to output. Treat those words as clues, not a diagnosis by themselves: inspect the complete log and identify the URL or protocol mentioned in the lines before and after the reconnect.
Capture the command and evidence before changing it. Record the FFmpeg version and build, the command with the stream key and any other credentials removed, the input and output protocols, and several log lines on both sides of the event. Note the time of each disconnect and compare it with Live Control Room’s stream-health messages. If you share logs for help, redact secrets first. A stream key is a credential, not a harmless command-line detail.
The difference matters because the documented FFmpeg reconnect controls below apply to HTTP protocol behaviour. They do not establish how an RTMP or RTMPS publishing connection should retry, and adding them to a publishing command does not show that the output fault has been fixed. If the source is a playlist or radio feed, the input may deserve close attention; for the relationship between a dropped internet connection and a broadcast restart, see how to reconnect a YouTube radio stream after an internet drop.
A useful first question is: which endpoint failed at the time shown in the log? If FFmpeg is still reading the source while output messages fail, investigate publishing. If output remains connected but reading fails, investigate the source. If the log is ambiguous, keep both possibilities open rather than assuming that every message saying “reconnecting” refers to YouTube.
Check whether the input uses HTTP
Before considering an HTTP reconnect option, establish the input protocol. Look at the URL scheme or the protocol shown in FFmpeg’s output: an http:// or https:// source is different from a local file, RTMP source, device input or other protocol. A command may contain an HTTP input and an RTMPS output at the same time. The presence of HTTP anywhere in the command does not make an HTTP input flag relevant to the output connection.
If you are unsure which options your installed build supports, check its own help with ffmpeg -h protocol=http. FFmpeg’s protocol documentation describes the HTTP options and their scope. Builds and versions can differ, so use that local help rather than copying a flag from an old command or assuming an option has the same default everywhere.
Look for evidence of an input-side failure: a failed read from the source, a source URL that stops responding, a connection error associated with that URL, or an unexpected end of input. Then verify the source itself. Check that the address is still valid, that authentication has not expired, and that the source is expected to remain available. A retry setting cannot repair a mistyped URL, rejected credentials, or a source that has gone offline.
An end-of-file message also needs context. A finite file normally reaches EOF when it is finished; a live or endless HTTP feed may need different end-of-input handling. Decide whether EOF means “the programme is complete” or “this live source dropped unexpectedly” before asking FFmpeg to reconnect. Automatically treating every EOF as an error can make a completed item repeat or leave a process retrying without producing useful media.
Use HTTP reconnect options only when applicable
FFmpeg documents several HTTP options because different failures call for different retry behaviour. They are not a single switch that makes every connection resilient. Choose only after the log points to an HTTP input and the observed condition matches the option’s purpose.
| Option | What it addresses | Check before using it |
|---|---|---|
reconnect |
Reconnect when an HTTP connection is disconnected before EOF. | Is the source expected to continue, and does the log show a disconnect rather than normal completion? |
reconnect_at_eof |
Treat EOF as an error and reconnect; intended for live or endless streams. | Is EOF unexpected for this input, rather than the normal end of a finite file? |
reconnect_on_network_error |
Retry on TCP or TLS errors during connection establishment. | Does the failure happen while establishing the HTTP connection? |
reconnect_on_http_error |
Retry on selected HTTP status codes, including code categories such as 4xx or 5xx. |
What response code appears, and is retrying it appropriate? |
reconnect_streamed |
Allow reconnects for streamed or non-seekable HTTP inputs. | Is the source streamed or non-seekable, and does the failure match? |
reconnect_delay_max, reconnect_max_retries, reconnect_delay_total_max |
Limit retry delay, attempt count or total retry time. | How long should the workflow wait before stopping and reporting a fault? |
These options control different triggers and boundaries. For example, an HTTP error response is not the same as a TCP connection error, and an unexpected EOF is not the same as a normal end to a recorded file. Setting several options without identifying the event can obscure the reason the source failed. It can also keep a process alive while the stream has no usable media.
The maximum reconnect delay and retry defaults cited in some examples are version-specific. FFmpeg 8.1’s HTTP source documentation shows a 120-second maximum reconnect delay and an unlimited retry default represented as -1; do not assume those values apply to your installed build. Inspect local protocol help and set bounds that fit your operation. A channel expected to run overnight should not silently retry forever against a permanently unavailable source without an alert or a recovery plan.
If you are using a playlist or a local file loop, distinguish the playlist or file handling from network recovery. A source can end normally, while the publishing side remains healthy; a remote source can fail while the output is still connected. For a broader comparison of ways to keep a playlist stream running, see Raspberry Pi 5 versus VPS for a 24/7 FFmpeg YouTube playlist stream. The right choice depends on where the failure occurs, not on which command has the most retry flags.
Inspect publishing-side output logs
If the output connection to YouTube is the one failing, leave the HTTP input options aside unless you have separate evidence of an HTTP input problem. Inspect the output URL, its protocol, and the lines FFmpeg prints as it tries to connect or write. Look for the point where the destination is named, whether a connection was established, and whether the fault is a timeout, an SSL/TLS error, a rejected connection, or a later write failure. The exact meaning depends on the message and build; do not infer a cause from “reconnecting” alone.
In Live Control Room, confirm the current stream URL and stream key, then check that both are present in the encoder configuration. Do not paste the key into a public issue or article comment. If the key was exposed in a log or screenshot, replace it in YouTube’s controls rather than relying on deletion of the posted copy. YouTube’s live encoder setup guidance describes setting up an encoder connection; use the current values shown in your own Live Control Room rather than copying an ingest address from an old example.
YouTube recommends RTMPS, the secure extension to RTMP. If logs show a timeout or SSL error, verify that the configured server URL and protocol match the current destination shown in Live Control Room. For the specific invalid-certificate SSL error, YouTube’s RTMPS guidance also says to check the server URL and protocol and, where appropriate, try port 443. Do not substitute an example hostname for the actual endpoint provided for your stream.
A publishing failure may have several causes, including a stale destination, an incorrect key, network conditions or a problem indicated by the service’s stream-health view. The supplied FFmpeg HTTP documentation does not define RTMP or RTMPS publishing retry controls, so this article cannot prescribe an output retry flag on that evidence. Work from the output log and YouTube’s current guidance, and avoid treating a change to an unrelated input option as a confirmed remedy.
Check network and ingest details
A connection can be configured correctly and still fail over an unreliable network path. Check whether the upload connection drops at the same time as FFmpeg’s output errors, whether other devices or services lose connectivity, and whether the stream is being sent over a stable connection. YouTube recommends an upload speed test and testing with representative audio and motion before an event. A speed test is useful evidence, but it is not proof that the connection will remain stable throughout a long broadcast.
Open YouTube Live Control Room’s stream-health panel and note its messages and timing. YouTube’s stream-health troubleshooting guidance explains the health messages and checks to make. Compare those messages with the FFmpeg timestamps: a YouTube warning may clarify that the incoming stream is missing data or has a configuration issue, while FFmpeg can show whether it failed to read or write. Neither view alone necessarily explains the whole path.
Check the encoder settings against YouTube’s current recommendations, but keep transport and media configuration distinct. YouTube recommends constant bitrate (CBR) and a keyframe interval of two seconds, not over four seconds. Those are encoder settings, not a guarantee against network disconnections. Also verify that the selected protocol and codec combination is supported for the intended stream. If the health panel points to a quality or encoding issue, correct that; if the output log points to a connection break, continue investigating the endpoint and network.
For a small channel running from a home or shop, a wired connection can be a practical way to test whether Wi-Fi instability is involved, but buying a cable is not a diagnosis and cannot fix an incorrect key or an unavailable source. If you test a different network path, change only that path and record what happens. The cost and effort of keeping a dedicated computer on all night also belong in the decision: a comparison of 24/7 streaming power draw on gaming and office PCs can help you assess the operating trade-off, but it will not diagnose a particular reconnect.
Test one change at a time
Once you have a likely failing leg, make one relevant change and observe the result. Save the original command, redact credentials in your notes, and note the time and symptom before editing. If the failure is an HTTP input read, change the HTTP option that matches that read failure. If it is an output timeout, test the output endpoint or network condition suggested by the logs instead of adding HTTP input flags. When several settings change together, it becomes harder to tell which mattered.
Test with representative media and the intended output settings before relying on the setup for an overnight or scheduled broadcast. Keep the observation long enough to cover the conditions under which the problem normally appears; a short successful connection does not establish that a channel will stay connected for a full night. Watch both FFmpeg’s log and Live Control Room while testing, and record whether the same error returns, changes, or disappears.
Set retry behaviour with a stopping point where the protocol supports it. Unbounded retries may be appropriate for a workflow designed to wait for a source to return, but they can also conceal a permanent fault and leave viewers with a broken or empty stream. Decide who or what will notice the failure, how long you are willing to wait, and what action follows. For an always-on channel, a quiet process that is still running is not the same as a healthy broadcast.
If the exact cause remains unclear, preserve the evidence rather than accumulating flags. The details needed for a useful diagnosis are the FFmpeg version and build, a command with secrets removed, input and output protocols, log lines around the disconnect, upload conditions, and Live Control Room’s stream-health messages. Without them, any specific fix would be a guess.
Confirm the stream stays connected
After a change, confirm that the source is being read and the output is being published, not merely that FFmpeg remains open. Check that the relevant log errors stop recurring, that YouTube shows the stream as receiving data, and that the preview and stream-health messages agree with what you expect. If the process reconnects but the destination does not receive usable media, the original problem has not been resolved.
Observe the channel under the conditions that have caused trouble: the same source, network, encoder settings and schedule. Note whether reconnects happen at a predictable point, such as when a source ends, or at irregular times that align with network or service messages. A repeatable EOF may call for a source workflow change; an intermittent output timeout calls for a different investigation. Keep timestamps so that later log review is useful rather than relying on memory.
For an always-on operation, plan what happens when the machine, source, network or publishing process fails. A local FFmpeg workflow gives you control over the command and logs, but it also means you are responsible for the machine staying on, its network path, and noticing a stopped or degraded stream. If the burden you are trying to remove is keeping a computer running and restarting a file-based broadcast after a drop, StreamNeo takes an uploaded video and runs it as a YouTube live stream without your computer staying on, with monitoring and automatic restarts if it drops; it is YouTube-only, so it does not replace a source-specific FFmpeg workflow or diagnose every ingest fault.
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
Should I add -reconnect 1 to stop YouTube disconnects?
Not as a general fix. The documented FFmpeg reconnect options discussed here are HTTP protocol options, and apply when an HTTP input is failing in a way the selected option covers. First identify whether the failure is on the input or publishing output and match any option to the log evidence.
How can I tell whether FFmpeg is reconnecting to its source or YouTube?
Inspect the complete log around the event and identify the affected URL or protocol, looking for a read/input failure versus a write/output failure. Compare its timestamp with YouTube Live Control Room’s stream-health messages. If the log does not clearly identify the leg, retain the command with credentials redacted and gather more evidence before changing flags.
Does reconnect_at_eof make a stream loop forever?
It tells FFmpeg to treat EOF as an error and reconnect for an HTTP input; it does not by itself make every kind of input loop or guarantee a working stream. It is intended for live or endless sources, so using it on a finite file that has completed may create unwanted retries. Check your build’s HTTP help and decide whether EOF is genuinely unexpected for that source.
What information should I share when asking for help?
Include the FFmpeg version and build, the command with the stream key and other credentials removed, the input and output protocols, and several log lines before and after the reconnect. Add the upload conditions and the corresponding Live Control Room stream-health message. Those details can distinguish an HTTP source problem from a YouTube publishing problem.