If FFmpeg exits unexpectedly, a Linux service managed by systemd can start it again after a configured delay. That restart only addresses a process that has stopped; it does not repair every publishing failure or prove YouTube has returned your intended broadcast to live.
The useful approach is to identify which layer failed, supervise the FFmpeg process, and verify the result at YouTube. This guide uses systemd as the Linux example; on another operating system, use an equivalent supervisor and check its own restart rules.
Identify whether FFmpeg exited
Start with the process, not the assumption that a black or frozen YouTube player means FFmpeg crashed. A crash is an exit: the FFmpeg process is no longer running, commonly with a non-zero exit status or a termination signal recorded by the operating system or service manager. By contrast, FFmpeg may still be running while the input has stopped changing, the connection to YouTube has failed, or output packets are no longer getting through.
That distinction determines what can help. A service manager can observe that its main process exited and apply a restart policy. If the process remains alive, a supervisor configured only to restart on exit may see nothing to act on. Output recovery within FFmpeg, or a separate health check that can detect useful delivery has stalled, addresses a different problem.
Check the service state and recent logs before changing settings. For a systemd unit called ffmpeg-live.service, systemctl status ffmpeg-live.service gives a current view, while journalctl -u ffmpeg-live.service shows its recorded output. Look for the exit result, timestamps, and messages immediately before it. A status of “active” tells you the service is considered running, not that YouTube is receiving healthy media.
Keep a short incident note when a failure happens: whether the process existed, its exit result if available, the time, the last FFmpeg error, and what Live Control Room showed. This makes a recurring cause easier to distinguish from a one-off interruption. If the visible problem is that a broadcast is waiting for input rather than that FFmpeg has exited, the fix order for a stream stuck on Starting Soon or Waiting for Data is a useful companion, because it keeps encoder delivery and broadcast state in view.
Run FFmpeg as a supervised service
For an unattended stream, run FFmpeg under a service manager rather than starting it in an interactive terminal and relying on the shell session to remain open. A service manager keeps track of a main process, can start it at boot according to unit configuration, and can apply a configured response when the process ends. This is particularly useful when a stream is hosted on a Linux machine that is expected to run without someone logged in.
A systemd unit generally needs a description, the command to execute, the conditions for starting, and an appropriate service type. The ExecStart command should launch FFmpeg in the foreground so systemd can track it as the service’s main process. Avoid wrapping it in a shell or a backgrounding construct unless you understand how that affects process tracking; if systemd tracks the wrong process, its view of service health and restart behaviour may not match the FFmpeg process you care about.
Use a protected configuration mechanism for credentials. YouTube uses a stream key to connect an encoder to a broadcast, so treat it as a password: do not paste it into a public unit file, screenshots, support posts, logs, or shell history. A unit may refer to a separate protected configuration file or another suitable secret-storage method for the host. Limit who can read that material and replace the key if it has been exposed. The YouTube RTMPS setup guidance explains where to get the encoder details and stream key in Live Control Room.
Keep configuration understandable enough to audit during an outage. Separate the media options from the destination and credentials where your deployment allows, and make sure the service user can read the video and required configuration. If you update a unit, reload systemd’s unit configuration before restarting the service, then inspect the resulting status and logs. A service that repeatedly fails to start is not a recovered stream; it is a visible failure that still needs diagnosis.
This is one operational pattern, not a requirement to use systemd. If you already have a managed streaming workflow, the relevant question is whether it monitors the FFmpeg process and how it surfaces failures. The comparison of OBS and FFmpeg for a 24/7 YouTube radio station can help you decide whether process-level control is worth the operational responsibility in your setup.
Choose a systemd restart policy
The Restart= setting tells systemd what kinds of service endings should lead to another start. For an FFmpeg service where a non-zero exit should trigger recovery, Restart=on-failure is a common choice. It is narrower than restarting after every clean exit, which may be important if FFmpeg ending normally is an intentional part of a scheduled workflow.
The exact interpretation depends on the unit, how FFmpeg exits, any service conditions, and the systemd version on the host. Read the systemd service documentation and confirm behaviour for your installed version rather than assuming that a setting copied from another machine covers all outcomes. In particular, decide deliberately what should happen after a clean exit, a non-zero exit, or termination by a signal.
| Failure or end condition | What may handle it | Does FFmpeg remain running? | What to check |
|---|---|---|---|
| Input disconnect or read error | Protocol-specific input reconnect behaviour, if supported and configured | Usually, if FFmpeg continues rather than exiting | FFmpeg logs and whether the input resumes |
| Output failure with configured FIFO recovery | FFmpeg FIFO muxer recovery for supported failures | Yes, while recovery is being attempted | FIFO options, logs, and whether output resumes |
| FFmpeg process exits with an eligible failure | systemd restart policy or another supervisor | No, until the next start | Service result, restart record, and new FFmpeg logs |
| Process runs but YouTube is not receiving the intended broadcast | A suitable health monitor and operator investigation | Yes | Encoder connection and broadcast in Live Control Room |
The table separates mechanisms, not products to buy. A protocol reconnect option is tied to a protocol and direction; do not assume an input-oriented reconnect option repairs a failed publishing connection. FFmpeg documents these options in its protocol documentation, and the available behaviour can depend on the installed build. Verify the particular option and test it with your real input and destination.
For a channel that is simply looping a prepared video, the guide to sending a prerecorded video playlist to YouTube covers a different delivery arrangement. Whatever the architecture, a restart setting is only one part of operating it: it does not validate your file, key, event selection, or YouTube’s live state.
Set a deliberate restart delay
RestartSec= controls how long systemd waits before attempting a restart. A delay gives a short interruption time to clear and avoids an immediate repeated launch when the underlying problem is still present. It is a configuration choice, not a promise about how long a broadcast will take to resume. Choose a delay that fits the failure you are managing, then observe what happens during a test rather than treating a copied value as universally right.
Think about the sequence after the process exits. The host may still be unable to read the video, resolve a destination, or establish an outgoing connection. If FFmpeg is relaunched immediately, it may fail in the same way and continue into a restart loop. A deliberate wait can make that loop less frantic, but it does not fix a bad path, invalid credentials, unsupported options, or a continuing network fault.
Check the service’s restart limits and conditions as well as the delay. Repeated failures may eventually be rate-limited or leave the service in a failed state, depending on unit and manager configuration. This behaviour is useful because it makes persistent failure visible instead of hiding it behind an endless cycle. During setup, test a controlled process exit and confirm that the service manager records it and makes the next attempt as configured. Do not test by exposing a live stream key or disrupting an important broadcast without a recovery plan.
A suitable restart delay also affects how you plan for an outage. If your channel needs an operator to intervene when attempts continue to fail, make that escalation explicit: check the service, inspect the latest error, and then check the YouTube event. Automatic retries reduce one kind of manual work, but they do not decide whether the current destination and broadcast are the ones you meant to use.
Check service logs after a restart
After systemd attempts a restart, review both its own service record and FFmpeg’s output. The service status and journal can show when the process stopped, whether a new process was launched, and whether it exited again. FFmpeg’s messages may point to a missing input file, an invalid option, an authentication or destination problem, or an output error. Preserve enough context to diagnose, but avoid logging the stream key or a full destination string that contains a credential.
Look for a sequence, not just a single “started” line. Did the original process exit? Did a new FFmpeg process start? Did it open the expected input and establish the output connection? Did it continue producing useful media? Each answer narrows the problem. A fresh process can fail immediately for the same reason as its predecessor, and the service manager may make more attempts without resolving that cause.
Be cautious with any health check based only on process presence. A process can be alive yet stuck, blocked on an input, or unable to deliver to the destination. If your operational requirement is to detect that situation, define a deployment-specific check that observes a meaningful signal and alerts or takes an appropriate action. Test false alarms as well as missed failures; a monitor that restarts a healthy process based on a weak signal can create the outage it was meant to prevent.
For a small devotional channel, for example, a useful incident record might say that FFmpeg exited after an output error, systemd started it again, the new process connected, and the intended event then appeared live in Control Room. If the final observation is missing, record that too. That difference matters more than a green service state when someone needs to decide whether to wait, investigate, or notify viewers.
Understand FIFO muxer recovery limits
The FFmpeg FIFO muxer can provide a recovery path for some output failures while the main FFmpeg process continues running. Its documentation includes an RTMP example configured with -attempt_recovery 1 and -recovery_wait_time 1; the example retries recovery every second indefinitely during a temporary network outage while processing continues at real-time rate. These are example settings documented by FFmpeg, not a measured recovery guarantee or a universal prescription.
FIFO recovery and systemd restarts address different failure layers. FIFO is relevant when the configured output path can handle the failure and FFmpeg remains alive. systemd is relevant when the tracked FFmpeg process exits in a way covered by the unit policy. If FFmpeg stays alive but the destination is not receiving useful media, systemd may see a running service and do nothing. If the process exits, FIFO cannot supervise and relaunch that process on its own.
Before adapting the example, check current FFmpeg format and muxer documentation, your installed FFmpeg version and build, and the actual input and output combination. Recovery options have to be supported and applied in the right place in the command. Test the behaviour outside a critical broadcast: simulate an interruption you can safely control, observe whether FFmpeg remains alive, and confirm whether it resumes producing output when the connection returns.
Do not treat retries as proof that the audience sees continuous playback. A temporary network fault may leave a gap, YouTube may no longer associate the encoder with the expected event, or the output may fail in a way the configured FIFO path cannot recover. Logs and destination-side status still matter. If your stream combines a live presenter with prerecorded material, the guide to mixing a presenter with prerecorded music may help identify which parts of the media workflow need their own checks.
Verify YouTube broadcast status
After a restart, check the intended broadcast in YouTube Live Control Room. Confirm that the encoder is connected, the stream health is acceptable, and the correct event is live. A successful systemd restart establishes only that the manager attempted to start its service; even a running FFmpeg process is not, by itself, evidence that the intended audience-facing broadcast has returned.
Use the current encoder details for that broadcast, including the stream key from Live Control Room. YouTube recommends RTMPS for live streaming. Its live encoder settings help page also provides current guidance on encoder settings, including keyframe guidance. Check the official page for current requirements and apply settings appropriate to your resolution and frame rate rather than relying on a command copied from an old example.
Make the post-restart check part of the runbook: note the time, the service result, relevant FFmpeg messages, and the state shown for the intended broadcast. If Control Room shows a connection but the event is not live, follow the controls and status information for that event; do not assume that restarting FFmpeg will automatically resume it. The service cannot confirm that the right event was selected or that YouTube has made it live again.
If managing process supervision, credentials, file access, and broadcast checks on a host is more than you want to own, StreamNeo removes the need to keep your own computer running for a file-based 24/7 YouTube stream: you upload the video and provide the channel’s stream key, then verify the broadcast in YouTube as usual. It is YouTube-only, and it does not remove the need to check that the intended event is live.
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 if it crashes?
Run FFmpeg as the main process of a supervised service and configure a policy that covers the exit you want to recover from. On systemd, Restart=on-failure is a common choice for non-zero exits, with RestartSec= setting the wait before another attempt. Check your host’s systemd behaviour and confirm a test in the service journal.
Will YouTube go live again when FFmpeg restarts?
Not necessarily. A restart shows that a process was started, not that it connected to the intended event or that the event is live. Check the encoder connection, stream health, and broadcast state in Live Control Room.
What if FFmpeg is still running but the stream has stopped?
A restart policy based on process exit may not act because systemd still sees its main process running. Inspect FFmpeg’s logs and consider supported FIFO output recovery or a deployment-specific monitor for stalled delivery. Test that monitor carefully, since process presence alone is not a useful-media check.
Does FIFO recovery replace a service restart policy?
No. FIFO recovery can attempt to handle certain configured output failures while FFmpeg remains alive; a supervisor can relaunch FFmpeg after an eligible process exit. Check the installed FFmpeg build and test the output path, then verify YouTube’s observed broadcast state separately.