A continuous YouTube stream can recover from some interruptions in its HTTP input, but FFmpeg’s HTTP reconnect options do not automatically restore every dropped YouTube publishing connection. First identify whether the failure happened while FFmpeg was reading the source or while it was sending the stream to YouTube.
For an HTTP live source, you can configure reconnect behaviour before the input URL and give retries sensible limits. If the output to YouTube is the part that failed, inspect that publishing path separately rather than adding HTTP flags and assuming the problem is solved.
Identify which side of the pipeline dropped
A typical FFmpeg stream has two network-facing sides:
HTTP source or file → FFmpeg → RTMP publishing output → YouTube
The left side is the input. This might be an HTTP live stream, an HLS playlist, a downloadable file, a camera feed, or another protocol. The right side is the output, where FFmpeg publishes encoded media to YouTube’s ingestion address.
The distinction matters because an option is interpreted by the protocol handling the URL it belongs to. HTTP reconnect settings are for an HTTP input. They are not a general-purpose switch for every network connection made by FFmpeg.
Look at the first meaningful error in the log. Messages about an HTTP response, a broken HTTP connection, an input EOF, or a failure reading the source point towards the input side. Messages about writing packets, an RTMP handshake, a socket write, a broken pipe, or a publishing connection point towards the output side.
An input interruption may leave FFmpeg running while it waits or retries. An output interruption may cause the process to stop writing altogether, even though the source is still available. These can look similar in a YouTube dashboard, where the visible symptom is simply that the broadcast has stopped receiving data.
If you are still choosing a way to operate the channel, the comparison in YouTube 24/7 streaming service vs self-hosting with OBS is useful background. It does not replace checking the exact failure, but it helps separate a local process problem from a hosted one.
What FFmpeg HTTP reconnect options control
The FFmpeg Project documents these controls in its HTTP protocol reference. They affect how FFmpeg handles the HTTP input, not how YouTube accepts the published stream.
-reconnect 1 enables automatic reconnection after a disconnection before EOF. It is useful when a live HTTP source drops while it is still expected to continue. It does not turn a finite video file into an endless loop.
-reconnect_at_eof 1 treats EOF as an error that can trigger reconnection. The FFmpeg documentation describes this as useful for live or endless streams. This is different from normal end-of-file handling for a completed file, where reaching the end is expected behaviour.
-reconnect_streamed 1 enables reconnect behaviour for streamed or non-seekable HTTP inputs. Many live HTTP sources do not behave like ordinary files that FFmpeg can seek backwards through, so this setting can be relevant when the source is a live stream.
-reconnect_on_network_error 1 asks FFmpeg to reconnect for TCP or TLS errors during connection. Use it when those errors are a plausible part of the source’s failure mode. It is not a cure for a wrong URL, a rejected credential, or a source that has been permanently removed.
-reconnect_on_http_error accepts a comma-separated list of HTTP status codes. It can also accept groups such as 4xx and 5xx, according to the protocol documentation. A broad group may retry errors that will not improve with waiting, such as a persistent authentication or authorisation problem, so choose the policy deliberately.
The delay and retry controls determine how long FFmpeg continues trying:
| Option | What it controls | Practical question |
|---|---|---|
reconnect_delay_max |
Maximum delay before another reconnect attempt is abandoned | How long should one retry wait at most? |
reconnect_max_retries |
Maximum number of retry attempts | How many attempts are acceptable? |
reconnect_delay_total_max |
Maximum total reconnect delay | How long should the source be unavailable before this input gives up? |
respect_retry_after |
Whether a server’s Retry-After response is honoured instead of using exponential backoff |
Should the source service’s requested wait take priority? |
The current FFmpeg protocol reference leaves the default for reconnect_max_retries unset. Do not assume that an unmentioned option gives you the retry duration or retry count you want. Check the documentation for the FFmpeg build installed on the machine where the command will run.
These controls are a policy, not a guarantee. The source may remain unavailable, return a permanent error, require authentication, or behave differently from the protocol assumptions. A process that retries for a while is not necessarily a process that will keep a YouTube broadcast alive indefinitely.
Use the HTTP-source starting pattern
For an HTTP live source, this is a documentation-based starting pattern:
ffmpeg -reconnect 1 -reconnect_streamed 1 -reconnect_at_eof 1 \
-reconnect_delay_max 10 \
-i 'https://example.invalid/live.m3u8' \
-c copy -f flv 'rtmp://a.rtmp.youtube.com/live2/REDACTED_STREAM_KEY'
The source URL and the YouTube URL are placeholders. Keep the stream key redacted in scripts shared with other people, articles, screenshots, support tickets, and logs. Treat a real key as a credential and rotate it through YouTube if it has been exposed.
The input options appear before the -i input they configure. That placement makes the intended scope clear and avoids assuming that an option written elsewhere will affect the URL you expect. In this example, the reconnect flags describe the HTTP source URL.
-c copy means FFmpeg attempts to pass the source’s existing audio and video through without re-encoding. That can reduce processing work, but it only works when the source codecs and the FLV output are compatible. If the source cannot be copied into the selected output, you may need to choose codecs and encoding settings that match the YouTube setup.
The example uses -f flv because the output URL is an RTMP publishing destination. The format choice does not turn the HTTP input options into RTMP output recovery controls. It simply tells FFmpeg which output container or muxer to use for that destination.
This is an illustrative pattern, not a tested universal command. The source protocol, playlist behaviour, codecs, FFmpeg build, output format, network path, and YouTube live configuration all matter. Confirm support locally with commands such as:
ffmpeg -protocols
ffmpeg -h protocol=http
ffmpeg -version
The exact help output can differ by build. The FFmpeg command-line documentation notes that FFmpeg is under continuous development and that code may have changed since the documentation was written. Read the output from the installed build rather than copying a flag from an older tutorial without checking it.
If your source is a finite collection of recorded tutorials rather than a live HTTP feed, reconnect options are the wrong tool for repeating the content. The workflow in how to create a 24/7 homework help stream from recorded tutorials addresses that different problem.
What those options do not fix
HTTP reconnect settings do not apply to every input protocol. Do not use them as if they automatically cover RTSP cameras, local files, capture devices, named pipes, or other sources. Each protocol and input type has its own behaviour, and some may require a different process design or a restart policy outside these HTTP options.
They also do not make a finite file loop forever. If FFmpeg reaches the natural end of an ordinary file, -reconnect 1 is not a playlist manager. Repeating files requires a loop, a playlist, or another explicit media-rotation method, and that introduces separate questions about transitions and output continuity.
They do not repair a bad source URL, expired access token, invalid certificate, missing permission, or an HTTP status that will remain the same on every attempt. Retrying a permanent error only delays the point at which you need to correct the source configuration.
They do not prove that the source resumes at exactly the interrupted frame. A reconnect may begin at a later playlist segment or another point determined by the source and protocol. If precise continuity matters, inspect the source’s documented behaviour rather than promising frame-level recovery.
Most importantly, they do not automatically restore a dropped RTMP publishing connection to YouTube. The flags above are HTTP input controls. If FFmpeg cannot write to the RTMP destination, investigate output handling, destination settings, and the process supervisor separately.
Diagnose a dropped YouTube publishing output
YouTube’s LiveStreams documentation describes the ingestion information used to send video to YouTube and provides the relevant protocol context. Use the current YouTube instructions when checking the destination address, stream configuration, and publishing credentials.
Start by confirming that the source is still producing media. If the input continues to advance but FFmpeg reports a write or RTMP error, the source reconnect settings are not addressing the immediate failure. Check the publishing URL, the stream key, the selected YouTube live event or stream, and whether the network path from the FFmpeg machine can reach the destination.
A destination or setup mismatch is not something retries can repair. An invalid address, expired or replaced key, incorrect event configuration, or unsuitable output format will continue to fail until the configuration is corrected. Retrying such a command can create a noisy log without improving the broadcast.
FFmpeg documents output handling separately from the HTTP protocol. Its FIFO muxer documentation includes recovery-related controls for certain temporary output failures. Read the FFmpeg output and FIFO muxer documentation before considering that mechanism, and test it with your actual output path.
Do not present FIFO recovery as a guaranteed YouTube session-resumption feature. It may help with particular temporary write failures, but the documentation does not establish that every YouTube live session will resume at the same point or remain available after every publishing interruption.
There is also a process-level question. If FFmpeg exits, something must decide whether to start it again, with what delay, and with which safeguards against a rapid restart loop. If FFmpeg remains alive but the output is stalled, a supervisor that only checks whether the process exists may not notice the problem. Monitoring should consider useful output activity, not just process presence.
For a channel that depends on a local computer running all night, the practical failure surface includes power cuts, sleep settings, changing networks, and updates. The advice in how to keep a YouTube 24/7 stream running during load shedding in India covers the operational side of that problem. It does not replace an FFmpeg diagnosis, but it may reveal why a technically correct command still stops overnight.
Verify input and output health separately
Test the source on its own before testing the complete publishing command. You want to know whether the HTTP URL can be opened, whether it continues to deliver data, and what happens when the source is interrupted. Record the protocol, response status, and any authentication requirement.
Then test the output path with a known-good short input or a controlled test source. This separates source instability from output configuration. A command that fails only when publishing is enabled points you towards the destination, encoding, muxing, or network path rather than the HTTP input.
During a live run, track at least these two questions:
| Check | Evidence to look for | Likely area if it fails |
|---|---|---|
| Is FFmpeg receiving input? | Input timestamps, packets, playlist reads, or source reconnect messages continue | HTTP source or another input protocol |
| Is FFmpeg writing output? | Output timestamps and packet counts advance without write errors | Encoder, muxer, network, or YouTube destination |
YouTube’s dashboard can show that incoming data has stopped, but it may not tell you whether the source stopped, FFmpeg stopped reading, or the publishing socket failed. Compare the dashboard with the local FFmpeg log and the input and output lines printed by the process.
Do not change several retry settings at once. First reproduce the failure if you can, note the exact error, and alter the smallest relevant part. If you change the input delay, retry count, output handling, encoder settings, and network at the same time, you lose the evidence needed to know which change mattered.
If the channel is built around a local low-power device, test its sustained workload rather than assuming that a command that starts successfully will run overnight. The discussion of whether a Raspberry Pi can stream 1080p video to YouTube 24/7 can help frame the hardware questions, but your actual input, output and encoding settings remain decisive.
Review logs before changing retry settings
Run FFmpeg with enough logging to capture the first failure, while avoiding accidental exposure of the stream key. A log should show whether the source returned an HTTP response, whether EOF was encountered, whether a network error occurred, and whether the output failed during connection or writing.
Look for the sequence rather than one isolated line. For example, an HTTP disconnect followed by reconnect attempts suggests an input event. A source that continues producing timestamps while the output reports a broken pipe suggests a publishing event. An immediate HTTP authorisation error suggests configuration rather than a temporary outage.
Save the command and relevant log lines with credentials removed. Replace the key, signed query parameters, cookies, and private URLs before sending the material to someone else. A technically useful log is still unsafe if it contains a credential that can publish to your channel.
Compare the installed help output with the options you intend to use. If FFmpeg reports an unknown option, rejects its value, or applies an option to a different URL than expected, stop and resolve that mismatch before tuning retry behaviour. A copied command is not evidence that your local build supports every part of it.
Choose retry bounds with the source’s behaviour in mind. A short maximum delay may give up quickly during a brief outage. A long or unbounded policy may leave a process running while no useful media reaches the output. A retry count or total-delay limit gives you a defined point at which an external monitor or operator can intervene.
The right result is not the most aggressive command. It is a command whose recovery scope, retry policy, and failure signal you understand. If maintaining the machine, process supervisor, credentials, and output diagnosis is more work than your channel warrants, StreamNeo removes the need to keep a local FFmpeg process running by taking an uploaded video, your YouTube stream key, and the always-on broadcast into one monitored workflow.
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 HTTP reconnect options reconnect YouTube’s RTMP output?
No. They configure the HTTP input side of the command. A dropped RTMP publishing connection needs separate output diagnosis and may require output recovery controls or a process restart policy.
Should I use reconnect_at_eof for every source?
No. It is intended for cases where EOF should be treated as an error, such as a live or endless HTTP source. It is not a general way to loop a completed local file, and it may be unsuitable when EOF correctly means that the source has finished.
Why does my command retry but the YouTube stream still stop?
The source may be retrying while the publishing output has failed, or the source may be returning a permanent error. Check the FFmpeg log to establish whether input reads or output writes stopped, then verify the YouTube ingestion address, key, stream setup and output format.
Do these flags work for RTSP or a camera input?
Do not assume so. These are HTTP protocol options, and other input protocols have different connection and recovery behaviour. Check the documentation and help output for the protocol actually used by your source.