When a 24/7 children’s stream drops after an internet interruption, first find out whether FFmpeg stopped receiving the video or stopped publishing it to YouTube. HTTP input reconnect settings and RTMP output recovery work at different points, so neither is a universal reconnect switch.
The right configuration depends on the input type, output type, failure and installed FFmpeg build. Use the examples below as starting points, then test the exact command and inspect its logs; none guarantees an uninterrupted broadcast or viewer playback without a gap.
Identify where FFmpeg stops
Think of the FFmpeg job as a path: it reads a source, processes or copies the streams, then writes to a destination. If it cannot read the source, the problem is on the input side. If it continues receiving and processing media but cannot write to YouTube, it is on the publishing side. A whole process that exits may also need a supervisor to restart it; that is distinct from protocol-level retries within a running FFmpeg process.
Begin with the log around the time of the drop. Look for the last successful input or output activity and the error that followed. A read error, closed HTTP connection or input reaching EOF points towards the source side. An RTMP connection or write error points towards publishing. If the process has exited, note its exit status and whether a separate service manager restarts it. Do not infer the cause solely from the stream appearing offline in YouTube Studio: that tells you the result, not which link failed first.
A useful way to narrow it down is to run the same input in a short test without the YouTube output, or send a known-good local input to the output in a controlled test. Change one part at a time and retain the log. For a playlist, also check whether the next file is readable and whether the playlist itself continues; FFmpeg cannot reconnect to a source that has ended normally unless the chosen input and command are meant to keep going. If your setup uses OBS rather than a direct FFmpeg command, why OBS may skip files in a cartoon playlist may help distinguish a playlist issue from a network drop.
Record the input URL or source type, output protocol, exact command, FFmpeg version and relevant log lines. Remove stream keys and other credentials before sharing logs. That basic evidence prevents a common mistake: adding HTTP input options to a command whose actual failure is an RTMP write, or adding output recovery when the source has gone away.
Check whether the input is HTTP or another source
FFmpeg’s HTTP reconnect options apply to HTTP input. They are not general-purpose options for a local file, a camera device, a pipe, or every other protocol. Check the command’s -i value and the protocol FFmpeg reports in its log. A URL beginning with http:// or https:// is a clue, but the log and the installed build’s documentation are the better confirmation when an input is indirect or wrapped.
A local video file normally reaches EOF when playback ends. Adding network retry flags will not make a playlist repeat by itself. You need a looping or playlist design appropriate to the source. For recurring file rotation on a Linux host, see how to rotate video playlists with cron. Cron or a playlist can start or sequence work, but it does not repair an unavailable HTTP source or an output connection.
Likewise, a camera or capture device may fail because it is disconnected, unavailable to the operating system or locked by another process. A reconnect option for HTTP does not reopen that device. First establish whether the source is still available and whether FFmpeg remains alive. If the input is a live HTTP feed, reconnect options may be relevant; if it is a local playlist, focus on playback logic; if it is another network protocol, look up that protocol’s own options in the documentation.
Keep the input and output diagnosis separate even when the same household internet connection carries both. A broadband outage can interrupt both, but each endpoint can recover differently. In a test, note whether the source resumes first, whether FFmpeg resumes reading, and whether the destination accepts writes. That sequence tells you which recovery mechanism is worth configuring.
Use HTTP reconnect options for input failures
The FFmpeg HTTP protocol documentation describes several reconnect options with different purposes. For a dropped connection before the input reaches EOF, -reconnect 1 asks FFmpeg to retry. Some live or endless HTTP feeds close in a way that looks like end-of-file; -reconnect_at_eof 1 treats EOF as an error and attempts a reconnect. For streamed or non-seekable inputs, -reconnect_streamed 1 allows reconnection attempts on errors.
These switches are not interchangeable in every situation. The distinction matters: EOF can be a normal end for a finite file, while on an endless live feed it may be a sign the connection was interrupted. Use reconnect_at_eof only when retrying after EOF fits the source’s expected behaviour. Otherwise, a finite asset that ends as intended could be opened again instead of remaining finished.
For example, an HTTP live input might be tested with this pattern:
ffmpeg \
-reconnect 1 \
-reconnect_streamed 1 \
-reconnect_at_eof 1 \
-i "https://example.invalid/live.m3u8" \
-c copy \
-f flv "rtmp://example.invalid/live/STREAM_KEY"
The addresses are placeholders, not working services. The HTTP options appear before the relevant -i, so they apply to that input. -c copy is only an example choice; it works only when the incoming codecs and container are acceptable to the output. You may need different processing, stream mapping or output settings. Do not paste this as a complete production command without adapting it to your feed and destination.
Other HTTP options can target narrower failure classes. -reconnect_on_network_error 1 is for TCP or TLS errors while connecting. -reconnect_on_http_error lets you name status codes or classes such as 4xx or 5xx; consider which responses genuinely represent temporary failure for your source. Repeatedly retrying an authentication error, missing resource or other permanent response may only obscure the cause. Keep credentials and provider-specific access rules in mind.
The documentation also lists controls to bound retries: -reconnect_delay_max caps the wait between attempts, -reconnect_max_retries limits attempts, and -reconnect_delay_total_max limits total delay. Whether to cap retries depends on operations. A finite retry policy can make a fault visible rather than waiting indefinitely; an always-on channel may instead need the process supervisor or operator to keep trying and alert someone. Choose intentionally, not by copying a long set of flags without knowing what each one controls.
Consider FIFO recovery for RTMP output outages
If FFmpeg is still reading its input but cannot publish to YouTube over RTMP, HTTP input reconnect flags will not recover the output. FFmpeg documents a separate FIFO muxer pattern for RTMP recovery in its all-components documentation. FIFO wraps the output path; recovery options such as -attempt_recovery 1 and -recovery_wait_time tell it to attempt recovery after an unsuccessful write or connection attempt.
The documented example is:
ffmpeg -re -i INPUT \
-c:v libx264 -c:a aac \
-f fifo -fifo_format flv \
-drop_pkts_on_overflow 1 \
-attempt_recovery 1 -recovery_wait_time 1 \
-map 0:v -map 0:a \
rtmp://example.com/live/stream_name
Treat INPUT, the RTMP address, maps and codec choices as placeholders. This example re-encodes video and audio; it is not automatically appropriate for every source or host. Re-encoding costs processing capacity, while stream-copy settings may be preferable when the source codecs already suit the destination. Test with the actual media and verify that both audio and video are mapped as intended.
FIFO introduces buffering behaviour that you need to understand. If the output cannot keep up, queued data can accumulate; overflow handling affects what happens to packets. The example’s -drop_pkts_on_overflow 1 is a choice in that context, not a promise of seamless continuity. Buffering can also affect latency, so confirm what viewers see after a recovery and whether audio remains in sync. Read the FIFO options in the installed version’s documentation before adopting the example.
The example sets a one-second recovery wait. FFmpeg documents a five-second default for recovery_wait_time; those are documented settings, not a recommendation that suits every network. The wait controls when another attempt follows an unsuccessful attempt. A shorter wait may make more frequent attempts, while a longer one reduces their frequency but leaves the output waiting longer. Choose based on observed outage behaviour and test what happens when the destination is deliberately unavailable.
FFmpeg also documents recover_any_error, which broadens retries to error types that may normally be permanent. Do not enable it reflexively. Retrying an error that requires a changed URL, renewed credentials or a corrected command will not fix the underlying problem. Recovery is an attempt to resume writing, not proof that YouTube accepted every packet or that viewers saw no interruption.
Match retry options to the observed failure
Use the smallest recovery mechanism that matches what the logs show. The table is a diagnostic aid, not a guarantee that a given flag will solve the fault. Confirm exact syntax and support locally before use.
| What the log or test indicates | Relevant area | Options or action to investigate |
|---|---|---|
| HTTP connection ends before EOF | HTTP input | -reconnect 1; consider a retry limit and delay cap |
| HTTP live feed reports EOF unexpectedly | HTTP input | -reconnect_at_eof 1, if EOF should mean the live feed may return |
| HTTP streamed/non-seekable source errors | HTTP input | -reconnect_streamed 1 |
| TCP/TLS connection attempt fails | HTTP input | -reconnect_on_network_error 1 |
| HTTP server returns a status error | HTTP input | -reconnect_on_http_error for chosen codes/classes, only if retry is sensible |
| Input reads normally, RTMP writing fails temporarily | RTMP output | FIFO muxer with recovery options such as -attempt_recovery 1 |
| FFmpeg exits rather than remaining active | Process lifecycle | Inspect exit cause; consider a service supervisor separately |
| Local file or playlist ends normally | Playback logic | Configure looping or playlist sequencing, not HTTP retries |
An internet loss at the publishing location can break the route to YouTube while a source file on disk remains perfectly readable. Conversely, a remote HTTP source can be unavailable while the network path to YouTube is fine. Logs may show both errors during a longer outage, so inspect their order and test each endpoint independently when possible.
Retry policy is an operational decision. A kids’ channel may use a pre-recorded loop, a live feed or a mixture; each has different consequences if it stops. Decide who will notice a prolonged outage, whether the process should keep retrying, and what evidence should trigger manual intervention. Do not conceal persistent errors by retrying forever if no one checks alerts or logs. For a broader view of keeping a radio-style broadcast online overnight, the overnight YouTube livestream troubleshooting guide covers operational checks that sit alongside FFmpeg configuration.
Once settings are selected, simulate a short interruption in a controlled test rather than waiting for a real overnight failure. Confirm that the process remains alive, the input resumes if it was interrupted, the RTMP output reconnects if that was interrupted, and the stream is visible again in YouTube Studio. Review both FFmpeg logs and the viewer-facing result. A recovery message in a log alone does not establish that the broadcast has returned cleanly.
Check options against the installed FFmpeg version
Online FFmpeg documentation follows the newest revision. The project’s documentation index advises readers using an older version to consult the documentation installed locally. That matters on a VPS, desktop machine or prebuilt host where the binary may lag behind the current online page. An option shown online may not be available or may differ in the build you actually run.
Check the executable used by the service, not merely the one in your interactive shell. A scheduled task or service may have a different path or environment. Record its version with ffmpeg -version, then inspect local help or documentation for the relevant HTTP protocol and FIFO muxer options. If a command reports an unrecognised option, verify spelling, version and option placement instead of adding unrelated flags.
For HTTP input, options belong before the corresponding -i; options after the input can apply elsewhere or be rejected depending on the option and command structure. For FIFO output, the muxer settings belong in the output portion of the command. A small test command makes placement errors easier to find than changing a long production command all at once.
Keep a known-good copy of the current command before editing it. Change one setting at a time, save the resulting log, and note the effect. This is particularly useful when a command is managed by a script or service unit: editing the wrong copy can make a test appear successful while the always-on job continues with old settings. Redact stream keys before storing or sharing command output.
If you would rather not maintain an FFmpeg process on a computer that must stay powered and online, StreamNeo removes that specific burden by turning an uploaded video into a YouTube live stream that runs with your computer off. It does not change the fact that you should verify the file and channel before depending on a broadcast.
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 HTTP reconnect flags reconnect an RTMP output?
No. Those options address FFmpeg reading an HTTP input. For a temporary RTMP publishing failure, investigate the FIFO muxer recovery pattern separately and verify it against your installed build.
Should I enable every reconnect option for a 24/7 stream?
No. Each option targets a particular failure condition, and some retries can hide a permanent problem such as a bad URL or access error. Match settings to the logs, decide how retries should be bounded, and test the behaviour.
Will FIFO recovery guarantee that viewers see no interruption?
No. It enables attempts to recover an output after a failure, but the documentation does not promise uninterrupted viewer playback. Test the output and review both logs and the visible stream after a controlled outage.
What if FFmpeg exits completely after the connection drops?
Protocol reconnect options operate within a running FFmpeg process; they do not themselves restart a process that has terminated. Find why it exited, then decide whether a separate process supervisor should restart it and how someone will be alerted to repeated failures.