If a network drop makes FFmpeg exit, run it under an operating-system supervisor that can start the process again. FFmpeg’s HTTP reconnect options are not a general switch for reconnecting an RTMPS output, and a restarted process is not guaranteed to rejoin the same YouTube live event.
Keep the correct RTMPS server URL and stream key available to the encoder, protect the key, and rehearse the full failure and recovery path before a service. The important test is not only whether FFmpeg starts again, but whether the intended YouTube event receives usable audio and video afterwards.
Identify what kind of network failure occurred
“Internet dropped” can describe several different faults, and each calls for a different response. The encoder may lose its connection briefly but remain running; FFmpeg may report an error and exit; the computer may lose network access for longer; or FFmpeg may restart successfully while YouTube does not show the expected event. First establish which of these happened rather than adding reconnect flags at random.
Keep FFmpeg’s logs and note the time of the interruption. Look for whether the process continued running, printed an output error, or terminated. If you are using a service manager, check its records as well: they can show whether FFmpeg exited and whether the manager launched it again. A silent black picture in the YouTube player, by itself, does not tell you which layer failed.
There are three useful layers to separate. The network link carries packets between your encoder and YouTube. FFmpeg’s output connection sends the encoded feed over the configured protocol. The YouTube live event receives that feed and presents a preview or stream health status. A failure at one layer does not mean the others will recover in the same way.
For a church using a camera or capture card, restarting FFmpeg also means reopening the input and restarting the encoding process. Confirm that your capture device is available again, that audio is selected correctly, and that the command can initialise without a person opening a desktop session. A restart policy cannot resolve a loose cable, a disabled capture device, or a computer that has itself frozen.
If you send a prerecorded programme rather than a live camera feed, input behaviour matters too. The guide to building a continuous YouTube stream from prerecorded tracks covers looping and source preparation; here, the concern is what happens when the sending process or its network path stops.
Why HTTP reconnect flags are not a general RTMPS output switch
FFmpeg documents options such as reconnect, reconnect_at_eof, and reconnect_on_network_error in its HTTP protocol documentation. Their scope is HTTP. In particular, HTTP reconnect behaviour should not be presented as a universal instruction to reconnect an RTMPS output after a broken connection.
The distinction is easy to miss because the option names sound broad. reconnect concerns an HTTP connection disconnected before EOF; other documented HTTP options cover cases such as EOF, network errors, retry limits, and selected HTTP responses. Those descriptions do not establish that the same options repair an RTMPS output connection. Check the documentation for the protocol actually in use and the installed FFmpeg build.
Command-line options also have positions and scopes. An option placed in an input’s HTTP option group applies to that input, not automatically to an output later in the command. Adding an HTTP option before an RTMPS destination does not turn it into an RTMPS reconnect control. If you need to confirm what a particular installation supports, check its version and run ffmpeg -h protocol=http; do not assume that options found in current documentation exist in an older distribution build.
Think of transport reconnection and process restart as two different mechanisms. A protocol-specific reconnect option may retry a connection within a still-running FFmpeg process, when that protocol and operation support it. A process supervisor can launch FFmpeg again after it exits. The second approach is useful for an exited process, but it does not prove the output connection will recover or that YouTube will attach it to the event you expect.
This distinction also helps avoid a risky last-minute change. If the existing command has been stable, changing its protocol options during a service may alter input or output behaviour without solving the fault. Record the current command and make one controlled change at a time in rehearsal.
Keep the YouTube RTMPS endpoint and key configured
YouTube’s encoder setup guide asks you to provide the encoder with a stream URL and stream key. Retrieve the RTMPS endpoint from the channel’s Live Control Room and check that the command uses the intended URL and protocol. YouTube recommends RTMPS; do not assume that a visible RTMP address is interchangeable with the RTMPS address for your setup.
The key is not merely a label. YouTube describes it as password-like: it allows YouTube to accept the incoming feed. Treat it as a secret. Do not put a real key in a public script, a shared repository, a screenshot, or a message sent to volunteers who do not need it. Avoid routine logging that prints the full command with the key included.
A supervisor must be able to start the command in the right environment, but that does not mean the key has to be written into a file everyone can read. Have the person who administers the system choose an appropriate protected configuration or secret-handling method for that operating system. Check file access and log output as part of the setup, and rotate the key in YouTube if it has been exposed.
When diagnosing a restart that does not restore the feed, verify the endpoint and key in Live Control Room rather than repeatedly restarting. A wrong or outdated key, a copied URL with the wrong protocol, or an event that is no longer accepting the feed can prevent recovery. The FFmpeg stream-key update walkthrough is relevant if you are changing a key, although the exact server and command arrangement may differ from yours.
For a live camera stream, also check the capture and encode settings after a restart. If you have changed resolution, frame rate, or audio handling, compare them with the settings you have rehearsed. A valid key cannot compensate for an input that failed to reopen or an output that is being sent with unsuitable stream settings.
Run FFmpeg under an operating-system supervisor
A supervisor watches a process and can relaunch it when it exits. Depending on your operating system, this might be a service manager or a carefully written restart loop. The practical pattern is: start the known FFmpeg command, record its output, wait if it exits, then start it again according to a deliberate policy. This is process supervision, not a special FFmpeg RTMPS flag.
Use the supervisor provided for the machine rather than copying a generic service file without understanding it. Configure the correct user account, executable path, working directory, environment, input devices, and any required permissions. A service that runs under a different account from your manual test may not see the capture card, media files, or protected key configuration.
Choose a restart delay that prevents a rapid failure loop. If the internet remains unavailable or the key is rejected, immediate repeated launches add noise and make logs harder to read. A delay gives the system and operator a chance to distinguish a short interruption from a continuing fault. Retain logs for both FFmpeg and the supervisor, and ensure that the supervisor itself starts after a normal reboot if unattended operation is intended.
There is a trade-off: restarting the whole process is simple, but it resets the input, encoder, and output rather than preserving their state. That is usually easier to reason about than trying to keep a broken process alive indefinitely, but it can take time to reopen hardware and may change what YouTube sees. If your church has someone available to take over, document the manual action and who is responsible when automatic restart does not restore the event.
Do not put a real stream key into an example copied into a public guide or paste it into a terminal that saves shell history. The FFmpeg guide to repeated playback discusses command behaviour for another continuous-stream problem; it is a reminder to treat the full command, inputs, and process lifecycle as a system rather than just a destination URL.
If a restart loop is the only protection, it can mask an underlying fault by repeatedly launching a command that cannot succeed. Have the supervisor report repeated failures to a human, and make the recovery instructions accessible to the person on duty. The goal is not a process that restarts forever without explanation; it is a recoverable stream with visible evidence of what happened.
Test process restart and stream recovery
Test before an actual service, when it is safe to interrupt the feed. YouTube’s live-streaming tips recommend testing ahead of time and describe a failover test that stops the primary encoder or disconnects its Ethernet cable. Adapt that idea to your setup: arrange a short, intentional interruption, observe the logs, and confirm whether the process exits and the supervisor relaunches it.
Do not test only the easy part. A supervisor may show that FFmpeg has restarted while the channel remains offline or the wrong event is active. Watch the Live Control Room preview and stream health, listen for audio, and verify that the picture is moving. YouTube’s advice is to “Continuously monitor streams for audio and video quality.” A process status of “running” is not the same as a working broadcast.
Use a rehearsal checklist that a volunteer can follow:
- Record the current command version and confirm the intended event is selected.
- Confirm the RTMPS URL and key are configured without exposing the key.
- Interrupt the network or stop the encoder in a controlled way.
- Note whether FFmpeg exits, what the logs say, and whether the supervisor starts it again.
- Check the YouTube preview, event state, audio and video after the restart.
- Restore the normal connection and confirm that a person knows how to take over if recovery fails.
A brief disconnect tests one part of the path, not every possible outage. Test a restart after a process exit and, separately, decide how your team will respond if the internet remains unavailable. A supervisor cannot restore connectivity during an ISP outage, correct an invalid key, or decide which event YouTube should receive. Keep a fallback plan appropriate to the service, such as an operator who can end the attempt and follow the church’s agreed manual procedure.
If the same fault repeats, investigate the upstream connection rather than increasing restart frequency. Check the local router and wired link, contact the internet provider if needed, and review YouTube’s stream health. YouTube’s encoder guidance discusses upload speed and recommends assessing the connection; a restart policy does not add capacity to a saturated or unstable connection. The JioFiber livestream setup guide is useful context for planning a connection, though your provider and location may differ.
Verify behaviour in Live Control Room
After the test, establish what YouTube actually received. In Live Control Room, check whether the intended event remains active, whether the incoming feed appears in preview, and whether stream health reports a problem. Confirm the audio and moving picture at the player as well. If the preview is absent, compare the configured stream URL and key with the event’s current encoder settings before changing the FFmpeg command again.
Do not assume that restarting the encoder rejoins the same live event. The event state and the response to an interruption depend on the particular setup and circumstances. Official guidance does not promise a universal reconnect window or guarantee that every restarted process will continue the same event. Your rehearsal is the evidence for your channel’s behaviour, and even that test cannot promise the next outage will be identical.
If you use a backup encoder, test that separately. YouTube describes failover arrangements as a more involved approach, including checking whether the player rolls over to the backup. A single-process restart and a tested backup path solve different operational problems. Choose the additional complexity only if the service needs it and someone can monitor and maintain it.
Write down the observed result in plain language: what failed, whether FFmpeg exited, how the supervisor behaved, what appeared in the Live Control Room, and what action restored the feed. Keep the note with the service runbook, not with the secret key. That record helps the next volunteer distinguish a known recovery from an assumption.
If you need a managed way to avoid leaving a church computer running when the broadcast source is a prepared video, StreamNeo can take an uploaded video and keep the YouTube broadcast running without that computer; it is YouTube-only, and it does not remove the need to verify the event and content. For camera input or a setup that needs direct control over capture hardware, keeping FFmpeg on an appropriately managed machine may be the better fit.
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 restart after the internet drops?
If the interruption makes FFmpeg exit, run the command under an operating-system supervisor configured to relaunch it after a delay. Keep logs, protect the stream key, and rehearse that the restarted process can open its inputs and send a usable feed. This does not guarantee that YouTube will resume the same event.
Will FFmpeg reconnect to YouTube Live?
It may reconnect in circumstances supported by the output protocol and the installed build, but FFmpeg’s HTTP reconnect options are documented for HTTP and are not a general RTMPS output switch. If FFmpeg exits, a supervisor can start it again; whether YouTube accepts that feed into the intended event must be tested in Live Control Room.
How can I keep our church livestream running if the network disconnects?
Use a stable, rehearsed setup with a supervisor for process exits, a protected and verified RTMPS URL and key, and a named person who can respond if recovery fails. Test an intentional interruption before a service and check the YouTube preview, audio, video, and stream health. For a continuing ISP outage, you need a response plan as well as a restart policy.