A Raspberry Pi can restart FFmpeg after the process exits, but FFmpeg's own reconnect options solve a different problem. Use protocol-specific input recovery for a supported input interruption, and a service manager such as systemd to start FFmpeg again after it has stopped.
A restart is only one recovery layer. It cannot repair an invalid YouTube stream key, a missing input file, a broken encoder command, or an internet connection that remains unavailable, so diagnose the failure before allowing the Pi to retry indefinitely.
First identify what actually failed
Start by finding out whether FFmpeg exited, remained running, or continued running without delivering a healthy broadcast. These cases can look similar from YouTube's side, but they require different responses.
If the FFmpeg process has disappeared, there is nothing left inside FFmpeg to reconnect. An external supervisor must launch a new process. If FFmpeg is still present, inspect its terminal output and service logs before restarting it. It may be waiting on an input, reporting encoder errors, or repeatedly failing to connect to YouTube.
If you run FFmpeg manually over SSH, check the process list and the terminal session first. A command may have ended when the shell closed, or it may still be running in another session. Under systemd, use the service status and journal rather than assuming that a YouTube interruption means the process has exited.
The useful questions are:
| Observation | Likely layer to inspect | What it tells you |
|---|---|---|
| FFmpeg is no longer running | Process supervision | The command needs to be started again, but the cause still needs investigation |
| FFmpeg is running and reports input errors | Input and source handling | An input reconnect option may help if the protocol supports it |
| FFmpeg is running but YouTube has no healthy video | Output, encoding, network and YouTube state | Restarting may not change the underlying problem |
| FFmpeg starts and exits repeatedly | Command, key, source, permissions or connectivity | A restart loop is masking a configuration failure |
This distinction matters for a devotional loop, a local news file, or a study channel alike. A Pi can faithfully restart the same failed command all night without producing a usable stream.
For a broader example of designing a continuous recorded channel, see this guide to a 24/7 JEE and NEET revision stream. The content is different, but the separation between the media file, encoder and YouTube broadcast is the same.
What FFmpeg input reconnect options can do
FFmpeg includes reconnect controls for particular protocols. The FFmpeg protocol documentation describes these in the HTTP section, where they apply to HTTP inputs rather than acting as a universal restart switch.
The documented options include reconnect, which retries a disconnection before the input reaches end of file; reconnect_at_eof, which treats end of file as an error and can be useful for live or otherwise endless inputs; reconnect_on_network_error, which covers network errors during a TCP or TLS connection; and reconnect_on_http_error, which can retry selected HTTP status codes or classes such as 4xx or 5xx. reconnect_streamed covers streamed or non-seekable inputs. The documentation also describes retry counts and delay limits.
These settings are useful when your source is an HTTP stream and the interruption fits the option's documented behaviour. They can allow one FFmpeg process to recover its input without being stopped and started. That is different from a supervisor launching a new FFmpeg process after the old one has exited.
Do not copy HTTP reconnect options into an RTMP or RTMPS output command and assume they will reconnect the YouTube broadcast. The input protocol and output protocol are separate parts of the command. An option documented for HTTP input handling should not be presented as a general solution for YouTube output recovery.
The exact option names, accepted values and interaction between retry limits should be checked against the FFmpeg build installed on your Pi. Package versions can differ, and an option copied from a different build may be rejected or behave differently from what you expect. Run ffmpeg -h full or consult the documentation for the version you are using before changing a production command.
Input recovery also has a trade-off. A process that keeps retrying may preserve its current output connection while waiting for the source, but it may also sit in a long retry cycle without making useful progress. If your source is a local file, a missing path or unreadable drive will not be fixed by an HTTP reconnect option. If the source is a camera, an unavailable device requires a device or power diagnosis instead.
Input recovery is not YouTube output recovery
A typical live command has at least four points where failure can occur: the media source, the decoder or filter chain, the encoder, and the connection carrying the encoded output to YouTube. A reconnect setting for one point does not repair the others.
For example, suppose FFmpeg reads an HTTP radio feed and sends encoded audio and video to YouTube over RTMPS. The HTTP input may reconnect after a temporary source interruption. That does not prove that the RTMPS connection is still active, that YouTube still considers the broadcast live, or that the same output session will accept data after a network change.
Conversely, if the YouTube connection fails and FFmpeg exits, HTTP input flags may have no effect at all. The external supervisor can start the command again, but the new attempt will fail if outbound traffic is blocked, the stream key is wrong, or the encoder command cannot initialise.
Treat the output as a separate health check. Look for connection errors, authentication messages, broken pipes, TLS failures, or encoder messages in the FFmpeg output. Then check the broadcast in YouTube Studio. A process returning to the running state is evidence that FFmpeg started, not evidence that viewers are receiving a healthy stream.
YouTube's live encoder guidance recommends testing with audio and movement similar to the planned broadcast, monitoring stream health, and matching the encoder settings to its current guidance. It lists RTMP and RTMPS as supported ingest protocols, and its recommendations include H.264, H.265 or AV1 video, AAC or MP3 audio, CBR, and a keyframe interval of two seconds recommended and no more than four seconds. Check the current page because these recommendations can change.
For H.264 at 720p and 30 frames per second, YouTube's table lists 3 Mbps as a minimum and 8 Mbps as a recommended ingest bitrate. Those are YouTube's guidance figures, not a guarantee that a particular Raspberry Pi can encode the content or that a broadband connection can sustain it. Your upload capacity needs headroom beyond the selected stream bitrate, and the Pi needs enough CPU capacity for the chosen resolution, frame rate and encoder.
If the output requirement is the part you do not want to keep repairing on a local computer, StreamNeo removes the need to leave your Pi running: upload the video, provide the YouTube stream key, and the broadcast runs with automatic monitoring and restart from the cloud. It is still your responsibility to check the file, channel and YouTube settings.
Put FFmpeg under a Raspberry Pi service manager
A service manager gives FFmpeg a parent process that can observe its exit and apply a restart policy. On Raspberry Pi OS, systemd is a practical pattern, but the exact unit behaviour depends on the installed operating system and systemd version. A Raspberry Pi-focused public FFmpeg systemd project is an implementation example, not official Raspberry Pi or YouTube guidance.
The important design is simple:
- Store the FFmpeg command in a service unit or a separately protected script.
- Run it as an intentional user rather than relying on an interactive shell.
- Give it the paths and permissions it needs.
- Ask systemd to restart it when it exits unexpectedly.
- Keep the logs available for diagnosis.
A unit might contain directives in this general shape:
[Unit]
Description=FFmpeg YouTube stream
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=streamer
ExecStart=/usr/local/bin/start-youtube-stream
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Treat this as a starting pattern, not a tested drop-in for every Pi installation. Verify the directive names and meanings with the systemd documentation installed on your machine. Confirm the executable path, user name, working directory, network target and permissions before enabling it. Some commands need an explicit working directory or environment variables; others fail because a shell feature was assumed but no shell was invoked.
Keep the actual FFmpeg command in a script when it is long. Make the script executable, use absolute paths, and test it directly as the service user. A command that works in your own shell may fail under systemd because it cannot see your home-directory environment, mounted drive, display session or PATH.
Do not place a stream key casually in a public script, a screenshot, a shared support post or shell history. Restrict the file containing it, avoid printing the full command into routine logs, and rotate the key if it has been exposed. YouTube's troubleshooting guidance explains how to obtain a new stream key in Live Control Room when a third-party encoder reports a start error. A new key is not a fix for every failure, so change it after checking the reported cause.
Configure and verify the restart policy
Restart=on-failure is intended for an unexpected non-zero exit or similar failure state. It is not the same as restarting after every clean stop, and it does not decide whether YouTube has accepted the new connection. Other policies exist, but choosing one without understanding how FFmpeg exits can produce either a silent failure or an endless loop.
RestartSec controls the pause before a new attempt. A short delay can help with a transient connection problem, while an immediate loop can overload the Pi, fill the journal and make diagnosis harder. There is no universal delay that suits every source and connection. Choose a pause, observe the behaviour, and adjust it after you understand the failure.
After editing a unit, reload systemd's unit files, start the service, and inspect its status. Use the installed systemd documentation and systemctl help to confirm the exact commands for your system. Do not assume that a service being enabled means that the FFmpeg command has been validated.
Test the policy deliberately before relying on it overnight. First run the command normally and confirm that the stream reaches YouTube. Then stop FFmpeg in a controlled way and observe whether the chosen policy correctly treats that stop. Next, allow FFmpeg to exit through a representative failure, such as a deliberately unavailable test input, and see whether the service starts it again. Do this with a test broadcast rather than the only live event serving your audience.
Watch for a restart storm. Repeated starts and exits usually mean that the command cannot initialise, the file is missing, the key is invalid, the user lacks permission, the input device is absent, the encoder settings are too demanding, or the Pi cannot reach the destination. A supervisor is doing its job when it reports the failure; it is not solving the cause.
Use limits and alerts appropriate to your setup, but do not invent a guarantee from them. The useful outcome is a clear record showing when FFmpeg started, why it exited, how many attempts occurred, and whether YouTube became healthy again.
Check the logs, source, key and connection
Start with the first error, not the final restart message. A service log often contains several lines after the original fault, including shutdown messages that are consequences rather than causes.
Check these areas in order:
- FFmpeg command: Confirm the input path, output URL, codec names, pixel format, frame rate, audio mapping and quoting. A small typo can make every restart fail in the same way.
- Source: Open the file or feed outside the full live command. Confirm that it exists, is readable by the service user, and contains the expected audio and video. For a camera or capture device, check that the device is present after reboot.
- Stream key: Verify that the key belongs to the intended YouTube channel and event. If YouTube reports a start error, follow its current Live Control Room instructions rather than repeatedly recycling the Pi.
- CPU and memory: Check whether the chosen encoder is keeping up. A Pi that falls behind under motion or complex audio may appear healthy with a static test screen and fail during real content.
- Storage and temperature: A full disk can prevent logging or reading a source, while thermal throttling can change encoder performance. These are local Pi conditions, not YouTube reconnect problems.
- Outbound connection: Confirm DNS, routing, firewall rules and sustained upload capacity. A brief successful connection does not establish that the link will remain usable for a continuous stream.
YouTube's live-stream troubleshooting guide advises checking the encoder version, the appearance and sound of the stream, encoder errors, CPU load and the outbound connection. Follow those checks with the current wording on the official page, since the Live Control Room and encoder guidance can change.
For a continuous channel, also test the content itself. A sleep-sounds and white-noise channel may have long quiet sections that expose audio dropouts differently from a news loop. A local talk programme may stress audio levels and file transitions. Test with representative movement and audio, not only a short colour bar.
Bandwidth is another common source of false confidence. A 24/7 children's video stream bandwidth guide can help you think about sustained usage, but your own stream still needs to be measured against its selected bitrate, overhead and other household or business traffic. If the connection is unavailable, restarting FFmpeg only repeats the connection attempt.
Confirm the broadcast in Live Control Room
Once the service reports that FFmpeg is running, open YouTube Studio and inspect the relevant live event. Confirm that the preview or stream health shows the expected video and audio, and look for warnings about bitrate, dropped frames or the connection.
This step answers a question that local logs cannot: whether YouTube received and accepted the new output. A restarted process may connect to a new broadcast, fail authentication, send no media, or reconnect after the previous event has ended. The process state and the broadcast state are not interchangeable.
Check the watch URL as a viewer as well, preferably from a separate device or connection. Look for frozen video, silent audio, repeated buffering, an ended broadcast or a different event from the one you intended to resume. If your channel uses a playlist or loop, verify that the content has not stopped at a file boundary.
Record the time of the failure, the last useful FFmpeg message, the restart time and the state shown in Live Control Room. This gives you a repeatable way to distinguish a one-off network interruption from a command that fails on every attempt.
Do not assume that a successful restart preserves the same YouTube broadcast or watch URL. The exact result depends on the event, key, output command and YouTube's current state. Verify the broadcast in Studio after recovery and confirm the public page before telling viewers that the channel is back.
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 FFmpeg's HTTP reconnect option restart a YouTube stream?
No. HTTP reconnect options apply to supported HTTP inputs and can retry particular input failures. They do not act as a general process supervisor or guarantee recovery of an RTMP or RTMPS output to YouTube.
What should restart FFmpeg after it exits on Raspberry Pi?
Use an external supervisor such as systemd, or a carefully designed wrapper, and verify its behaviour on your installed Raspberry Pi OS. Configure a suitable restart policy, retain the logs, and test a controlled failure before relying on it overnight.
Why does FFmpeg keep restarting but never go live?
The command may have a bad source path, missing device, invalid key, incompatible encoder settings, insufficient CPU, or no usable outbound connection. Read the first FFmpeg error and check YouTube's Live Control Room rather than increasing the restart frequency.
Does a running FFmpeg process prove that YouTube recovered?
No. FFmpeg can be running while the output is rejected, stalled or not reaching the intended broadcast. Confirm stream health in YouTube Studio and check the public watch page after every recovery test.