If your Telugu church sermon stream stops, first find out whether FFmpeg exited, its camera or other input disconnected, or its connection to YouTube failed. Each problem needs a different recovery method: a process supervisor can relaunch an exited FFmpeg process, but it cannot make an unavailable camera or network connection work again.
For a continuous channel, treat restarting as one part of recovery, not a guarantee that the broadcast will return. Check the logs, identify the failed link, and test the relevant recovery path while someone can observe the channel.
Identify what stopped: FFmpeg, input or output
A live stream has a path from source to viewer. In a sermon setup, the source might be a camera and microphone, an RTSP feed, or a prepared recording. FFmpeg reads that input, encodes or packages it, and sends the result to YouTube or another destination. A break at any point can look like the same symptom to a viewer: the picture freezes or the stream ends.
Start by checking whether the FFmpeg process is still running. If it has exited, a service manager can launch it again. If it remains active, a process supervisor may have nothing to do: the input could be missing, or the output connection could be stalled. Restarting an active process may interrupt the broadcast without fixing the original cause.
Keep three cases separate:
| What you observe | Likely failure area | Recovery to investigate |
|---|---|---|
| FFmpeg is no longer running and its log ends with an error | Process, or an error that caused it to exit | Correct the cause, then use a supervisor to relaunch it |
| FFmpeg is running, but input reads or frames have stopped | Camera, capture device, file or input connection | Check the source and use protocol-specific reconnect behaviour where supported |
| FFmpeg is running and reading input, but the destination no longer receives video | Output connection or destination session | Inspect output errors and consider supported output-side recovery |
These signs are clues, not proof. A process can remain alive while waiting on an input, and a log may show an output error before the viewer notices a freeze. Use process status and the most recent log lines together. If the stream is important, record the time of the failure and the visible symptom so you can compare later tests.
The operating system, input protocol, installed FFmpeg build and destination requirements all affect the available options. There is no safe, universal command for this title alone. If you need a broader view of the channel setup before changing recovery settings, the guide to running a YouTube live loop with systemd and FFmpeg covers the relationship between a service and a looping broadcast.
Check FFmpeg logs and input status
Before changing restart behaviour, preserve enough evidence to tell what happened. Check the service manager's status, whether the FFmpeg process exists, and the log lines immediately before the failure. Look for input open or read errors, connection timeouts, output write errors, authentication problems and repeated reconnect messages. The exact wording varies by protocol and build, so interpret it in context rather than matching one message as a universal diagnosis.
Check the source independently. Is the camera powered and reachable? Is the capture device still present? If the input is a file, is the path mounted and readable by the service account? For an RTSP camera, confirm that the address and credentials are still valid from the machine running FFmpeg. A source that has rebooted, changed address, lost power or rejected authentication will not become available just because FFmpeg is restarted.
Also note whether the log stops producing new lines. A quiet log could mean FFmpeg exited, is blocked waiting for input, or is running without useful progress messages. Pair it with process status and, where available, input frame or packet counters. Confirm the destination is not receiving new video before concluding that the source is at fault.
FFmpeg's online documentation is regenerated for the current project version; the project advises checking documentation appropriate to the installed build. Run the local help or consult the documentation installed with your FFmpeg package before using an option from a newer web page. The FFmpeg documentation page is a useful starting point, but it does not establish that every option exists in your version.
Protect the stream key and source credentials while gathering evidence. Avoid pasting full command lines or unredacted logs into a public forum: they can contain passwords, private addresses or destination keys. Store credentials in access-controlled configuration rather than a script that is shared or committed to a public repository.
Restart an exited process with a supervisor
If FFmpeg has exited, a process supervisor can start it again. On Linux, systemd is one common choice; other operating systems have their own service managers. A systemd unit can specify that a failed service should be restarted and can pause before the next attempt. The pause matters: an immediate loop can repeatedly launch FFmpeg against the same unavailable source, fill logs and make troubleshooting harder.
A user on the FFmpeg mailing list described a systemd configuration using Restart=always and RestartSec=5, alongside an input timeout intended to make FFmpeg exit when an RTSP source could not be reached. Treat that as one person's reported setup, not a tested recipe for your camera or host. The correct unit depends on your service manager, FFmpeg command, permissions and the way the source fails. See the mailing-list discussion of an RTSP timeout and systemd restart for context, then verify settings against your own systemd and FFmpeg documentation.
A supervisor only acts when the process reaches an exit condition that the supervisor recognises. If FFmpeg hangs, remains alive while receiving no frames, or keeps retrying inside the process, an ordinary restart-on-exit policy may not trigger. That is why the log and status check comes first. Avoid adding a separate watchdog that kills a process based on a guessed threshold until you know what normal input gaps look like for your setup.
Restarting also has a destination-side effect: the outgoing connection is interrupted and a new connection may need to be accepted by YouTube. Keep your stream key private, check the current destination instructions, and observe what viewers see after a controlled restart. A supervisor can relaunch a command; it cannot correct a wrong key, invalid ingest configuration or a destination restriction.
If you are deciding whether to maintain a local FFmpeg loop or use a file-based approach, compare the needs of the channel with the options for looping devotional videos on YouTube. A sermon captured live from a camera has different recovery needs from a prepared video that can be sent repeatedly.
Use exit conditions for failed inputs
A supervisor can only restart FFmpeg after it exits. For a source that disappears, you need to decide whether FFmpeg should keep trying within the same process or stop after a defined failure so that the supervisor can launch it again. That choice depends on the input protocol and the behaviour of the local FFmpeg build.
Some protocols have input reconnect options; their names, meanings and availability are not universal. The FFmpeg-user discussion about reconnecting an HTTP live input concerns HTTP behaviour, not a blanket rule for RTSP cameras, USB capture devices or every network stream. Check the protocol-specific documentation for the exact input you use, and confirm options with the installed version.
A timeout can be useful if a stalled input otherwise leaves FFmpeg alive indefinitely, but a value that is too short may treat an ordinary pause as a failure. A value that is too long can delay detection. Do not copy a timeout simply because it appears in another person's service unit. Observe normal source behaviour first, then set a policy that distinguishes expected gaps from a genuinely lost connection.
When FFmpeg exits because the input cannot be opened, a supervisor can retry after a delay. If the camera is still offline, the retries will fail too. Use logs and, if appropriate for your operations, an alert so someone knows that the source remains unavailable. A restart policy is most useful for transient faults that clear on their own; it is not a repair for missing power, changed credentials or a broken camera.
For a live sermon, consider what viewers should see during the gap. If the input is expected to return shortly, a reconnect attempt may preserve the session, depending on the protocol and destination. If the process exits and restarts, the destination may show a brief interruption or require a new session. Test the actual viewer-facing result rather than assuming the log's “started” message means the broadcast has resumed.
Check source and network recovery
When the source or internet connection fails, inspect that part of the path before tuning FFmpeg. Check whether the camera can be reached from the streaming computer, whether its address has changed, whether the router or switch is online, and whether the computer has a working route to the destination. For a church relying on a mobile or shared connection, congestion or a temporary service outage may affect the stream even if the local camera remains healthy.
Separate local network recovery from internet recovery. A camera may still answer on the church network while the uplink to YouTube is down. Conversely, YouTube may be reachable while a camera cable or local wireless link has failed. Use available router, camera and operating-system status tools to narrow the fault; avoid repeatedly changing multiple settings at once, because that makes it harder to identify which change helped.
Output recovery is distinct from input recovery. FFmpeg's FIFO pseudo-muxer documents output-side options including attempt_recovery, recovery_wait_time and max_recovery_attempts. Its recovery behaviour depends on the error class and settings; some errors are not retried unless broader behaviour such as recover_any_error is enabled. This can be relevant when the process is still running but its output path has a transient failure. It does not reconnect a camera input merely by being enabled.
The FFmpeg formats documentation describes those FIFO options and their boundaries. Check the format documentation for the version you actually run before building them into a command. Avoid enabling broad retries as a first response: if the error is permanent, such as invalid credentials or a misconfigured destination, retries can obscure the cause and produce a repeating failure instead of a recovery.
If your setup uses a VPS, distinguish a changed public IP from an FFmpeg crash. A changed address can affect how a source or remote service reaches the host, while restarting FFmpeg alone does not update network configuration. The guide on keeping a YouTube stream running when a VPS changes its IP address addresses that separate failure mode.
Verify YouTube receives the resumed feed
After a reconnect or restart, verify the destination, not just the local process. A running FFmpeg process confirms only that the command is alive; it does not prove that YouTube is receiving usable video and audio. Check the live control room or current YouTube guidance for the channel's ingest status, and confirm the viewer-facing stream resumes with picture and sound.
Allow for the difference between a process restart and a viewer seeing motion again. The encoder may need to establish a new connection, and the destination may take time to show incoming video. Check that the sermon audio is present, the picture is not frozen, and the stream has not accidentally started a second session or left an old session active. The exact behaviour depends on the destination configuration and current platform requirements.
Do not expose the stream key while checking or sharing the setup. If the key has appeared in a log, screenshot or public command, follow YouTube's current guidance for changing it. Keep the destination URL and key in protected configuration and use the current official instructions for the channel rather than a hard-coded ingest address copied from an old example.
A useful operational note records the failure time, whether FFmpeg exited, what the source and destination status showed, what action restored the feed, and whether the viewer could see and hear the resumed sermon. That history helps distinguish a recurring source problem from a process that needs a better exit policy. It is also more useful than relying on a single “active” status indicator.
Test recovery before relying on it
Arrange a safe test window when a brief interruption will not cut across an important service. Test one failure at a time. First, stop FFmpeg in a controlled way and verify that the supervisor relaunches it, then confirm YouTube receives the resumed feed. This checks process recovery, not source recovery.
For an input test, use a planned interruption that is safe for the camera and network: for example, temporarily disconnect a test source rather than interrupting an active service. Observe whether FFmpeg reconnects, exits, or stays alive without frames. If it exits, check that the supervisor's delay and retry behaviour are sensible. Restore the source and verify picture and sound at the destination.
For an output-path test, only use a controlled method that does not expose credentials or create an unwanted public session. Check whether the process remains alive, whether its output recovery behaviour matches the local documentation, and whether the destination accepts the resumed feed. If you cannot safely simulate an output failure, do not claim that this part of the recovery plan has been tested.
Watch the logs during and after each test. A successful recovery should leave evidence of the original fault and of the return to normal, without a rapid loop of repeated launches. Confirm that no credentials were printed or committed. Document what remains manual, such as restoring a camera's power or asking someone to check a router; a realistic runbook is better than assuming every fault will clear itself.
For a non-technical operator, put the practical steps in plain language beside the streaming computer: who to contact, which status to check, where to find protected logs, and when not to keep restarting. If maintaining a computer and camera path overnight is the recurring burden, StreamNeo removes the need to keep that computer running for a file-based YouTube broadcast: you upload the video and provide the stream key, while the broadcast runs with automatic monitoring and restart if it drops. It is YouTube-only and does not repair a live camera or church internet outage.
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
Will Restart=always reconnect my RTSP camera?
No. It can relaunch FFmpeg after the process exits, but the camera must become reachable and the FFmpeg command must be able to open it. If FFmpeg stays alive while the input is stalled, a restart-on-exit policy may not run at all.
Should I use FIFO recovery or a systemd restart?
They address different layers. FIFO recovery is for supported output-side errors while FFmpeg is running; systemd can relaunch an exited process. Choose based on logs and test the relevant failure path rather than treating either as a universal reconnect switch.
Can I copy an HTTP reconnect option for an RTSP source?
Not safely. Reconnect behaviour depends on protocol and FFmpeg version, so consult the local documentation for the input you use. An HTTP example does not establish that the same option works for an RTSP camera.
How do I know the sermon stream has resumed?
Check that FFmpeg is running and that YouTube reports incoming video, then view the public or intended playback feed for moving picture and audible sermon audio. A process status alone does not show that viewers are receiving a usable stream.