A Raspberry Pi that loses power can only resume a YouTube stream after power returns if the board boots and FFmpeg starts again. Enable a systemd service at boot, then choose a restart policy for the way FFmpeg exits; neither step proves that the source, network, stream key or YouTube broadcast is healthy.
The practical aim is recovery you can inspect, not a promise of uninterrupted streaming. This guide sets up the local process to start without an interactive login, then gives you checks to separate a Pi boot problem from a failed input or destination.
What power restoration does—and does not—restart
When power returns, a Raspberry Pi with a working supply should boot according to its normal startup configuration. That brings up the operating system, but it does not automatically know that a particular FFmpeg command should run. A command you started in a terminal is tied to that login session unless you have arranged for a service or another supervisor to own it.
There are two distinct recovery events. A boot-enabled service handles the first: the Pi starts, systemd loads the unit, and the service attempts to run FFmpeg. A restart policy handles a later event: FFmpeg exits while systemd is supervising it, and systemd decides whether to launch it again. Enabling a service does not by itself restart a process that fails hours after boot; a restart policy does not launch a service that was never enabled for boot.
Nor does a local process restart establish that a broadcast has resumed. FFmpeg can start and then fail to open a camera, read a file, resolve a hostname or connect to the publishing endpoint. It can also remain alive while media has stalled. Treat “service active” as one useful observation, not as an end-to-end health result.
Before changing the service, note what the system currently does. Is the Pi itself off, does it boot but fail to launch FFmpeg, or is FFmpeg present but no live picture reaching YouTube? Those are different faults. The upload-speed checks for a recorded YouTube stream can help when the process runs but the connection is unstable; they will not fix a unit that never starts.
Prepare FFmpeg to run without an interactive login
A service should run FFmpeg in the foreground as its main process. Do not add & to the end of ExecStart: that backgrounds FFmpeg and makes process tracking less clear. Use the absolute path to the executable and to any input file, and include all the arguments the command needs. For a file stored in a user’s home directory, for example, /home/streamer/video.mp4 is more dependable than a relative path whose meaning changes with the working directory.
The service will not inherit everything from a terminal you normally use. Make the service account, working directory, required environment and device access explicit. If the camera is available only to a particular group, check that the service user belongs to the right group and that the device exists after boot. Test that the file is readable by that user, rather than relying on a successful run from an administrator’s shell.
Here is a deliberately illustrative command shape:
/usr/bin/ffmpeg -nostdin -i INPUT -c copy -f flv OUTPUT
Replace INPUT, OUTPUT and the arguments with the actual camera or media source and the destination format required by your setup. -nostdin prevents FFmpeg from waiting for terminal input that will not exist in a service. The example is not a universal command: a camera may need different options from a video file, and your output endpoint may require different encoding or protocol arguments.
Keep credentials private. A live stream key is a secret: do not publish it in a support post, put it in an example, or expose it in a world-readable unit file or log. Decide how the service will receive the key with permissions appropriate to your installation, and restrict access to any file or environment configuration containing it. If you rotate the key in YouTube, update the service’s configured destination and restart the unit deliberately.
If the input is a network camera, confirm the camera is powered and reachable after the Pi boots. FFmpeg supports protocols including RTSP, and its protocol options can be specified on the command line or through AVOptions, as described in the FFmpeg protocol documentation. A transport option may be appropriate for a particular camera and network, but no single flag fixes every camera reconnect or network failure. Check the camera’s own settings and the errors FFmpeg reports.
For a prerecorded stream, verify that the file and any loop or playlist configuration still exist at the paths in the command. If the job is a sequence of sermons or videos, organising the inputs before automating them makes a failed file easier to identify; see this guide to organising a large video folder for an automated live stream.
Create a systemd service for the stream
On a Raspberry Pi OS installation using systemd, create a unit file for the stream, for example ffmpeg-stream.service. The sample below illustrates the core relationships. Change the account and paths, and replace the sample command with the tested foreground command for your actual source and destination.
[Unit]
Description=FFmpeg live stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/home/streamer
ExecStart=/usr/bin/ffmpeg -nostdin -i INPUT -c copy -f flv OUTPUT
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
The User entry determines whose permissions FFmpeg receives. WorkingDirectory makes relative paths predictable, although absolute paths in the command are still preferable. Type=simple tells systemd to treat the launched process as the service’s main process, so keeping FFmpeg in the foreground matters. WantedBy=multi-user.target makes the unit eligible to start as part of the normal multi-user boot sequence once you enable it.
Wants= and After= express a relationship to network-online.target. They are not a reachability test. In particular, After= controls ordering; it does not guarantee that DNS is working, a camera answers, or YouTube can receive the stream. If FFmpeg exits because a dependency is not ready, systemd can retry under the policy below. A process that hangs rather than exits requires a separate, reliable health check if you need to detect that condition.
Use a clear unit name and keep the command understandable. If the full command is long, do not hide its behaviour in an elaborate shell wrapper just to fit it on one line. A wrapper can change which process systemd tracks, make exit status harder to interpret, or retry in an unbounded loop. First make the straightforward command work under the intended service account; add a wrapper only when it has a specific job and its exit and retry behaviour are understood.
After saving a new or changed unit, ask systemd to reload unit definitions before starting it. Then read back the unit and status to catch spelling, path and permission errors. The unit file is configuration, not proof the media pipeline works: a successful start can still be followed by an FFmpeg error in the journal.
Enable startup at boot and choose a restart policy
Enable the unit and start it now with:
sudo systemctl enable --now ffmpeg-stream.service
enable arranges for the unit to be pulled in at boot; --now also requests that it start immediately. Check the installed systemd release and its documentation if options or behaviour differ on your Raspberry Pi OS image.
For many streaming jobs, Restart=on-failure is a measured starting point. It asks systemd to relaunch FFmpeg when it exits unsuccessfully or is terminated in the failure conditions systemd recognises, rather than repeatedly starting it after every clean exit. RestartSec=10 in the example inserts a pause before an attempt, making repeated failures visible without creating a rapid restart loop. The value is illustrative, not a promise that a camera or network will recover in that time.
Choose Restart=always only if a clean exit should also begin another attempt. The systemd service manual says that with always, a service is restarted whether it exited cleanly or not, was terminated abnormally by a signal, or hit a timeout; see the systemd.service manual. This can suit a process expected to run continuously, but it can also obscure an intentional clean end unless you know how the unit is stopped. A systemd-requested stop is not overridden by the restart policy.
The choice is about the process’s exit behaviour. If FFmpeg fails once because the camera is temporarily unavailable, restarting may be useful. If a key is invalid or a file has been removed, repeated attempts cannot correct the underlying configuration. Inspect the journal, fix the cause and then start the unit again. Avoid a tight, unbounded retry loop; a restart delay gives you a chance to see recurring errors and prevents the recovery logic from becoming another source of noise.
A policy that reacts to exits is not a detector for every stalled stream. If FFmpeg remains active while frames stop arriving, systemd may have no exit to react to. Add a stream-aware monitor only if your source or receiving platform provides a dependable signal and you know what action it should trigger. Do not mistake a rising restart count or an active state for proof of usable video.
Test service behaviour after a reboot
Test ordinary service operation before relying on recovery from a power cut. Start the unit, inspect its state, and read its current-boot messages:
systemctl status ffmpeg-stream.service
journalctl -u ffmpeg-stream.service -b
The status view helps distinguish active, failed and repeatedly restarting states. The journal can reveal a missing executable, a permission denial, an unreadable input or a connection error. Treat the first useful error as evidence: repeated retries may produce similar messages, so look at when the failure began and whether the same cause recurs.
Next, perform a normal reboot when you can observe the result and have a safe maintenance window. After the Pi comes back, run the same status and journal checks. Confirm that the unit was loaded for the current boot and that FFmpeg reached the expected stage. If you are operating a church or study channel where a gap matters, schedule the test outside a critical session and have a manual fallback rather than treating the test as proof of future uptime. A spare-PC approach to a nonstop sermon stream may be relevant if your actual need is a different operating arrangement, but it also needs its own startup and recovery plan.
A clean reboot test covers the boot-to-service path, not every possible outage. It does not simulate a marginal power supply, a camera that starts slowly, a changed network route or an invalid stream key. Do not repeatedly pull power as a casual test: abrupt power loss can interrupt storage writes. Prefer an orderly reboot for verifying service enablement, then investigate power quality separately if the Pi itself fails to return.
If the unit fails on boot but works when started manually later, compare the environment and timing. The interactive shell may have variables or permissions the service lacks, or the network and camera may not yet be ready when FFmpeg starts. Record the journal error, make the dependency or configuration explicit, then repeat the reboot test. Do not assume adding After=network-online.target solves an endpoint that is not actually reachable.
Verify the process, input, network and YouTube broadcast
Use a layered check rather than a single green status. The table separates what each recovery layer can do from what it cannot establish.
| Layer | What it addresses | What it cannot prove |
|---|---|---|
| Boot-enabled systemd unit | Starts FFmpeg after the Pi boots | That the input or destination is usable |
Restart=on-failure or always |
Relaunches after qualifying process exits | That a still-running process has healthy media |
| Stream-aware monitoring | Can flag a stalled or missing feed when its signal is reliable | That the Pi has power or can boot |
| UPS | Can bridge an outage within its supported load and capacity | Recovery after capacity is exhausted or the system crashes |
Start with the board. Confirm it has completed boot and that the service is active rather than failed or cycling. If the Pi is not booting, FFmpeg settings are not the first issue. Check the power supply, cables and board-specific indicators or diagnostics. Raspberry Pi documentation notes that the red PWR LED on models 1 through 4 relates to stable 5 V supply and can be off or flickering under undervoltage; Raspberry Pi 5 has power and reset reason fields. Consult the Raspberry Pi configuration documentation for your model, and do not use one indicator as a complete diagnosis.
Then check the input. For a camera, confirm it has power and is reachable from the Pi, and compare FFmpeg’s input errors with the camera’s own status. For a local file, confirm the file remains at the configured path and can be read by the service user. A successful FFmpeg process launch is not the same as a valid sequence of frames.
Next, verify the network path and destination configuration. Check that the Pi has a working route and can resolve the destination name; a “network online” ordering target alone does not establish either. Review the output URL and key without printing a live credential in public. If the key was reset or copied incorrectly, FFmpeg may run briefly or report an output error even though systemd has done its job.
Finally, inspect the receiving side. YouTube Studio’s live controls should show whether it is receiving the intended stream, and you should confirm that the broadcast itself is live and carrying current content. A local active state cannot tell you whether the platform sees the stream or whether viewers see moving video. If the platform indicates a problem, use its current help guidance and the exact error reported rather than assuming every interruption is a Pi fault.
The same distinction matters when planning a continuous playlist. Reaching YouTube is only part of the job; the content must also advance as intended. If your format is a loop, the article on avoiding gaps in a YouTube live video loop addresses a different failure layer from systemd process recovery.
Consider a UPS as a complementary measure
A UPS or Raspberry Pi UPS HAT may help bridge a short interruption, depending on its supported load and capacity. It addresses power continuity for a period; it does not enable your service at boot, supervise FFmpeg after a crash, or guarantee that the network or camera stays available. Keep the boot-enabled unit and process supervision even if you add battery-backed power.
Choose any power accessory only after checking its compatibility with the exact Pi model, connected camera and peripherals, and the power output and ride-through duration you require. The documentation reviewed for this guide does not establish runtime or compatibility for a particular UPS or HAT, so no model-specific promise is appropriate. Include the actual load in your decision: a bare board and a board powering additional equipment are not equivalent cases.
If outages are long enough to exhaust the chosen capacity, the Pi will still shut down or lose power. Recovery then returns to the same boot path: the board must start, systemd must enable the service, and FFmpeg must have working input and output. A UPS is a complementary layer, not a substitute for that chain or a guarantee against broadcast interruption.
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
Does Restart=always make FFmpeg start after a power outage?
Not on its own. It applies when systemd is already supervising a service and the process exits; enable the unit at boot to cover a Pi reboot. If you intentionally stop the unit through systemd, the restart policy does not undo that stop.
What should I check if systemd says the service is active but YouTube is not live?
Read the current-boot journal, then check the input, network route, destination URL and stream key. Confirm in YouTube Studio whether the platform is receiving the stream. An active local process is not an end-to-end broadcast check.
Should I use on-failure or always?
Use on-failure when only unsuccessful exits should trigger a retry. Use always when even a clean FFmpeg exit should begin another attempt, and make sure that behaviour matches how you intend to end the stream. Check the installed systemd documentation and watch the journal for repeated failures.
Will a UPS prevent the stream from stopping?
It may bridge an interruption within its supported load and capacity, but it cannot guarantee continuous power or a healthy stream. It does not replace enabling the service at boot or supervising FFmpeg, and it cannot fix a failed input, network path or key.