If your internet drops while FFmpeg is pushing a live loop to YouTube, the documented output-side approach is to wrap the FLV output in FFmpeg’s FIFO pseudo-muxer and enable recovery attempts. This can retry a temporary output failure only while the FFmpeg process is still running; it cannot restart a process that has exited, and a retry is not guaranteed to restore the stream.
The queue setting is a separate decision: dropping packets can let processing continue while data is lost, whereas waiting for the output can build back-pressure and eventually stall processing. Before relying on either behaviour overnight, test the exact command and inspect YouTube’s stream health.
Confirm the failure is on the output side
Start by separating an internet outage from a problem with the media input, encoder, or YouTube ingest configuration. The FIFO recovery pattern discussed here is for a failure writing the outgoing RTMP or RTMPS stream. It is not a general reconnect switch for every part of an FFmpeg command.
When connectivity returns, check the machine that runs FFmpeg. Confirm it can reach the internet, then determine whether the FFmpeg process is still alive. Look at the terminal, service logs, or process monitor you normally use. A process that remains active may still be making recovery attempts; a process that has exited cannot make another attempt, regardless of the FIFO options in its old command.
Also check whether the input is still available. A local file may have reached its end, a playlist may have a path error, or a source may have stopped independently of the network. Those are different failures. If the input has failed, recovering the output connection alone will not create new audio or video.
Do not treat FFmpeg’s HTTP input options as the fix for an RTMP output push. Options such as -reconnect and -reconnect_streamed address HTTP protocol behaviour on the input side. They do not replace the FIFO muxer’s output recovery configuration for a YouTube RTMP(S) destination.
For a useful diagnosis, note when the outage began, whether the process stayed alive, and what the last relevant output message says. Avoid copying a line containing your stream key into a public support post. These observations help distinguish a retrying process from a terminal error that needs an operator or a supervisor to relaunch FFmpeg.
Wrap the RTMP or RTMPS output with FIFO
FFmpeg’s FIFO pseudo-muxer sits between the encoded media and the actual output muxer. For a YouTube-style FLV stream, specify FIFO as the outer format and FLV as the format used by the wrapped output. FFmpeg’s FIFO muxer documentation describes recovery options and shows a network-output pattern.
A simplified pattern is:
ffmpeg -re -i INPUT \
-c:v libx264 -c:a aac \
-map 0:v -map 0:a \
-f fifo -fifo_format flv \
-drop_pkts_on_overflow 1 \
-attempt_recovery 1 -recovery_wait_time 1 \
'rtmps://DESTINATION/STREAM_KEY'
This is a shape to adapt, not a command to paste unchanged. INPUT and DESTINATION are placeholders. Keep the codecs, stream mapping, timing options, and audio/video handling that fit your source and existing setup. If your current command already has filters, separate audio handling, or a looping input, retain and test those parts rather than assuming this short example covers them.
The important change is at the output: -f fifo -fifo_format flv wraps the FLV output in FIFO. The destination remains the YouTube RTMP or RTMPS publishing address supplied for your stream. YouTube’s encoder setup guidance explains how to obtain the stream URL and key and configure an encoder. Copy the current values from your own Live Control Room workflow; do not infer a URL or key from an example.
The FIFO wrapper does not make a weak or disconnected network path disappear. It governs what FFmpeg does when writing to that output fails. You still need an input that can be read, an encoder command that works, and a destination that accepts the stream.
Enable recovery and understand the retry boundary
-attempt_recovery 1 enables FIFO recovery attempts after an output failure. In FFmpeg’s documented example, -recovery_wait_time 1 sets the wait interval between attempts to one second. That is an example setting, not a guarantee that a connection will be restored after a particular outage duration or that every error will be retried successfully.
There are two boundaries to keep in mind. First, a failure must be within the recovery behaviour supported by the installed FFmpeg build and options. Second, the process must remain alive to make attempts. If FFmpeg exits because of a terminal error, a machine restart, or an operator stop, FIFO cannot launch it again. Process supervision is a separate concern; no supervisor configuration is implied by adding these muxer options.
FFmpeg exposes additional controls, including options that affect which errors qualify, the number of recovery attempts, and keyframe handling. Support and behaviour can vary with the installed version. Check the local ffmpeg -h muxer=fifo output before adding options such as -recover_any_error, -max_recovery_attempts, or -restart_with_keyframe, then test them in a controlled stream. Do not assume a setting exists or behaves identically on every binary.
The retry interval is not the same thing as the duration of an outage that can be survived. Whether a particular connection error is retried, whether the network path comes back, and whether YouTube accepts the resumed publishing session are separate questions. Plan for the possibility that an operator still has to diagnose and restart the encoder.
Choose queue behaviour: drop or block
When output stops accepting data, the FIFO queue gives you a place to buffer packets temporarily. What happens when that queue fills is a trade-off, not a free continuity improvement. With -drop_pkts_on_overflow 1, FFmpeg can keep processing by dropping packets once the queue overflows. That can avoid letting a growing backlog hold up the encoder, but the dropped audio or video represents missing programme content.
If you do not drop packets, FFmpeg may instead wait for the output to accept them, depending on configuration. That preserves queued packets while there is space, but a prolonged failure can fill the queue and create back-pressure. Processing may then stall rather than continue at the intended pace. A queue cannot preserve an unlimited outage without consequences.
| Choice | During a temporary output failure | Main cost | Consider it when |
|---|---|---|---|
| Drop on overflow | Processing can continue after the queue fills by discarding packets | Missing media and a visible or audible gap | Keeping the process moving matters more than retaining every packet |
| Do not drop | Queued packets can wait for the output while capacity remains | Back-pressure may stall processing when the queue fills | Retaining queued media is more important and a stall is acceptable |
The right choice depends on what the channel is doing. A lofi station may tolerate a short discontinuity more easily than a scheduled news loop where a missed sentence matters. A devotional stream may prefer the encoder to keep progressing rather than later sending stale material, but that is a programming decision, not a universal technical rule.
Do not choose based only on the word “recovery”. Decide whether the more acceptable failure mode is losing packets or allowing pressure to propagate back into processing. Then validate the actual behaviour in a test stream. The table does not predict the length of a gap: that depends on the outage, buffer state, process behaviour, and reconnect outcome.
Replace the example input and destination safely
Adapt the example to your established command in small steps. Replace INPUT with the local file, playlist, or other input expression that the command already uses. Replace the destination placeholder with the publishing URL and key from YouTube’s Live Control Room. Keep the URL quoted so shell characters are not interpreted unexpectedly, and avoid placing a real key in a public script or post.
The sample uses H.264 video, AAC audio, and explicit maps for one video and one audio stream. Those choices are not a requirement for every source. If your file has multiple audio tracks, no audio, subtitles, or a filter graph, mapping only 0:v and 0:a may not fit. Adapt stream selection and codecs to the material you actually intend to broadcast.
If you use a concat playlist or prerecorded loop, confirm that its file paths and loop behaviour still work after the output changes. The guide to building an Indian classical music loop with FFmpeg concat covers the input side of a continuous programme. For a playlist whose files fail to open on a Linux VPS, the FFmpeg playlist path troubleshooting guide is relevant; fixing those paths is distinct from reconnecting the output.
YouTube’s encoder guidance recommends a two-second keyframe interval and says not to exceed four seconds. It also describes CBR as the bitrate encoding setting. These are ingest and stream-quality guidance, not a promise of network recovery. Review YouTube’s live encoder settings for the current official details, and test the settings with your own content and connection.
Before changing a command that has been running reliably, save a private copy of the working version. Make one change at a time where possible, so you can tell whether an issue came from the FIFO wrapper, stream mapping, or destination. For more context on the trade-offs of a computer-based continuous broadcast, see the electricity cost comparison for an always-on loop PC.
Protect the stream key as a secret
A YouTube stream key is a credential for publishing to a channel’s live workflow. Treat it like a password: share it only with the encoder you intend to use, and do not include it in a screenshot, public command example, shared document, or support ticket. The placeholder in this article is deliberately not a real key.
A command that contains a literal key may also leave traces in shell history, scripts, process listings, or logs, depending on how it is run and how the system is configured. Avoid pasting an unredacted command into a public forum. If a key is exposed, use YouTube’s current Live Control Room controls to manage or replace it, and update the encoder configuration accordingly.
When you share diagnostic output, redact the full publishing URL, key, and any account-identifying details. You can usually describe whether the destination is RTMP or RTMPS and include the relevant error text without revealing the credential. Keep a private, access-controlled copy of the real command for your own recovery procedure.
A restarted encoder may be rejected if it is using a stale or mismatched URL or key. YouTube’s streaming troubleshooting guidance directs creators to check the configured stream key when a third-party encoder reports a startup problem. Confirm values in the official control room rather than repeatedly retrying a guessed destination.
Check recovery, stream health, and your fallback
Test the command before depending on it during an overnight broadcast. Use a private or unlisted test stream if appropriate for your channel, and create a controlled interruption that you can observe. Check whether FFmpeg stays alive, what the logs report, whether recovery attempts occur, and whether audio and video return in YouTube’s preview. This article does not claim to have executed or tested the command for your machine.
When a real outage happens, first confirm that connectivity has returned from the streaming machine. Then check whether FFmpeg is still running. If so, allow its configured attempts to work and watch the logs and YouTube stream health. If it has exited, restart the encoder through your established operator process or process supervisor, then check the Live Control Room preview and health indicators. Do not expect FIFO itself to restart it.
YouTube recommends testing a stream and monitoring health during an event. Its streaming tips warn that a connectivity disruption can break a stream. YouTube also recommends sufficient outbound capacity, including headroom, but spare capacity cannot restore a physically disconnected internet path.
If interruptions recur or a missed segment is costly, treat redundancy as a separate design. YouTube describes testing a backup encoder by stopping the primary or disconnecting its Ethernet cable and checking player rollover. A second encoder and a genuinely separate network path may help with different failure modes, but they require their own configuration and tests; they are not a property of FIFO recovery in one FFmpeg process.
A mobile hotspot or cellular router is only a possible alternate route if local coverage and sustained upload capacity are adequate, the data allowance suits continuous use, and it does not depend on the same failed network path. Coverage varies by location, so test the actual route where the channel runs. For a channel built around a prerecorded file rather than a locally managed encoder that needs ongoing attention, StreamNeo removes the need to keep that computer running to carry the uploaded video as a 24/7 YouTube live stream.
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
How do I make FFmpeg reconnect to YouTube Live after my internet drops?
For a temporary RTMP or RTMPS output failure, use FFmpeg’s FIFO pseudo-muxer around the FLV output and enable recovery attempts. Test the command with your own input and destination, because recovery is not guaranteed and depends on the process remaining alive.
My FFmpeg live stream stopped when the internet came back. What should I check?
First check whether the FFmpeg process is still running and inspect its logs. FIFO retries can act only within a live process; if it exited, restart it using the current YouTube stream URL and key, then inspect the Live Control Room preview and health status.
Should I drop packets or let FFmpeg wait?
Dropping on overflow can keep processing moving but loses media and may leave a gap. Waiting preserves queued packets while there is room, but a full queue can create back-pressure and stall processing; test which consequence is acceptable for your programme.
Do FFmpeg HTTP reconnect flags recover an RTMP output?
No. HTTP reconnect options concern HTTP input-side behaviour and are not the FIFO recovery mechanism for an RTMP output push. For YouTube output recovery, consult the installed FIFO muxer help and the current FFmpeg documentation.