If FFmpeg exits on your Raspberry Pi, run it under a service manager such as systemd so the process can be started again automatically. Then check YouTube Live Control Room: a restarted process is not proof that YouTube is receiving healthy media or that the intended broadcast has resumed.
First identify whether FFmpeg exited, the source failed, the process is still alive but stuck, or YouTube ingest is unhealthy. These failures need different checks, and reconnect options for an input protocol do not replace process supervision.
Identify which part failed
A live stream has a local side and a remote side. On the local side, FFmpeg reads a source, encodes or packages media, and sends it over the network. On the remote side, YouTube receives that media and associates it with an encoder configuration and broadcast. A break anywhere along that path can look like “the stream stopped” to a viewer, but the remedies differ.
Start with the service state and recent logs. If there is no FFmpeg process, determine whether it exited, failed to start, or was stopped by an administrator. If it is active, look for evidence that it is still reading and writing media rather than assuming the process is healthy because its status says “running”. Then check that the input file, camera, or other source is available to the service account.
Finally, check the remote view in YouTube Live Control Room. Its preview and stream health help distinguish a local process recovery from healthy ingest. A camera that is offline, an expired or changed key, a network failure, and a YouTube ingest problem are not fixed merely by starting another FFmpeg process.
Keep a short incident note with the time, service state, last relevant log lines, source status, and what Live Control Room showed. Avoid recording the stream key in shared notes or pasting it into public support requests. This evidence helps you avoid repeatedly changing settings that are not connected to the failure.
Put FFmpeg under systemd
On a Raspberry Pi OS installation that uses systemd, a system service can start FFmpeg at boot and supervise its process. The service manager handles a different job from FFmpeg: systemd can react when the command exits, while FFmpeg’s own options govern what happens within a running process, such as handling certain input disconnections.
Before creating a unit, make the exact FFmpeg command work manually. Use the same media source, output destination, user permissions, and environment that the service will use. A command that succeeds in an interactive shell may fail under systemd because it relies on a shell profile, a mounted directory, a relative path, or credentials unavailable to the service account.
The unit should identify the executable and its arguments explicitly, use a suitable service account, and declare any required working directory. Keep secrets out of a world-readable unit file where possible, and make sure the account can read the source and write any logs or temporary files the command needs. The specific arrangement depends on the Pi’s operating system, systemd version, source, and FFmpeg build; there is no safe universal unit to paste without checking those details.
A Raspberry Pi-oriented project such as YouTube-AutoEncoder illustrates a systemd-based approach, but it is an implementation example rather than an official endorsement or a configuration guaranteed for every installation. Treat it as a reference for the idea of supervision, not as a substitute for understanding your command and source.
Once a unit is in place, reload systemd’s unit definitions after editing, start the service, and inspect its state and journal. If you change the command, reload and restart deliberately, then verify which process is actually running. Do not infer success merely from a command returning without an error: inspect the output and then confirm YouTube’s side separately.
Choose restart behaviour deliberately
A restart policy tells systemd what to do after a service process terminates. For a stream intended to keep running, the policy may request another start after an unexpected exit. That is local recovery: systemd starts a new process. It does not establish that the source is ready, that the output connection succeeds, or that YouTube attaches the new media to the broadcast you intended.
Set a delay between attempts and consider a restart limit appropriate to the deployment. Without a pause or bound, a permanent error such as a missing input file or invalid command can cause rapid repeated starts, adding noise to logs and making diagnosis harder. A limit can prevent endless retries, but it also means you need to notice when the service has stopped trying and decide what to do next.
The right directives and their behaviour depend on the installed systemd version and the desired policy. Check the local systemd documentation before using options from a unit written for another distribution. Decide whether a deliberate clean stop should remain stopped, whether a failed startup should be retried, and how quickly an operator should be alerted after repeated failures. A policy that restarts every exit without considering why it exited can conceal a broken command rather than repair it.
FFmpeg’s protocol reconnect options are another layer. The FFmpeg protocol documentation describes reconnect controls for HTTP behaviour. Those controls can be relevant when an HTTP input disconnects, but they do not launch a process that has already exited and should not be treated as universal reconnection controls for an RTMP or RTMPS output. Choose reconnect options based on the actual protocol and direction of the connection.
For example, if a network source briefly drops while FFmpeg remains running, input-side handling may be relevant. If FFmpeg terminates with an error, systemd supervision is the part that can start it again. If FFmpeg remains running but stops sending useful media, a restart-on-exit policy alone may do nothing. The distinction is central to a dependable recovery plan.
Read the service and FFmpeg logs
After a failure or test restart, inspect the service status and recent journal entries. The status can show whether the unit is active, failed, or in a restart cycle. The journal can reveal the exit code, a missing file, a permission problem, a rejected option, an unavailable device, or a connection error. Look at the first meaningful error as well as the last line: later messages may only describe the consequences.
Make sure FFmpeg output reaches a place you can inspect through the service logs or a deliberate logging arrangement. A service that runs quietly can appear fine until you look at the remote preview. For more detail on keeping diagnostics available during an overnight incident, see how to log FFmpeg output for a 24/7 stream. The precise file paths in a VPS guide may not match your Pi, but the reason to preserve useful output is the same.
Do not expose the stream key in a command transcript, screenshot, or support post. YouTube describes stream keys as credentials in its live stream settings guidance; treat them accordingly. If a diagnostic command prints a full output URL containing the key, redact it before sharing the output.
Correlate local and remote evidence by time. If the service restarted at a particular moment but the Control Room preview stayed frozen, that tells you something different from a case where YouTube reported a new healthy input. A log showing that FFmpeg connected is useful, but it is not the same as confirming moving video and audible sound in the viewer-facing stream.
When FFmpeg is alive but media is stalled
A process supervisor normally notices a process exit. It cannot reliably infer that a living process is producing useful frames and audio. FFmpeg may remain active while waiting on a source, blocked on an output, or otherwise no longer advancing the media that viewers should see. The operating system’s “active” state is not a media-health check.
Check FFmpeg’s progress or diagnostic output, the source itself, and the remote preview. If the source is a file, confirm it can still be read and that the command is advancing through it as expected. If it is a camera or network feed, check that the device or endpoint is reachable and producing current media. Avoid automatically restarting on every temporary source delay without understanding whether that would interrupt a healthy recovery.
A separate health check can monitor progress or probe the source, but it must be designed for the command and media type. The Raspberry Pi-oriented project mentioned above documents progress timeout and source probing as separate controls. These are not interchangeable with systemd’s restart policy: one looks for lack of progress or source trouble, while the other responds to process lifecycle events.
If you add a watchdog, decide what evidence counts as a stall, how long a transient pause should be tolerated, and what action follows. A threshold that is too sensitive can repeatedly kill a process during normal buffering; one that is too relaxed can leave a dead picture on screen for longer. Test with the real source and typical network conditions rather than assuming a generic value suits your channel.
For a useful recovery test, stop the service deliberately and see whether systemd starts it again. Then test a source interruption and observe how the actual FFmpeg command behaves. These are separate tests: the first validates process supervision, while the second tells you about source handling. Neither alone validates YouTube ingest or viewer continuity.
Verify media health in Live Control Room
After FFmpeg restarts, open YouTube Live Control Room and inspect the preview and stream health. Look for moving video and, when the stream should contain audio, confirm that audio is present. A local log line that says the output connection opened does not show whether the intended broadcast is receiving usable media.
YouTube’s encoder setup guidance describes checking the live preview and stream status while setting up an encoder. Use the current official guidance for the channel and format in question. If YouTube reports an error or the preview does not advance, investigate the reported issue rather than repeatedly restarting the Pi without new evidence.
Confirm that the encoder is using the intended server URL and current stream key. YouTube’s help pages explain how to create or reset a key and update encoder settings. If the key was changed, update the local configuration securely; do not put the new value in a public issue, shared screenshot, or article example. Prefer RTMPS where supported, following YouTube’s current setup instructions.
If you intentionally use HLS rather than RTMP/RTMPS, follow YouTube’s HLS requirements for that supported use case. HLS changes the ingest configuration; it does not remove the need to supervise a local FFmpeg process. Do not change protocols as a generic response to an unexplained crash: first identify whether the failure is local process exit, source, network, or remote ingest.
YouTube recommends test streams and checking the picture and sound, and a configured backup encoder should be tested as its own recovery path. A successful local restart test proves only that a process can be restarted. It does not prove healthy ingest, continuous audio and video, a successful backup handover, or that YouTube has resumed the same broadcast.
Confirm the broadcast and viewer URL
Once the preview looks healthy, confirm which broadcast is live and what viewers can access. Check the intended event or stream in YouTube Studio and compare its status with the public watch page you share. A restarted encoder may reconnect in a way that does not match the broadcast or viewing session you expected; do not assume the same watch URL or uninterrupted playback simply because FFmpeg is running again.
If a planned restart is part of normal operation, test it with a private or otherwise appropriate test stream before relying on it in a public schedule. Note what Live Control Room reports, what happens to the watch page, and whether the video and audio resume. If you use a backup encoder, test the changeover independently and confirm what viewers see. Local service recovery and viewer-facing continuity are separate outcomes.
YouTube says streams under 12 hours are automatically archived, as described in its encoder streaming guidance. That statement is not a guarantee that every process restart preserves one uninterrupted broadcast, archive, or viewing URL. Check the current official guidance and the actual broadcast state, especially if recording or archiving is important to your channel.
For a deeper explanation of what happens when a broadcast goes offline, read whether a YouTube live stream can reconnect automatically. If you are configuring FFmpeg’s own retry behaviour, the reconnect options for a 24/7 YouTube stream are relevant background, but remember that protocol retries and systemd process restarts solve different problems.
For a small channel that wants to avoid leaving a Pi powered and responsible for a long-running local FFmpeg process, StreamNeo can remove that specific device-supervision task by running an uploaded video as a YouTube live stream without the creator’s computer staying on. It is YouTube-only, and it does not eliminate the need to confirm the broadcast and viewer experience in YouTube.
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 on a Raspberry Pi?
Run the working FFmpeg command as a systemd service and choose a restart policy suited to your systemd version and failure behaviour. Add a deliberate delay or limit so a permanent error does not create a rapid restart loop. Then check the service journal and YouTube Live Control Room after testing.
Will FFmpeg reconnect flags restart a crashed stream?
No. FFmpeg protocol reconnect options apply to particular connection behaviours while FFmpeg is running; they do not start a new process after it exits. A service manager such as systemd can restart an exited process, but that still does not prove healthy YouTube ingest.
Does a running systemd service mean the stream is healthy?
No. The process can remain active while the source is unavailable or media progress has stalled. Check FFmpeg progress and source health, then confirm moving video and audio in Live Control Room.
Will a local restart preserve the same YouTube broadcast or watch URL?
You cannot establish that from the local restart alone. Check the intended broadcast in Live Control Room and verify the viewer-facing watch page after recovery. Do not promise uninterrupted viewing or the same URL without testing the channel’s actual setup.