When an FFmpeg YouTube stream disconnects, first check whether FFmpeg is still running or has exited. Use FFmpeg’s FIFO muxer to attempt recovery from some temporary output failures; use an external supervisor to relaunch a process that has stopped.
Those are separate recovery layers, not one universal reconnect switch. Neither guarantees uninterrupted playback or recovery from every failure, so check the logs, verify YouTube’s ingest details and test what viewers see after each kind of interruption.
Identify which failure occurred
A dropped stream can describe different events. The network path from your encoder to YouTube might fail briefly while FFmpeg continues running. Or FFmpeg might encounter an error and exit. There is also a harder-to-diagnose case: the process remains alive but is stalled and no longer makes useful progress.
The distinction matters because an in-process output recovery option cannot relaunch a process that no longer exists. A supervisor can restart a process that exits, but a basic restart policy may not notice a living process that has stopped sending data. Treat these as separate questions: is the output connection working, and is FFmpeg making progress?
If you are watching YouTube, a frozen image or an ended broadcast does not by itself tell you which condition occurred. Check the machine running FFmpeg and the stream’s status in YouTube Live Control Room. A local process check tells you whether FFmpeg is present; the log helps show what it was doing; YouTube’s status helps establish what reached the platform.
For example, a log reporting a temporary write or network error followed by continuing activity is different from a final fatal error and a returned shell prompt. Do not set up a restart loop until you know what failed: repeated launches may not fix a bad stream key, invalid destination, missing input file or sustained network problem.
Check FFmpeg logs and process state
Keep FFmpeg’s standard output and error available in a log or service journal that survives the terminal closing. The exact method depends on how you launch the process. Record enough context to match messages to the running attempt, including when it started and whether the process later exited. Avoid putting a live stream key in a public log, issue or example; treat it as a credential.
Then check process state on the machine that runs FFmpeg. If the process is absent, inspect the end of its log for an exit reason. If it is present, look for recent output errors and evidence that input and output are advancing. A process listing alone is not a health check: a process can exist without successfully publishing.
Separate input failures from output failures. If the source file cannot be read or the input connection has failed, a setting intended to recover the RTMP output will not repair that source. FFmpeg’s HTTP reconnect options belong to HTTP protocol behaviour; they are not a general fix for a YouTube RTMP publishing failure. The FFmpeg HTTP protocol documentation and its FIFO muxer documentation describe different mechanisms.
Before changing options, confirm the destination URL and stream key in YouTube Live Control Room. YouTube’s encoder setup guidance explains that the encoder needs the server URL and stream key. If you rotate a key, follow the updated value in the encoder; the consequences of a changed key for a running channel are discussed in what happens when a church’s livestream key changes.
Attempt RTMP output recovery with FIFO
For a temporary output failure while FFmpeg continues processing, FFmpeg documents a FIFO pseudo-muxer pattern for RTMP. FIFO sits between the media processing and the output, and the example configures it to attempt recovery while processing continues in real time. In simplified form, the relevant options are:
-f fifo -fifo_format flv \
-drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1
The documented example places these options before the RTMP destination, with FLV as the underlying output format. It also uses -re to read at real-time speed. Its complete shape 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_KEY'
This is a documentation example, not a command to paste unchanged into every setup. Replace the input, codecs, stream mapping and destination with values appropriate to your workflow, and keep the actual key private. Confirm that your installed FFmpeg build supports the options and consult documentation matching that build. The current FFmpeg FIFO muxer reference is the primary source for the option behaviour and example.
The -recovery_wait_time 1 value in the example describes the interval before another recovery attempt, not a promise that a connection will be restored within a second. Likewise, the documented attempt to recover indefinitely does not mean every network failure, server response or configuration error can be fixed. Check the resulting log and test your own output path before depending on this for an unattended channel.
Understand what FIFO recovery handles
FIFO recovery is an output-side measure for temporary failure while FFmpeg remains alive and continues processing. The documented pattern attempts to reopen or recover the output path after a failure. It is not a process manager: if FFmpeg exits, there is no running FIFO muxer left to make another attempt.
Recovery also has a cost. The example includes -drop_pkts_on_overflow 1, which permits packets to be dropped when the FIFO queue overflows rather than allowing the queue to grow without limit. That is a practical trade-off, not a guarantee that all frames are preserved. During an outage, the stream can have a gap or discontinuity; what viewers experience depends on the failure and subsequent YouTube stream state.
Do not confuse output recovery with reconnecting an HTTP input. If the source is an HTTP feed, HTTP protocol options may be relevant to reading that source, but they do not demonstrate that an RTMP output to YouTube will recover. Diagnose both sides independently: confirm the input is readable, then inspect whether the output can publish.
If you are preparing recorded media rather than capturing a live source, the file itself needs suitable encoding and mapping. The practical considerations in encoding Telugu song videos for an always-on YouTube channel can help you check the input before treating every interruption as a network issue. For a playlist or changing programme, remember that changing the media and restoring a broken publishing connection are separate tasks.
Restart exited processes with a supervisor
When FFmpeg exits, an external process supervisor can start it again according to a restart policy. That is a different layer from FIFO. The supervisor watches the process lifecycle; FFmpeg’s muxer handles output behaviour inside a running process. You can use both, but one does not substitute for the other.
Choose a supervisor appropriate to the operating system and deployment you actually use, then verify its restart policy and logging behaviour against its official documentation. This article does not prescribe a universal service file or command: syntax, defaults and restart conditions vary by supervisor and version. Ensure the process starts with the right working directory, input, output arguments and credentials after a reboot or failure, and confirm that repeated failures do not create an uncontrolled launch loop.
A restart policy generally responds to process termination, not to every form of lack of progress. A live-but-stalled FFmpeg process may need a separate health check or watchdog that can detect a condition meaningful to your stream, such as a lack of recent output progress. That check is deployment-specific. Define what evidence counts as healthy, how long an interruption is tolerable and what action should follow, then test it without assuming a process listing is enough.
A process restart can also affect the YouTube broadcast lifecycle. YouTube’s encoder guidance describes stopping encoder output as a way to end a stream, but the sources here do not establish that a restarted publisher will preserve the same live event or viewer continuity. Check the actual stream state in Live Control Room after a restart. If keeping a running programme while changing media is your separate need, see how to change videos in a YouTube live stream without ending it; do not treat that as evidence that an encoder restart preserves a broadcast.
Check the YouTube ingest connection
Use the current server URL and stream key shown in Live Control Room rather than relying on an old copied command. YouTube’s Live API also exposes primary and backup ingest addresses, including RTMP and RTMPS variants. The existence of a backup address does not mean FFmpeg will switch to it automatically; the API describes it as an option for sending content simultaneously. See the YouTube Live API ingestion information for the available ingest details.
If you publish over RTMPS, verify the protocol and endpoint as well as the key. YouTube describes RTMPS as RTMP over TLS/SSL, and its RTMPS troubleshooting guidance advises checking the RTMPS server and protocol; for relevant SSL errors it suggests port 443. These checks address connection setup, not process restarts. A wrong URL, incompatible protocol or invalid key is unlikely to be solved by asking FFmpeg to retry indefinitely.
If your workflow runs on a VPS, network and resource constraints can complicate diagnosis. A machine can remain reachable while outbound publishing is interrupted, or FFmpeg can stop because the input or local resources have failed. The operating trade-offs discussed in streaming a slideshow continuously to YouTube from a VPS are useful context when deciding what to monitor beyond the process itself.
Test network and process failure cases
Test the two recovery layers separately before combining them. First, while keeping FFmpeg running, simulate or observe a temporary output interruption in a controlled setting. Confirm the log records the failure and a later recovery attempt, and check whether YouTube receives output again. Do not infer success from an FFmpeg message alone: verify the destination and viewer-facing stream.
Next, test process termination. Stop the FFmpeg process deliberately during a maintenance window and check whether the supervisor detects exit, launches a new attempt and records both events. Verify the new process receives the correct input and destination. Because a restart can alter stream state, check the Live Control Room rather than promising that the existing event continues unchanged.
Finally, consider the live-but-stalled case separately. A supervisor that only watches for process exit may do nothing when FFmpeg remains present but stops progressing. If you implement a watchdog, test the detection condition and the action it takes; avoid a threshold that mistakes a short source pause for a permanent failure. The reviewed FFmpeg example does not define a universal health check.
For each test, keep a short record of the symptom, relevant log lines, process state, recovery action and YouTube result. This gives you evidence about your own setup instead of relying on a generic claim that a reconnect option is enabled. Repeat the tests after changing FFmpeg versions, command-line options, ingest settings or the supervisor policy.
Monitor recovery and YouTube stream health
After configuring recovery, monitor more than whether the process exists. Check for recent log activity, repeated output errors, input progress and YouTube’s live status. If FFmpeg keeps retrying but the destination remains unavailable, investigate the endpoint, credentials and network path rather than assuming the retry loop has fixed the problem.
YouTube’s guidance says streams under 12 hours are automatically archived. That is a platform behaviour, not evidence that a reconnect will preserve a broadcast or that a particular restart sequence will produce a continuous archive. Review the live event and archive after testing, and consult the current official guidance when planning stream duration or lifecycle behaviour.
Keep the recovery path understandable for whoever is on call. Document where logs are, how to confirm whether FFmpeg is running, how to check the active stream in Live Control Room and how to stop repeated failed attempts safely. Never publish the key in that runbook. If a restart does not restore output, a clear next step—checking the source, ingest address and key—is more useful than an unexplained loop.
If maintaining a computer and supervisor is itself the failure point, an uploaded-file workflow can remove that particular burden: StreamNeo turns an uploaded video into a YouTube live stream, so you do not need to leave your own computer running for that use case. It is YouTube-only and does not replace a live encoder workflow when you need to transmit a changing real-time source.
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
Does FIFO restart FFmpeg after it exits?
No. FIFO is an output muxer used within a running FFmpeg process. If FFmpeg exits, an external supervisor is the separate layer that can relaunch it under its configured policy.
Do FFmpeg HTTP reconnect flags fix a YouTube RTMP disconnect?
Not as a general rule. HTTP reconnect options concern HTTP protocol behaviour, while FFmpeg’s documented FIFO example addresses RTMP output recovery. Diagnose the input and publishing output separately.
Will a restart keep the same YouTube live event open?
The sources covered here do not establish a continuity guarantee after a publisher restart. Check the stream in Live Control Room and test your actual workflow before relying on a particular event lifecycle.
What should I check first when the stream drops?
Check whether FFmpeg is still running, then read its recent log and verify the current YouTube server URL and key. A running process with a temporary output error calls for a different response from a process that has exited.