If FFmpeg exits unexpectedly, a Linux service manager such as systemd can start it again; if FFmpeg remains running but its output is interrupted, that is a different problem. Use process supervision and output recovery for their separate jobs, then check YouTube Live Control Room and the viewer-facing stream before deciding that the broadcast is healthy.
A process status is only one signal. A running encoder can be sending unusable media, retrying a broken output, or failing to reach YouTube, so your checks need to cover the process, the output and what viewers actually receive.
First identify which part has failed
There are at least two failure cases that can look similar from the viewer’s side. In the first, FFmpeg terminates: perhaps the input file cannot be read, the process encounters an error, or the host stops it. A process supervisor can notice that exit and launch FFmpeg again, according to the policy you configured.
In the second case, FFmpeg is still running but cannot deliver its output successfully. A network interruption or an output-side error may leave the process alive while YouTube receives no usable stream. A restart policy that only acts when the process exits will not necessarily respond to this case. FFmpeg’s FIFO muxer offers output-recovery controls for certain interruptions, but it cannot resolve every permanent error or prove that viewers are receiving good media.
Start with evidence rather than a guess. Check whether the service is active, whether its logs show FFmpeg exiting and restarting, and whether YouTube Live Control Room reports a healthy stream or a problem. If the service is active but YouTube reports a problem, investigate the output path, connection and encoder messages before changing the restart policy. If the service repeatedly exits, address the error shown in its logs as well as deciding how it should restart.
That distinction matters for a channel that must run overnight. A process that restarts quickly can still return with the wrong input, an invalid key, or an output configuration that continues to fail. Conversely, repeated restarts during a short network disruption can make diagnosis harder without fixing the underlying connection.
Run FFmpeg as a managed service
On a Linux host, systemd can manage FFmpeg as a service instead of leaving it attached to an interactive shell. This makes its state and logs easier to inspect and gives you a place to define when a failed process should be started again. The systemd documentation on service restart behaviour describes the available restart settings; confirm the behaviour against the manual and version installed on your host.
Here is a small pattern to adapt, not a tested, universal service file:
[Unit]
Description=FFmpeg YouTube Live stream
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/stream-to-youtube
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
The example calls a wrapper script so that the service file can remain readable. Your ExecStart must use the actual path to your installed FFmpeg binary or wrapper, and the script must include the real input, output endpoint, mappings and encoding choices. Do not paste the example as-is and assume it will work: the path, source, codecs and credentials are specific to your setup.
The After and Wants entries express an ordering preference around network availability at service start. They do not ensure that the connection is working, stays available, or can reach YouTube. A service can start after the host’s network-online target and still encounter a later outage. Verify how the target is defined by your distribution and test what happens when the connection is absent at startup.
Keep the stream key private. YouTube describes stream keys as like a stream’s password and address. Avoid putting one in a public script, a screenshot or a shared log. Use access controls suitable for your host, and reset the key if you believe it has been exposed. You can also read about keeping an FFmpeg stream key out of shell history, which covers a related credential-handling risk.
Choose a restart policy and a delay
Restart=on-failure is one possible policy for an FFmpeg service. It asks systemd to restart the service after a failure rather than treating every normal termination as something to undo. That distinction helps preserve an operator’s deliberate stop: you should be able to stop a broadcast for maintenance without an unconditional shell loop immediately launching it again.
RestartSec=5 in the sample means a five-second pause before a restart under that policy. It is an illustrative choice from the example, not a required value or a guarantee that the stream will recover in five seconds. A short delay can bring a service back promptly after an isolated failure, while a repeated failure can produce a cycle of restarts that consumes time and makes the logs harder to read. Choose a delay and policy for your input and operating conditions, then inspect the result during a controlled test.
The right policy depends partly on how FFmpeg ends. A non-zero exit may indicate an error, while a normal exit can be expected for a finite job but surprising for an always-on channel. Decide whether a clean exit should remain stopped, and make sure the service behaviour matches that decision. Avoid adding a shell retry loop without understanding how it treats deliberate stops and signals.
A restart only repeats the start command. If the command contains a stale path, expired or incorrect key, unsupported codec option, or unavailable input, restarting does not repair that cause. Look for the first useful error in the service log, correct the configuration, then restart deliberately. For a broader comparison of a persistent host and its responsibilities, see how a 24/7 YouTube stream can run on a cloud VM in Mumbai. Hosting a process on a remote machine does not itself monitor YouTube’s stream health.
Consider FIFO recovery for output interruptions
When the process stays alive but the output is interrupted, FFmpeg’s FIFO muxer may be relevant. Its recovery options concern the output path; they are separate from systemd’s decision to restart a process that has terminated. The FFmpeg FIFO muxer documentation explains the options, including recovery attempts and behaviour when a queue fills. Check that documentation and your installed build before using them.
The official documentation shows the general structure of an RTMP output using FIFO. This adapted sketch keeps the input, endpoint and key as placeholders; it is not a copy-and-run command:
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://SERVER/live/STREAM_KEY'
Replace the placeholders with the input and YouTube ingest endpoint configured for your broadcast, and use mappings and codecs that suit that input. Confirm the supported options in your FFmpeg build. The -re option appears in the documented RTMP example for reading a file at real-time rate; do not assume it belongs on every live capture input. The FFmpeg protocol documentation is another reference for the output protocol in use.
Recovery attempts can help with certain temporary output problems, but they cannot make a permanent rejection, bad endpoint or broken configuration disappear. Dropping packets when a FIFO queue overflows may trade a blocked output for missing media. That could affect what viewers hear or see, so use such a setting only with an understanding of the trade-off and verify the resulting broadcast.
Do not treat an FFmpeg process that has stopped as an output interruption that FIFO will restart. Nor should you assume that systemd will detect every unhealthy output while FFmpeg is still running. When you combine these mechanisms, assign each a clear role: systemd handles the process exit policy; FFmpeg recovery handles certain output interruptions; YouTube’s status and an actual viewer check tell you whether the stream is working as intended.
Check YouTube Live Control Room health
During a broadcast, open YouTube Live Control Room and review the stream-health status and messages. YouTube’s guidance is to monitor stream health and review messages; these are evidence about the platform’s view of the incoming stream, not a guarantee that every viewer’s device or connection plays it correctly. Read the specific message before changing encoder settings or restarting the service.
YouTube’s current live encoder guidance covers RTMP or RTMPS, supported video and audio codecs, constant bitrate, and keyframe intervals. It recommends a two-second keyframe interval and says not to exceed four seconds. Bitrate recommendations vary with codec, resolution and frame rate, so match the current settings guidance to your intended output rather than copying a number from an unrelated setup. The YouTube recommended encoder settings page is the place to check the current requirements and recommendations.
Your connection is part of the same check. YouTube recommends upload bandwidth headroom of 20% and warns that network disruption can break a stream. Check outbound capacity rather than relying on download speed, and account for both primary and backup encoder bitrates plus the additional margin if you use a backup encoder. These are YouTube’s recommendations, not a promise that a connection will remain stable.
A setup that works at home may behave differently on another network or host. Test the exact input, codec, bitrate, keyframe interval and ingest configuration you intend to use before a scheduled event. If you are deciding between FFmpeg and another encoder workflow, the guide to starting a 24/7 YouTube Live stream with OBS in India may help you compare the operational shape of a different setup; it does not replace checking YouTube’s current requirements.
Verify what viewers actually receive
A green-looking process state is not enough. Open the public or preview stream from a separate device or browser where practical and check that video is moving, audio is present, and the audio and picture stay in sync. A still image may be appropriate for an ambience channel, but confirm that it is the image you intend to show and that the expected audio continues. For a spoken or news channel, listen for missing speech, clipping or an unintended silent section.
Check again after a restart or recovery event. FFmpeg may have resumed output while selecting a different input state, or the stream may be present but have a quality issue. Compare what you see and hear with the Live Control Room status and encoder logs. If the viewer-facing stream is wrong, avoid declaring recovery solely because the service is active or the platform has accepted an input.
Think about continuity as well as immediate playback. YouTube says streams under 12 hours are automatically archived, but its documentation does not establish that restarting an external FFmpeg process preserves one continuous broadcast or archive. If a continuous archive matters to you, test your exact restart scenario and check the resulting YouTube recording rather than assuming a process restart is invisible to viewers or to the archive.
Some channels use a recorded video loop as their source. In that case, confirm not only that the live output is playing but also that the video and audio behave as intended at the loop boundary. A separate guide on running a 24/7 CBSE revision stream from recorded videos is relevant to that source pattern, while the checks here still apply to the FFmpeg process and YouTube output.
Review logs and refine the checks
Use service status and logs to reconstruct what happened. The systemd journal can show when the service started, exited and restarted, alongside output captured from the process. Inspect the first error around a failure, not only the final restart message. Repeated exit messages can point to an input or command problem; connection or muxing messages while the service remains active call for output-path investigation. The precise commands for viewing logs vary by distribution and service name, so consult your host’s systemd guidance.
Keep a simple incident note during testing: when the problem began, whether the process remained active, what FFmpeg logged, what Live Control Room reported and what a viewer device showed. This helps distinguish a process crash from an output interruption next time. Do not add a monitoring destination or automated detection rule unless you have verified that it exists and behaves as expected; the checks described here rely on service status, FFmpeg logs, YouTube Live Control Room and viewer-facing playback.
Test failure handling before relying on it for an overnight channel. With a non-public test setup where possible, verify that a controlled process exit follows the intended restart policy, that an operator stop remains stopped, and that a temporary output interruption does not mislead you into thinking the stream is healthy. Do not deliberately disrupt a public event just to test recovery. Change one thing at a time so you can identify whether a result came from the service policy, output settings, network or encoder configuration.
If the same failure repeats, fix the cause instead of increasing retries by reflex. Check that the source is available, the stream key and endpoint are current, the chosen codecs are supported, and outbound bandwidth has the recommended margin. Protect the key in scripts and logs, and reset it if exposed. A reliable operating routine is a set of checks and a tested response, not a restart setting by itself.
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 automatically restart FFmpeg if it crashes?
Run FFmpeg as a managed service and choose a restart policy that applies to failures, such as the systemd Restart=on-failure pattern shown above. Add a delay that suits your setup, and inspect the service logs to learn why it exited. Restarting repeats the command; it does not fix a missing input, invalid key or incorrect output configuration.
What if FFmpeg is running but YouTube says the stream is unhealthy?
A restart policy may not act because the process has not exited. Read the FFmpeg output and YouTube Live Control Room messages, then investigate the network, ingest endpoint and encoder settings. FIFO recovery can address certain output interruptions, but it does not prove the broadcast is healthy.
Does a successful systemd restart mean viewers can watch?
No. It means the service manager started the process again, not that YouTube is receiving usable media or that viewers can hear and see it properly. Check stream health in Live Control Room and verify playback from a viewer-facing device.
Should I use FIFO recovery and systemd together?
They can serve different failure cases: systemd can restart a process after failure, while FIFO options can attempt recovery from certain output errors while FFmpeg remains alive. Whether both suit your setup depends on the input, FFmpeg build and output path. Test the combination and check the resulting stream rather than assuming either mechanism guarantees recovery.