Before putting FFmpeg under systemd, prove that the command can reach YouTube and that YouTube receives healthy audio and video. Then check the systemd version on your Ubuntu host, build a service using directives verified for that version, and test what happens when FFmpeg exits.
A systemd service can restart a process, but it cannot guarantee an uninterrupted broadcast or confirm that YouTube is receiving a valid stream. Keep the service journal and YouTube Live Control Room health indicators in view as separate checks.
Get the RTMPS destination and protect the key
In YouTube Live Control Room, create or select the stream you intend to use, then copy its stream URL and stream key. YouTube recommends RTMPS, which carries RTMP over a secure connection; choose the RTMPS endpoint rather than assuming the first URL displayed is the right one. See YouTube’s live streaming guidance for the current workflow and requirements.
Treat the stream key as a password. Anyone who obtains it may be able to publish to your stream, so do not paste a real key into an article, screenshot, shared ticket, public repository or command that will be saved in shell history. If the key is exposed, use YouTube’s Live Control Room reset workflow and update the system that publishes the stream.
For the manual test, keep the key out of the command you share or save. You can enter a destination privately in a way that avoids leaving the secret in a public example, but do not assume that merely moving a value into a file makes it protected. Check file ownership and permissions, and verify the secret-handling method supported by your Ubuntu and systemd versions before adopting it in a unit. Do not make the unit world-readable if it contains a credential.
The endpoint and key need to match the selected live stream. If YouTube rejects a connection, recopy both from the same Live Control Room stream before changing encoding flags. For a broader diagnostic sequence when ingest does not appear, see common YouTube Live streaming problems.
Build and test FFmpeg manually
Test the exact media and command interactively before creating a service. This lets you distinguish an FFmpeg, file-path, codec or YouTube ingest problem from a systemd configuration problem. FFmpeg’s protocol documentation gives a general file-to-RTMP pattern using real-time input, an input file and FLV output. Adapt that pattern to the RTMPS URL and key copied from YouTube, and check that your installed FFmpeg build supports the protocols and codecs you intend to use: FFmpeg protocol documentation.
A safe public illustration uses placeholders, not a live credential:
ffmpeg -re -i /path/to/input.mp4 \
-c:v libx264 -b:v 5M -maxrate 5M -bufsize 10M \
-r 30 -g 60 -c:a aac -b:a 128k \
-f flv 'rtmps://example.invalid/live/REPLACE_WITH_PRIVATE_DESTINATION'
This is an example shape, not an authoritative command for every file or current YouTube configuration. The destination shown is deliberately unusable. Replace it privately with the RTMPS endpoint and key, and select parameters that fit the input, target resolution and frame rate. If the file is already encoded appropriately, a re-encode may be unnecessary, but verify the stream’s actual codec, bitrate and keyframe behaviour rather than inferring them from its filename.
YouTube’s current live encoder guidance lists H.264, H.265/HEVC and AV1 video, AAC or MP3 audio, constant bitrate encoding, and frame rates up to 60 fps. It recommends a two-second keyframe interval and says not to exceed four seconds. Requirements and recommended bitrates vary with the selected codec, resolution and frame rate, so use YouTube’s current table for the exact combination rather than treating an example as a universal target.
For context, the displayed H.264 recommendations include 5 Mbps for 1080p at 30 fps, 6 Mbps for 1080p at 60 fps, and 3 Mbps for both 720p examples at 30 and 60 fps. These are examples from YouTube’s changing guidance, not guarantees of quality or a substitute for checking the current table. If you choose a different codec, resolution or frame rate, look up its corresponding recommendation before setting the encoder. A 4K and 60 fps FFmpeg setup guide can help frame the workload trade-offs, but it does not replace current YouTube requirements.
Run the command in a terminal as the account you expect to use for the service, with the intended media file and network path. Watch FFmpeg’s output for connection errors, missing files, unsupported options and repeated reconnects. Then check Live Control Room: an FFmpeg process that has not exited is not proof of healthy ingest. YouTube advises testing with representative motion and audio and monitoring stream health and messages during the event.
Check Ubuntu and systemd before writing a unit
Systemd unit directives and supported secret mechanisms can differ by systemd release. First identify the Ubuntu release and the installed systemd version on the actual host where the service will run. Record those results, and consult the official systemd manual pages matching that version, along with Ubuntu’s documentation for the release. Do not copy an unfamiliar unit directive from a newer distribution and assume it will work on an older host.
The exact systemd manual pages could not be verified during preparation of this guide. For that reason, this article deliberately does not publish a purportedly universal unit file or assert that a particular directive is supported on every Ubuntu release. Verify each directive against the target host’s installed manuals before using it, especially settings for restart behaviour, credentials, execution identity and service environment.
You can still prepare the information a unit will need: the absolute path to FFmpeg, the source file or playlist, the working directory if required, the account that will run the process, and the private destination handling method you have verified. Resolve relative paths before deployment. A command that works from your home directory may fail when launched as a system service because its working directory and permissions differ.
If the Ubuntu host is a remote machine, also establish how you will administer it if the stream process fails. Do not make changes to a working production service until you have a way to inspect its status and journal and a way to recover or stop it. The point of version checking is not paperwork: it avoids diagnosing a typo or unsupported directive as a network or encoder failure.
Decide what should happen when FFmpeg exits
A restart policy is a recovery choice, not a promise of continuous streaming. Before choosing one, decide whether an exit should trigger an automatic retry, whether repeated failures should prompt an alert or human investigation, and how you will prevent an invalid command from restarting indefinitely without anyone noticing. Confirm the exact restart directives and limits in the manual for the installed systemd version; no single policy is right for every source or deployment.
Consider the likely failure modes. A brief network interruption may justify a retry after a delay. A wrong file path, rejected key or unsupported encoder option is unlikely to be fixed by repeatedly launching the same command. For those errors, inspect the journal and correct the underlying cause. If you use a playlist, test its transitions as well as the initial file; fixing FFmpeg playlist gaps addresses a different source of silent or stalled output than process supervision.
Choose a dedicated, unprivileged service account where practical, and grant it only the access needed to read the media and use the verified secret mechanism. Consider what happens after a host reboot and whether the service should start automatically, but verify the relevant unit behaviour and dependencies on your Ubuntu release. A service that starts before a mounted media directory is available may fail even though the FFmpeg command itself is sound.
Plan logging before you enable automatic restarts. Decide how you will read recent output, distinguish a clean stop from an error, and notice a process that repeatedly exits. Systemd’s journal records process messages; YouTube’s Live Control Room reports ingest health. One view cannot substitute for the other.
Create the service with verified directives
After the manual test works, translate that exact invocation into a service. Do not change the codec, source file, key handling and restart policy all at once. Keeping the working command stable makes it easier to identify whether a later failure comes from the unit context or from an FFmpeg change.
Use the official manual pages for the host’s installed systemd version to verify the unit section names and every directive you plan to use. Confirm how the chosen Ubuntu release handles the service account, working directory, environment or secret delivery, restart policy, and logging. Then validate the unit using the tools and procedure documented for that host before starting it. Because the version-specific manuals were not retrievable for this guide, it would be misleading to present a ready-to-paste unit as verified.
Keep secrets separate from public configuration where the verified mechanism permits it. Restrict access to any credential-bearing file, check its owner and permissions, and consider whether the secret could appear in process arguments or diagnostics. A unit file is not automatically a safe place for a key simply because it is not a shell script. If your chosen arrangement cannot protect the key from other local users, reconsider the account and secret storage design before exposing the stream.
Use absolute paths for the executable and source, and test the command under the intended service account. Confirm that the account can read the input and any configuration but cannot alter files it does not need to change. If you edit a unit, follow the target system’s documented reload and validation workflow; do not rely on assumptions about when systemd notices edits.
Start the service and inspect both views
Start the service only after the unit has been checked on the target version. Inspect its status and recent journal entries using the commands documented for your installation. Look for execution failures, permission errors, FFmpeg output and restart attempts. If the process exits immediately, run the exact command again interactively as the service account and compare its environment and paths with the unit’s configuration.
At the same time, open Live Control Room and check whether the stream is actually arriving and whether YouTube reports healthy audio and video. A service can be active while sending no usable frames, publishing the wrong source, or connecting to the wrong stream. Conversely, an ingest warning may point to encoding settings even if the service has remained up.
Test with representative content, including the sort of movement and audio the channel will carry overnight. Check for silent sections, frozen frames, unexpected aspect ratio, audio clipping or warnings about bitrate and keyframes. Keep YouTube’s current encoder recommendations at hand while testing, and revisit them if you change codec, resolution or frame rate.
For a channel built around long-running material, the source itself deserves attention as much as the service. If your use case is a continuous ambience or study station, the guide to growing a 24/7 white-noise stream covers audience and content considerations rather than systemd behaviour. Keep that distinction clear: successful service management does not resolve rights, content suitability or YouTube policy questions.
Test failure and recovery deliberately
Do not wait for a real overnight failure to learn whether your recovery plan works. During a controlled test, stop the process using the documented service-management method and observe whether the result matches your intended policy. Then test a recoverable fault in a safe window, such as temporarily making a test source unavailable, and confirm that logs explain the failure and that any retry behaves as expected. Avoid deliberately exposing the live key or disrupting a scheduled broadcast to test recovery.
Also test a failure that should not be mistaken for a transient network issue. A missing file or invalid option should be diagnosable from the journal, not hidden behind a loop of retries. If the service restarts repeatedly, review the configured policy and the actual failure messages before deciding to change it. Verify the restart limits and syntax against the systemd version you run rather than relying on a sample written for another release.
During the test, compare the systemd state with YouTube’s ingest view. If the service is active but YouTube reports unhealthy media, investigate the endpoint, stream selection, encoder configuration and input. If the service is inactive, start with the journal and reproduce the command interactively. For connection rejection, recopy the URL and key from Live Control Room; for encoder warnings, recheck codec, bitrate, keyframe interval and audio settings against the current official guidance.
Once the controlled tests pass, document how to stop the service, inspect logs, renew a compromised key and restore the previous known-good configuration. A tested recovery procedure is useful only if someone responsible for the channel can find and follow it. systemd can supervise FFmpeg, but it cannot remove every cause of stream interruption or verify the audience-facing result on its own.
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
Where do I put the YouTube stream key?
Treat it as a credential and keep it out of public commands, screenshots and world-readable unit files. Verify a protected storage method supported by your Ubuntu and systemd versions, and check who can read the resulting configuration. If you think the key has been exposed, reset it in YouTube Live Control Room.
Why is systemd active when YouTube says the stream is unhealthy?
Systemd reports whether it is supervising a process; YouTube reports what it receives. FFmpeg may still be running while sending the wrong source, invalid media or an encoder configuration that triggers warnings. Check the journal and Live Control Room separately.
Should I use RTMP or RTMPS?
YouTube recommends RTMPS, which uses a secure connection for RTMP. Copy the RTMPS URL from Live Control Room and confirm that the installed FFmpeg build supports the protocol you select.
Does a restart policy prevent interruptions?
No. It can relaunch FFmpeg after some process failures, but it cannot guarantee an uninterrupted broadcast or prove that YouTube is receiving healthy media. Test the policy and recovery path on your host, and monitor both the journal and YouTube’s stream health.