To start an FFmpeg YouTube stream when your Raspberry Pi boots, first make the command work interactively, then run that same command from a systemd service. The service can start the process, log its output and restart it after certain failures; it cannot make a bad encoder setting, missing input or unavailable network work.
YouTube’s current ingest address and encoder requirements depend on your Live setup. Copy them from the current YouTube Live Control Room or official documentation, and treat any command below as a structure to adapt rather than a guaranteed current recipe.
What the service will do
A systemd unit describes a process the operating system can start and supervise. You will give it the FFmpeg command that you have already tested, specify which local account runs it, and choose when it should start. When the Pi boots, systemd can launch that process without requiring you to log in and open a terminal.
The unit can also record the process’s standard output and errors in the system journal. That gives you a place to look when FFmpeg exits. A restart policy can start the process again after an unexpected exit, subject to the policy you choose. Neither feature confirms that viewers can watch the stream: FFmpeg might still be running while YouTube rejects the feed or the stream is not live in your Control Room.
The Pi itself needs a working operating system on boot media, along with suitable power and the input source your stream uses. Raspberry Pi’s getting-started documentation covers the basic setup. The appropriate Pi model and input path depend on whether you are sending a file, a camera feed or another source, and on the encoding work involved. Do not infer that a camera command for an older Pi setup will work unchanged on your hardware or operating system.
A service is useful when you want to keep a Pi-based source running unattended and are prepared to inspect it when something changes. If your actual need is to broadcast an uploaded video while your own computer is off, this is a different operating model: StreamNeo removes the need to keep a Pi or desktop running for that specific file-to-live workflow.
Prepare and test the FFmpeg command
Do not start by debugging FFmpeg inside a service. First open a terminal on the Pi and run the command in the same local account that the service will use. Confirm that it can read its input, produce the intended audio and video, connect to the destination, and appear as an incoming stream in your YouTube Live setup.
The command-line model is straightforward: FFmpeg reads one or more inputs, applies any requested mapping or encoding, and writes an output. Inputs can include files, network streams and capture devices; the output is commonly a destination URL. The FFmpeg command-line documentation explains this model. The FFmpeg protocol documentation documents RTMP-family protocols and shows an RTMP output using FLV. That establishes the format of an example, not which protocol or ingest address your channel should use today.
Use the server address and stream key shown for the specific broadcast in your current YouTube setup. Check the encoder requirements there as well, including resolution, frame rate, bitrate and keyframe interval. This guide does not prescribe values: a setting that was once used in a tutorial may not fit your current stream, account workflow or source. Confirm YouTube receives the stream before moving on to systemd.
If the command is long, write it down carefully and note the working directory, input paths and FFmpeg executable path. Shell commands that work from your home directory may fail as a service because the service starts with a different working directory or account environment. Check command -v ffmpeg and use its resulting path in the service. If you use a camera, confirm the device path and permissions as the service account, not only as your interactive login.
Avoid copying a command from an old camera guide without checking every argument and endpoint. The Raspberry Pi Foundation’s older nature-camera example is useful background for the camera-to-stream idea, but its startup instructions are historical and should not be treated as a current systemd recipe. If your stream uses a prerecorded loop, first confirm that the local playback behaves as intended; advice on making a seamless loop for a prerecorded YouTube Live stream covers that separate part of the workflow.
Protect the YouTube stream key
A stream key is a credential. Anyone who obtains it may be able to send video to the associated stream, so do not paste a real key into a public article, repository, screenshot or support post. The Raspberry Pi Foundation’s example likewise warns readers to keep the key secret. If you believe a key has been exposed, use the current YouTube controls to replace or reset it and update your local configuration.
Do not put the key directly in a unit file that other users can read, or leave it in shell history. A practical pattern is to put the output URL or key-bearing configuration in a separate file owned by the service account and readable only by that account. For example, you might use a directory under /etc for service configuration and restrict its ownership and mode. Choose the exact format to suit your command and operating system, and check what permissions are applied after creation.
One option is an environment file referenced by the unit, with a variable containing the key. Keep that file out of version control and restrict access. Another is a wrapper script that reads a protected file and passes the value to FFmpeg. In either case, be aware that credentials can still be exposed by careless logging, diagnostic output or process inspection. Do not print the full destination URL if it contains the key when sharing logs.
If you use a shell wrapper, quote variable expansions correctly and avoid building a command by concatenating untrusted text. Make the script executable, give it a valid interpreter line, and set permissions so only the intended account can change it. Test the wrapper interactively as that account before asking systemd to run it. You can also use a YouTube stream-key permission troubleshooting guide if the Control Room rejects the credential: check Brand Account stream-key permissions.
Create the systemd service
Create a unit file with a name you can recognise, such as /etc/systemd/system/youtube-ffmpeg.service. A unit can call FFmpeg directly or call a wrapper script. The example below is a skeleton, not a complete command; replace the placeholders with paths and configuration you have tested. It intentionally contains no real key or universal ingest URL.
[Unit]
Description=FFmpeg YouTube live stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/home/streamer
EnvironmentFile=/etc/youtube-ffmpeg/stream.env
ExecStart=/usr/bin/ffmpeg YOUR_TESTED_ARGUMENTS_AND_OUTPUT
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
The User should be the dedicated or ordinary account you selected, and the input files and devices must be accessible to it. WorkingDirectory matters when your tested command uses relative paths. EnvironmentFile is optional; include it only if your command actually reads variables from such a file. Likewise, replace ExecStart with your tested argument list or a wrapper path. Systemd does not run ExecStart through a shell by default, so shell syntax such as pipes and variable expansion will not behave like a terminal command. A wrapper is often clearer if the workflow needs shell features.
Type=simple suits a foreground FFmpeg process: systemd considers the service started when it launches the command. Keep FFmpeg in the foreground rather than backgrounding it from a script; systemd needs to track the process it started. Restart=on-failure asks systemd to restart after a non-successful exit, while a deliberate clean exit is not automatically treated the same way. RestartSec gives a pause before a retry. These settings help with transient exits; they do not repair persistent faults.
Review the unit before enabling it. In particular, confirm that the service account, executable, input, protected credential source and output are all correct. The unit itself should not contain a copied key. If you change the file later, systemd will need to reload its unit definitions before it uses the new version.
Configure startup and network readiness
After=network-online.target expresses ordering: start this service after the network-online target has been reached. Wants=network-online.target requests that target as a dependency. These directives do not test whether DNS resolves, the router has internet access, a firewall permits the connection, or YouTube’s ingest endpoint is reachable. The operating system’s network manager must also provide and configure the relevant wait-online behaviour for the target to mean what you expect.
Raspberry Pi’s configuration documentation describes wireless setup and a boot option to wait for a network connection. That setting can affect boot behaviour, but it is not a guarantee that an external streaming destination will be reachable at the instant FFmpeg starts. Think of boot ordering and end-to-end connectivity as separate checks.
For an unattended stream, combine suitable startup ordering with a process that can cope with an initial connection failure. A restart delay can give a router or connection time to recover; excessive rapid retries can make diagnosis harder. Choose a delay appropriate to your setup and inspect the journal after a failed start. If the network remains unavailable, repeated starts will not create connectivity. If the service starts before DNS or routing settles, a later retry may work, but verify that behaviour rather than assuming it.
The right readiness check also depends on the Pi image and network manager. Do not add a wait-online unit blindly if your installation does not implement it, and do not treat a successful local network association as proof that YouTube can be reached. If the stream buffers or repeatedly drops on a home connection, examine the upload path separately; the practical Wi-Fi checks in this bhajan stream stability guide apply to the network question, though the device in that guide differs.
Enable, start and inspect the service
After saving the unit, ask systemd to reread unit files, then enable the service for the chosen boot target and start it now. The sequence is:
sudo systemctl daemon-reload
sudo systemctl enable youtube-ffmpeg.service
sudo systemctl start youtube-ffmpeg.service
Enabling arranges for the unit to be pulled in at boot; starting launches it immediately. They are separate actions, so doing only one does not do the other. If you have changed the unit file since loading it, run daemon-reload again before restarting the service.
Inspect the result rather than relying on the command returning without an error:
systemctl status youtube-ffmpeg.service
journalctl -u youtube-ffmpeg.service -n 50 --no-pager
The status output tells you whether the unit is active and usually shows recent process information. The journal gives FFmpeg’s error messages and startup output. Look for obvious problems such as a missing input file, permission denied, an unrecognised option, a missing device, or a connection error. Redact credentials before sharing any output publicly.
Also check YouTube Live Control Room. A process can remain active while the stream is not accepted or visible as expected. Confirm the incoming preview and any stream-health information there, then check the public viewing experience as appropriate. systemd reports process state, not the quality or policy status of a YouTube broadcast.
To make a change, stop or restart the unit deliberately after editing its configuration. Use systemctl restart youtube-ffmpeg.service after a unit reload when needed, then inspect status and journal again. If you want to prevent boot startup while retaining the unit file, disable it; if you need it stopped immediately, stop it as well. Avoid testing changes during an important broadcast unless you have a safe maintenance window.
Restart safely and diagnose failures
Automatic restart is most useful when a process exits unexpectedly because of a temporary interruption. With the sample’s on-failure policy, a persistent bad key or invalid FFmpeg option can cause repeated failures. The service may be active at one moment and fail again shortly afterwards. Use the journal to identify the first meaningful error rather than treating a restart loop as recovery.
Work through failures in layers. First run the command by hand under the configured account. If it fails there, fix the command, file access, camera permissions or network before editing systemd. If it works interactively but not as a service, compare the account, environment, path, working directory and device access. If FFmpeg connects but YouTube does not show a usable stream, check the current ingest details and encoder requirements in YouTube rather than changing unrelated systemd directives.
When a connection drops, inspect whether the process exited, whether systemd restarted it, and whether it can reconnect with the same command. A service restart policy only reacts to process exit; it cannot detect every bad stream condition while FFmpeg continues running. A process that is stuck but still alive may need a different health check, and that should be designed carefully so it does not disrupt a healthy broadcast.
After repeated failures, stop the service while you investigate to avoid noisy retries. Make one change at a time, start it again, and check both the local journal and YouTube’s incoming status. If a key may have leaked, replace it in YouTube and update the protected local file. For recurring connection issues, distinguish local Wi-Fi or ISP instability from an encoder failure and from a YouTube-side issue; these have different remedies.
A Raspberry Pi gives you direct control over the source and local process, but that also means you own the operating system, input, network and service configuration. If your requirement is specifically to keep a pre-recorded file live without leaving your computer powered on, compare that workflow with the broader options for around-the-clock prerecorded video streaming.
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 start an FFmpeg stream on boot?
Test the FFmpeg command interactively first, then put it in a systemd unit with the correct user, paths and configuration. Reload systemd, enable the unit for boot and start it, then inspect its status and journal before relying on it unattended.
Does network-online.target guarantee that YouTube is reachable?
No. It provides ordering around a systemd network target, whose behaviour depends on the operating system and network manager. DNS, internet routing and the remote ingest endpoint can still be unavailable, so use sensible retry behaviour and verify the actual connection.
Will systemd fix a YouTube encoder or stream-key error?
No. systemd starts and supervises a process; it does not validate your key or choose suitable encoder values. Use the current YouTube Live setup for the ingest details and requirements, and correct FFmpeg or credential problems before expecting a service restart to help.
Can I use a Raspberry Pi camera command from an older tutorial?
Use it as a historical example, not as a ready-to-run recipe. Camera software, device access, FFmpeg options and YouTube ingest details can change, so confirm the input path and current output requirements on your own installation before configuring systemd.