If FFmpeg stops publishing to YouTube Live after a network drop, first establish whether FFmpeg is still running and whether the failure is on the input or output side. HTTP -reconnect options are not a general recovery switch for an RTMP or RTMPS output; FFmpeg documents the FIFO muxer as a separate route for attempting RTMP output recovery.
Before changing flags, preserve the command and the log around the outage, check the current YouTube ingest URL and key, and compare FFmpeg's state with Live Control Room. A loop that keeps reading a file is not the same thing as a publishing connection that has recovered, and no option guarantees that every interruption will resume the same live event.
Start by identifying what stopped
A “loop” can mean that your input file or playlist repeats, that the FFmpeg command runs inside a shell loop, or simply that your YouTube channel is intended to be always on. Those are different layers. When a stream goes dark, identify which layer stopped before deciding that FFmpeg needs a reconnect flag.
Look at the machine or environment running FFmpeg. Is the process still present? Is it using CPU, and are new log lines appearing? If the process exited, an output muxer recovery attempt cannot bring it back: recovery settings operate while FFmpeg is running. If it remains alive, determine whether it is still reading and encoding the input, or whether it reports an error opening or writing the output.
A file can continue to loop locally while YouTube receives nothing. Likewise, an input network stream can fail even though the RTMP publishing connection is healthy. Treat input, encoding, output transport and the YouTube live session as separate observations. For a recorded-video setup, the background in running a 24/7 recorded video stream on Ubuntu can help you distinguish the job that plays the file from the job that publishes it.
Do not restart immediately if you can safely capture the failure first. A restart may restore a picture, but it can erase useful evidence about whether FFmpeg exited, remained stuck, or kept retrying. For a critical channel, make recovery steps deliberate: collect the status, protect the stream key, and then decide whether a restart is appropriate.
Why HTTP reconnect flags do not generally fix RTMP output
FFmpeg's -reconnect family is documented in its HTTP protocol documentation. The options include reconnect, reconnect_at_eof, reconnect_on_network_error, and reconnect_on_http_error, among others. Their placement in the HTTP protocol section matters: they describe behaviour for HTTP connections and streams, not a universal reconnect facility for every output protocol.
The documentation defines HTTP reconnect as reconnecting automatically when disconnected before EOF is hit. That statement does not mean that adding -reconnect 1 to a command that publishes via RTMP or RTMPS makes its publishing output reconnect. A command may have an HTTP input and an RTMP output, so an HTTP option could be relevant to reading the source while doing nothing to repair the distinct publishing leg.
Option scope and placement also matter. FFmpeg options generally apply to the relevant input or output context; a flag that is valid for one protocol is not necessarily accepted or useful for another. Check the documentation and help for the installed build rather than copying flags from a command that happens to use FFmpeg. Preserve the full command with the key redacted so you can see which URL each option is meant to affect.
If your input is an HTTP playlist or stream, an HTTP reconnect option may help with that input under appropriate conditions and version support. It cannot be taken as proof that an RTMP(S) output will recover. Keep the diagnosis split: source recovery answers “can FFmpeg keep reading?”, while output recovery answers “can it resume sending to YouTube?”.
Read the log around the interruption
Save the complete FFmpeg command, version and build information, and the log lines immediately before and after the drop. Redact the stream key anywhere you share the command or log. A key is a credential, not a harmless part of an example URL; anyone who obtains it may be able to publish to the associated stream configuration.
Read the messages in sequence, not as isolated error strings. Did the input report a read failure first? Did encoding continue? Did an output or muxer error appear? Did FFmpeg print an exit message, or do timestamps and progress output stop while the process remains present? These clues help separate a source failure, an output connection failure and a terminated process. A message alone may not settle the cause, especially if the network interruption affects more than one connection.
Record the time of the interruption and compare it with what you see in Live Control Room. Note whether the preview or stream status changed, whether the live session still appears to be active, and whether FFmpeg continued to emit output-related messages. You are building a timeline, not trying to infer success from one reassuring line.
Keep a copy of the original command before editing it. If you change the input, transport, buffering, recovery options and restart policy in one go, a later improvement will not tell you which change mattered. Make one deliberate change at a time, then retain the before-and-after logs. This is more useful than repeatedly adding flags found in unrelated examples.
If the log suggests that the picture itself is absent rather than the connection, check the source and mapping separately. The black-screen troubleshooting guide covers a different failure class; a black picture and a disconnected output can look similar to a viewer, but they require different evidence.
Verify the YouTube endpoint and key
In Live Control Room, check the current stream URL and stream key for the stream you intend to publish. Compare them character by character with the destination in your command, and confirm that you have not copied a stale endpoint or a key for another stream. Do not paste the unredacted key into public logs, screenshots or support posts.
YouTube's RTMPS help guidance describes RTMPS as a secure extension of RTMP and directs creators to obtain the URL and key from Live Control Room. If you choose RTMPS, verify that the destination uses the rtmps protocol and that your FFmpeg build supports the protocol you intend to use. Do not substitute the placeholder endpoint from an FFmpeg example for the ingest URL shown for your stream.
For an SSL error, YouTube's guidance says to check that the protocol and server are correct and, if needed when the URL is otherwise correct, specify port 443. For a timeout, it advises checking the server URL and protocol and confirming encoder support for RTMPS. Treat those as checks to investigate, not as proof that a network drop has been fixed. If the URL, key or protocol is wrong, reconnect attempts will repeat a configuration error rather than repair it.
Check whether your command targets the primary or backup ingest address only if you have an actual configured reason to do so. Avoid inventing a replacement URL from memory. The relevant value is the one currently provided for your stream in YouTube's controls, used in the format and protocol supported by your encoder.
What FIFO muxer recovery does and does not do
FFmpeg documents a separate output recovery approach in its FIFO muxer documentation. Its example streams to an RTMP server and attempts recovery during a temporary network outage. The core options shown are -attempt_recovery 1 and -recovery_wait_time 1; in that documented example, recovery is attempted every second indefinitely. This is documentation of an attempt pattern, not a promise that YouTube will accept every reconnect or preserve the same event state.
The example uses a FIFO muxer around the FLV output and includes -drop_pkts_on_overflow 1. An illustrative 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_name
This is FFmpeg's documented example pattern, not a ready-to-run YouTube command. Replace the input, maps, codecs and destination with the values for your stream, and use the current ingest URL and protected key. Consult the muxer documentation and the help output for the FFmpeg version and build you actually run; availability and behaviour can depend on the build and the rest of the command.
The FIFO options address recovery attempts in the output path while FFmpeg continues processing. They do not restart an FFmpeg process that has exited. If FFmpeg quits, process supervision is a separate operational layer that can relaunch a command; it cannot correct a bad key, an invalid endpoint, unsupported protocol or a continuing network failure. Check the restarted process and YouTube state rather than assuming relaunch restored publishing.
There is also a trade-off in buffering and packet loss. The example's -drop_pkts_on_overflow 1 allows packets to be dropped on overflow; during a long interruption, that means recovery design can affect what happens to queued media rather than preserving every packet. Consider the behaviour you want for a devotional loop, a local news repeat or a study channel, and test it before relying on it. A buffer is not a way to make an outage invisible or unlimited.
| Recovery layer | What it addresses | What to verify |
|---|---|---|
| FIFO muxer recovery | Attempts to recover an RTMP output during temporary failures while FFmpeg is processing | Build compatibility, recovery logs, buffering and packet-drop behaviour, and YouTube's observed status |
| Process supervisor or restart policy | Relaunches FFmpeg after the process exits | That the process starts with the right command and credentials, and that YouTube accepts the new publishing connection |
| Input loop or playlist | Supplies more media to FFmpeg | That reading continues; this does not itself restore the output connection |
If you are adapting a loop command, keep the loop and output recovery questions separate. This guide to keeping a cloud-streamed YouTube loop from creating a new live event addresses event continuity, which is related but not identical to transport recovery. A loop can supply content again without guaranteeing that a failed publisher reconnects to the intended live session.
Compare FFmpeg evidence with Live Control Room
Use Live Control Room as an independent view of the stream, not as a substitute for the FFmpeg log. YouTube exposes stream setup and status there; check the preview and indicators available for the current stream, and note whether YouTube reports that it is receiving data. Compare those observations with timestamps in FFmpeg's output.
If FFmpeg says it is writing but YouTube reports no incoming stream, revisit the destination URL, protocol, route and output errors. If YouTube shows incoming data but the preview is black or delayed, investigate the media path and encoding as well as connection state. If the live session has ended or changed state, a successful new connection may not necessarily mean the original event continued as you expected. Confirm the event state before telling viewers that the same broadcast has resumed.
YouTube's status display may take time to reflect a change, and a short-lived preview is not proof of sustained delivery. Record what you observe after a recovery attempt and compare it with the log. If you make several changes before checking again, it becomes harder to know whether the status changed because of the configuration or because the interruption ended on its own.
For a channel that uses a scheduled event, review the event and stream state before repeatedly launching a new process. The goal is not simply to produce an outgoing connection; it is to understand whether YouTube is receiving the intended stream under the intended event. The FFmpeg bitrate settings guide is relevant when investigating media configuration, but bitrate tuning does not replace reconnect diagnosis.
Retest in a controlled way
Once you have evidence and a candidate fix, test with a non-critical broadcast or a planned interruption. First confirm normal input, encoding, output and Live Control Room status. Then test the recovery behaviour you intend to use and capture the logs and YouTube status during and after the interruption. Do not assume that an arbitrary real outage is a safe test: it may leave the live event in a state you do not want.
If you test FIFO recovery, establish whether FFmpeg remains running and whether recovery messages appear. If you test process supervision, separately confirm that it responds to process exit and that the launched command is correct. These tests answer different questions. Neither establishes behaviour across every network, FFmpeg build, interruption length or YouTube session state.
Keep the test scope modest. Change a single relevant setting, such as the output recovery pattern, and preserve a version of the previous command. Confirm that the input loop still behaves as intended and that the stream is actually visible in YouTube's controls. A command that runs without an immediate error is not the same as a confirmed, sustained live stream.
For a real overnight channel, decide what should happen if recovery fails. You may need an alert, a human check, a process restart path or a fallback plan, depending on the importance of the broadcast. A recovery option is one part of operations, not a replacement for monitoring. Do not promise viewers uninterrupted playback until your own tests and monitoring support that expectation.
Choose the recovery layer that matches the failure
Use the evidence to select a response. If the input stopped but the output is open, investigate the source and any applicable input protocol options. If the output connection failed while FFmpeg continues, review the FIFO muxer recovery pattern and test it against your build and YouTube setup. If the process exited, address process restart separately. If YouTube rejects the connection, correct the endpoint, protocol or credentials before adding retry logic.
This order avoids a common failure loop: changing a command repeatedly while leaving the actual problem untouched. A supervisor cannot fix an invalid stream key, HTTP reconnect options do not generally recover an RTMP output, and FIFO recovery does not guarantee restoration of every interrupted stream. Each tool operates at a different layer and needs evidence that the failure is at that layer.
If maintaining a command and watching a process overnight is the part that repeatedly fails, StreamNeo can remove that specific operational burden by turning an uploaded video into a YouTube live stream that runs with your computer off and is monitored and restarted if it drops. It is YouTube-only, so it is not a fit if you need to publish to another platform or need FFmpeg-level control over a custom live production.
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 a network drop?
First check whether FFmpeg is still running, preserve the log around the failure, and verify the current YouTube URL and key. For RTMP output, FFmpeg documents FIFO muxer recovery options such as -attempt_recovery 1 and -recovery_wait_time 1; test the pattern with your build and stream rather than treating it as a guarantee.
Does -reconnect work with an RTMP output?
FFmpeg documents the -reconnect options under its HTTP protocol. They may be relevant to an HTTP input, but they should not be treated as a general RTMP or RTMPS output recovery switch.
What if FFmpeg exited instead of retrying?
Muxer recovery applies while FFmpeg is operating, so an exited process needs a separate process-level restart mechanism if you want automatic relaunch. A restart does not fix a bad key, incorrect ingest URL, unsupported protocol or persistent network fault; verify those and compare the new connection with Live Control Room.
Does a looping video keep the YouTube stream alive?
A loop can keep supplying media to FFmpeg, but it does not by itself recreate a failed publishing connection. Diagnose the input loop and output recovery separately, then check whether YouTube is receiving the intended stream.