If your relaxation stream drops, first identify whether the failure is at the input, the network output, the local file loop or the FFmpeg process itself. FFmpeg has different controls for each point: HTTP reconnect options apply to an HTTP input, FIFO recovery can retry a network output while FFmpeg is still running, and a process that exits needs an external supervisor.
A looped file is separate again: -stream_loop -1 tells FFmpeg to repeat an input, not to reconnect the publishing destination. The examples below are templates rather than tested commands; check your installed FFmpeg build, source protocol, codecs and destination requirements before relying on them.
Identify where the stream stopped
“Restart” can mean several different things in a live setup. If an HTTP source stops delivering media, you need input-side reconnect behaviour. If FFmpeg keeps running but cannot publish to YouTube or another network destination, output recovery may help. If a local relaxation video reaches its end, loop the input. If the FFmpeg process has terminated, no protocol flag inside that process can start it again.
Start by checking what you can observe. Is FFmpeg still running? Does its log show that it is reopening or retrying a connection, or does the process return to the shell? Does the input keep advancing while the output reports errors? If the source and destination are both on the network, which side lost its connection? These distinctions matter because a reconnect setting attached to the wrong side may have no effect.
| What failed | Typical clue | Relevant mechanism | What it does not do |
|---|---|---|---|
| HTTP input | Source read or connection errors while FFmpeg remains active | HTTP reconnect options before the input URL | Relaunch an exited process or repair every kind of source |
| Network output | Output write or connection errors while FFmpeg remains active | FIFO pseudo-muxer recovery around the output | Loop the media file or manage a stopped process |
| Local file reached its end | Input completes normally, so the command has no more media to send | -stream_loop -1 before -i |
Reconnect a publishing URL |
| FFmpeg exited | No process remains to handle another retry | An external service manager or restart loop | Preserve playback position unless the source and command do so |
A destination may also end a broadcast for reasons that FFmpeg cannot fix, such as an invalid stream key or a publishing configuration problem. Read the full error rather than assuming every interruption is a brief network wobble. For a broader operational checklist, see how to monitor a 24/7 stream running on a remote server.
Recover an HTTP input
For a source delivered over HTTP, FFmpeg offers protocol options that control reconnect attempts. Put them before the relevant -i and source URL, since they configure how FFmpeg opens that input. The official HTTP protocol documentation describes controls such as reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error and reconnect_streamed.
A deliberately limited example shape is:
ffmpeg -reconnect 1 -reconnect_at_eof 1 \
-reconnect_streamed 1 -reconnect_delay_max 30 \
-i 'https://SOURCE/relaxation-stream' ...
Replace the placeholder with your actual HTTP source and choose options based on what its server does. The delay value shown is only an example of syntax, not a recommended universal setting. A live source that streams without a seekable file may need reconnect_streamed; an HTTP response ending normally may need reconnect_at_eof if EOF should be treated as a reason to try again. Neither choice makes sense for every source.
The protocol documentation also lists ways to control retry policy, including maximum retry counts and total retry delay, and an option to respect a server’s Retry-After header. A bounded policy limits how long FFmpeg keeps attempting to reopen an unavailable source. A more persistent policy may be useful for an always-on channel, but it can also leave a process waiting on a source that is no longer available. Decide whether you want retries to stop for human attention or continue while the source recovers.
Do not assume HTTP options cover RTMP, another publishing protocol or a local input. They describe HTTP protocol behaviour. Reconnection depends on the installed build, server, network and particular error; the documentation describes controls, not guaranteed recovery. Check the options supported by your build, especially if you have installed FFmpeg through a package manager that may provide a different revision from the current online documentation.
If you publish a local file, these HTTP input flags are not the answer to an output-side disconnect. Keep the input and output roles clear when reading logs and arranging command-line options. The FFmpeg command-line documentation explains option placement and input handling.
Recover a network output with FIFO controls
When FFmpeg remains alive but the publishing connection fails, the FIFO pseudo-muxer can attempt recovery on the output path. Its controls include attempt_recovery, recovery_wait_time and max_recovery_attempts. Unlike HTTP reconnect options, these belong to the output arrangement. They cannot restart a process that has already exited.
Here is a template for a local file sent to a network destination:
ffmpeg -stream_loop -1 -re -i relaxation.mp4 \
-c:v copy -c:a copy \
-f fifo \
-attempt_recovery 1 \
-recovery_wait_time 5 \
-max_recovery_attempts 0 \
-fifo_format flv \
'rtmp://DESTINATION/APP/STREAM_KEY'
Treat every value and format here as an illustration, not a confirmed configuration for your channel. Replace the output URL and underlying muxer with values accepted by your publishing destination. The example assumes the file’s codecs can be copied and that the destination accepts the illustrated FLV/RTMP combination; that may not be true. If the destination requires different codecs, you will need compatible encoding options rather than blindly copying streams.
The -f fifo setting selects FIFO for the output. -fifo_format flv tells it which underlying muxer to use; the FIFO layer is not a replacement for a format compatible with your destination. The recovery options tell FFmpeg to attempt recovery, wait between attempts and decide how many attempts to make. A zero maximum in this example represents an unlimited-attempt choice in the documented option pattern; choose finite or persistent retry behaviour deliberately and verify semantics in your installed version.
Persistent attempts can be appropriate when you expect a short network interruption to clear without anyone present. They do not help with a permanent authentication error, a revoked key, an unsupported format or a destination that has ended the session. Retrying every kind of error indiscriminately can obscure a configuration problem. The FIFO documentation includes recover_any_error, but enabling broad recovery is not a substitute for understanding which errors are transient.
The FIFO pseudo-muxer section of FFmpeg’s all-options documentation describes its recovery mechanism. Read the option descriptions for your build and test the result; it is a mechanism for in-process output recovery, not a guarantee that every interruption is transparent. Where the process keeps failing or the output cannot reopen, you still need diagnosis or supervision at another layer.
Loop a local relaxation file
A relaxation stream often uses a finished recording as its source. If you want the recording to repeat indefinitely, add -stream_loop -1 before its -i. This is an input option: it asks FFmpeg to loop that input. It does not keep a network connection alive and does not restart FFmpeg after a crash.
For file-based live-paced output, a command may use -re before the input as well. Reading a file at its native speed rather than as fast as the machine can process it is commonly appropriate when feeding a live output, but check the destination’s expectations and your media’s behaviour. The command template above combines that input pacing with a loop and separate FIFO output recovery; each part addresses a different concern.
A local file must also be suitable for continuous playback. If audio and video have different durations, incompatible codecs, damaged timestamps or a visible discontinuity at the end, looping the input will not fix those content problems. Listen and watch across the join, including the transition from the last frame to the first. A quiet nature recording may hide a small join better than a track with a spoken introduction, but neither should be presumed seamless without checking.
For a playlist or several source files, do not assume that a single -stream_loop arrangement will behave like a playlist manager. Compare the workflow you need with OBS playlist source and VLC looping options. If the media does not open or play reliably in your chosen workflow, the guide to making MP4 files compatible with OBS playlist streaming covers a related compatibility problem. These are distinct tools and neither changes what FFmpeg’s output recovery does.
Handle an FFmpeg process that exited
When the process has stopped, there is no FFmpeg instance left to reconnect its input or recover its output. Use a process supervisor outside FFmpeg if your requirement is to start a new invocation after termination. Depending on your operating system and how you run the channel, that could be a service manager or a carefully configured restart loop. The supervisor observes the process; FFmpeg’s protocol options handle connections within a running process.
Set the supervisor’s restart policy with care. A process that exits because of a persistent error may be relaunched repeatedly without becoming healthy. Capture logs, make the exit visible to whoever maintains the channel and decide whether repeated failures should pause for intervention. A restart loop also needs a sensible delay so that a failed command does not launch continuously and fill logs or consume resources.
Consider where a new invocation begins. If it opens a local file again, it may start from the beginning rather than resume at the point of interruption. A live HTTP source may offer different behaviour when reopened, depending on the source. If continuity of a particular moment matters, determine whether the source and your command can preserve position; do not infer that process supervision remembers it.
This distinction also matters for unattended operation. A desktop command in a terminal may disappear when the computer sleeps, loses power or closes the session. A supervisor can address process lifecycle on a machine you control, but it does not by itself guarantee network availability, compatible media or an accepted YouTube broadcast. If the specific pain is needing to keep your own computer on to carry the file-based broadcast, StreamNeo removes that requirement by running the uploaded file as a YouTube live stream while your computer is switched off; it does not change the need to prepare compatible content and channel settings.
Test recovery behaviour before relying on it
A command that starts successfully has not yet demonstrated recovery. Test the failure you actually care about in a controlled period, with a copy of the command and logs available. For an HTTP input, check that the source can be reopened after a temporary interruption. For FIFO output recovery, confirm that FFmpeg remains alive and observe whether it attempts to reopen the destination. For a local loop, let the file reach its end and confirm it starts again as expected. For supervision, stop the process deliberately and verify that the supervisor’s policy behaves as intended.
Avoid testing against an important live broadcast without a plan. Use a private or otherwise appropriate test destination, and check the current YouTube guidance for the channel and stream setup you intend to use. A recovery test can reveal that the command retries, but it cannot establish that every network condition or YouTube-side issue will recover. Record the distinction between what you tested and what remains unverified.
Read logs for the transition, not just the final status. Note whether the input URL, output URL or process exit appears in the error, and whether a retry is followed by media reaching the destination. A message about reconnecting is not proof that viewers received uninterrupted video. Check the live output itself and, where relevant, confirm that audio continues and that the loop has not restarted at an unwanted point.
Finally, verify the exact options against the installed build. FFmpeg’s documentation index notes that its online documentation is regenerated nightly for the newest revision, so it may not match an older package on your machine. Ask the local binary for its version and available help, then compare with the relevant online protocol, FIFO and command-line sections. If a flag is unrecognised, do not silently remove it and assume the same recovery behaviour remains.
For the command you will keep, write down the source type, destination protocol, codecs, retry policy and what should happen after process exit. That short record makes it easier to distinguish a failed input reconnect from an output recovery failure the next time the stream drops.
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 restart FFmpeg after it exits?
No. They configure reconnect behaviour for an HTTP input while FFmpeg is running. To launch a new process after termination, use an external supervisor or restart policy.
Does -stream_loop -1 reconnect my YouTube output?
No. It repeats the input file; it does not reopen or repair the publishing connection. Use separate output recovery controls when appropriate, and verify that the output muxer and destination are compatible.
Can FIFO recovery cover every network drop?
No. FIFO can attempt recovery on an output while FFmpeg remains alive, but errors may persist and attempts can fail. Its behaviour depends on the failure, destination and installed build, so test the case you care about.
Where should I put the HTTP reconnect options?
Put them before the -i and URL for the HTTP source they configure. They apply to that input, not universally to every output or protocol; check the official protocol documentation and your build’s supported options.