A systemd service can keep FFmpeg running after you close the terminal or log out of Linux. It can also restart FFmpeg after a process exit, but it cannot repair a bad stream key, a missing input file, a failed encoder, or a network problem.
The dependable workflow is to obtain a current YouTube ingest URL and key, prove the complete FFmpeg command interactively, then place that known-good command under systemd supervision. You must still check YouTube's Live Control Room, because an active Linux process is not proof that YouTube is receiving a healthy stream.
Get the current YouTube ingest details
Open YouTube Studio and create or select the live event you intend to use. In the Live Control Room, find the current stream settings and copy the server URL and stream key from the official event interface. Do not assume that a key copied from an old event is still the right credential for the stream you are preparing.
Treat the stream key like a password. Anyone who has it may be able to send content to your channel, so do not paste it into a public issue, a tutorial screenshot, a shared document, a world-readable service file, or a shell command that may be retained in command history. If you believe it has been exposed, reset or rotate it in YouTube Studio before testing again.
Keep the ingest URL and key conceptually separate even if your local command eventually combines them. The URL identifies the YouTube ingest endpoint. The key authenticates the broadcast to that endpoint. Store both in a protected file or another secret mechanism that only the service account and administrators can read.
YouTube's current instructions and interface should take priority over an older command copied from a forum. Start with the official YouTube encoder settings when checking supported codecs, bitrate guidance, frame rates, keyframes, audio, and ingest choices.
For a first test, use an unlisted event if you do not want viewers to find the stream while you are checking it. This lets you inspect the preview and stream-health messages without confusing a technical rehearsal with a public broadcast. It does not remove the need to respect YouTube's current policies or the rights associated with the material you stream.
Prefer RTMPS where YouTube supports it
RTMPS is RTMP carried over an encrypted connection. YouTube recommends streaming with RTMPS, so use the RTMPS server address supplied by the current Live Control Room when your FFmpeg build and network support it. Do not replace the endpoint with a guessed hostname or an address found in an old example.
The output protocol is only one part of the path. Your Linux host must be able to resolve the endpoint, establish the connection, and sustain the upload. A service manager can bring FFmpeg back after it exits, but repeated connection failures will simply create repeated failures unless the underlying network, endpoint, or credentials are corrected.
YouTube's encoder guidance covers RTMP and RTMPS workflows and identifies the supported codec and delivery settings. It recommends a constant bitrate and a keyframe interval of about two seconds, with the interval not exceeding four seconds. Use the settings for your chosen resolution, frame rate, and codec together rather than copying a bitrate from a different mode.
For example, the current YouTube table lists H.264 at 1080p and 30 frames per second with a recommended bitrate of 14 Mbps, while 720p at 30 frames per second has a recommended H.264 bitrate of 8 Mbps. Those figures are tied to those exact conditions, not universal values for every stream. If you choose a different codec, frame rate, or resolution, consult the current table again.
Leave room for variation in your upload connection. A connection that barely reaches the selected video rate may still produce dropped frames when another device uses the network or when the line fluctuates. Measure the real upload path from the machine that will run FFmpeg, and avoid treating a short speed-test result as a guarantee of overnight performance.
Match FFmpeg to the input and output
Before creating a service, confirm that FFmpeg is installed and that its build contains the input demuxer, output protocol, and encoder you plan to use. Find the executable with:
command -v ffmpeg
ffmpeg -version
Use the absolute path returned by command -v ffmpeg in your service or wrapper. This avoids relying on the different PATH available to a system service compared with your interactive shell.
The input type determines much of the command. A prerecorded file, a looped playlist, a camera, and a network feed have different pacing and failure behaviour. Do not take a command designed for a local MP4 and apply it unchanged to a camera or an online source.
For a prerecorded file, -re tells FFmpeg to read the file at its native playback rate rather than sending it as quickly as the machine can read it. It is useful when publishing a file in real time. For a genuinely live input, adding -re may be inappropriate because the source is already paced. FFmpeg's official documentation should be checked for the input and protocol you are using.
A simple H.264 and AAC example, using placeholders rather than a real credential, looks like this:
/usr/bin/ffmpeg -nostdin -re \
-i /srv/youtube-stream/input.mp4 \
-c:v libx264 -preset veryfast \
-b:v 4500k -maxrate 4500k -bufsize 9000k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://example.invalid/app/STREAM_KEY"
This is a structural example, not a universal YouTube preset. A 60-frame GOP represents two seconds only when the video runs at 30 frames per second. At another frame rate, set the keyframe interval to approximately twice the frame rate and confirm the result against YouTube's current guidance.
The example also uses a 4,500 kbps video rate, which is not a recommendation for every output. Select bitrate, resolution, frame rate, codec, and available CPU or GPU capacity as one group. If the installed build does not include libx264, use an encoder that it does support and verify that YouTube accepts the resulting format.
If the file already contains compatible video and audio, stream copying may reduce CPU use, but it leaves compatibility and timing entirely dependent on the source. Re-encoding gives you control over output settings but requires sustained processing capacity. Test both the visible result and the host's CPU, memory, and upload behaviour before choosing.
For a looped file, define the loop explicitly and test what happens at end of file. A service restart is not the same as a seamless loop: it may create a new connection or a visible interruption. If your source is a camera or network feed, use the input-specific options and reconnection behaviour appropriate to that source instead of assuming a file loop will cover it.
Prove the command before creating the service
Run the complete command interactively first. Use the same input, output settings, endpoint type, and account that the service will use. This separates FFmpeg and YouTube problems from systemd problems.
Watch for a successful connection, increasing frame count, advancing timestamps, and stable audio and video processing. An FFmpeg process that remains open while producing no frames is not a successful test. Likewise, a command that connects but sends a frozen image or silent audio needs fixing before it is supervised.
Open the Live Control Room while the test is running. Check that the preview shows the expected picture, that audio is present, and that YouTube reports healthy or actionable ingest information. Move through a representative part of the source: a quiet visual loop may hide a timing problem that becomes obvious when the video changes or audio begins.
FFmpeg normally checks console input for commands such as q. That behaviour can be a problem for a detached process because the process may consult a terminal that no longer exists or suspend while checking it. Add -nostdin as a global option. The FFmpeg FAQ documents this background-process behaviour and also describes redirecting standard input from /dev/null as an alternative.
Stop the interactive test cleanly after you have confirmed the result. Do not create the production service around a command that has only been tested by watching whether a terminal window stays open. The test must include the actual YouTube preview and the source conditions expected during normal operation.
Create a protected systemd service
Create a dedicated unprivileged Linux account for the stream rather than running FFmpeg as root. Give that account access to the input directory, the working directory, the FFmpeg executable, and the protected credential file, but avoid granting it unrelated administrative access.
For example, you might use a layout such as:
/srv/youtube-stream/input.mp4
/etc/youtube-stream/stream.env
/etc/systemd/system/youtube-stream.service
The exact paths are your choice. What matters is that the input and working directories are explicit and that the credential file is not readable by ordinary users. Set ownership and permissions according to your distribution's account model, then verify them rather than assuming a file created by an administrator is accessible to the service account.
A service unit can have this general shape:
[Unit]
Description=FFmpeg YouTube live stream
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/srv/youtube-stream
EnvironmentFile=/etc/youtube-stream/stream.env
ExecStart=/usr/local/bin/start-youtube-stream
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Treat this as a framework to adapt, not a copy-and-paste universal unit. Confirm that the directives are supported by the systemd version on the distribution you operate. The network-online.target ordering can help sequence startup, but it does not prove that the Internet route is usable or that YouTube will accept the connection.
The protected environment file could contain names such as YOUTUBE_RTMPS_URL and YOUTUBE_STREAM_KEY, but do not publish its contents. Be careful with how the service consumes those values. Shell-style variable expansion is not identical everywhere in ExecStart, and systemd does not turn the command into an interactive shell. A small wrapper script with strict ownership and permissions can read the environment and invoke FFmpeg with quoted values.
For example, the wrapper should use the absolute FFmpeg path, include -nostdin, and quote the assembled endpoint. Do not place a real key in the wrapper, the unit file, a public code repository, or documentation. Also consider that command-line arguments and process inspection may expose values while the process is running, depending on the operating system and permissions. Use a secret-handling approach appropriate to your host and keep access limited.
Avoid unnecessary output redirection. The system journal is useful for diagnosis, but a badly designed command can echo the full endpoint or credential into logs. Log FFmpeg's useful progress and error messages without printing the secret. Review the unit, wrapper, environment file, and journal after a test to confirm that the key does not appear.
Restart=on-failure asks systemd to try again after an abnormal process exit. It does not mean that YouTube will see one continuous broadcast, and it does not fix an invalid key, an unavailable source, unsupported settings, or a persistent network fault. Add a deliberate restart delay and use the local systemd rate-limit controls so a broken configuration does not create an uncontrolled restart loop.
A host restart, power cut, disk failure, or loss of the upload connection remains an operational event to handle. The service manager is a process supervisor, not a replacement for input monitoring, network checks, or YouTube's own live-event state.
Start, enable, and inspect the service
After saving the unit, ask systemd to reload its configuration:
sudo systemctl daemon-reload
sudo systemctl start youtube-stream.service
Inspect the immediate state:
sudo systemctl status youtube-stream.service
sudo journalctl -u youtube-stream.service -n 100 --no-pager
Look for the process ID, the exit status, the command actually being launched, and the latest FFmpeg messages. A service shown as active (running) means the supervised process has not exited. It does not confirm that frames are arriving at YouTube or that the public stream is healthy.
Once the interactive and managed tests have both succeeded, enable the service for the normal boot target:
sudo systemctl enable youtube-stream.service
You can combine start and enable with systemctl enable --now, but doing the first managed start separately often makes diagnosis clearer. Test a manual stop and start as well, and confirm what YouTube shows after the process reconnects. A new connection may be represented differently from a continuous event, so check the event state rather than assuming systemd's restart is invisible to viewers.
When changing the command, edit the protected source, reload systemd if the unit changed, and restart the service deliberately. Then inspect the journal again. Keep a short record of which input, codec, bitrate, and endpoint were tested so that a later change can be traced instead of guessed at.
If a local Linux machine is used, compare its power settings, reboot schedule, upload path, and physical access with the demands of a 24/7 channel. A remote host can remove some household power and connectivity issues but adds its own administration, access-control, storage, and cost responsibilities. The VPS guide for a 24/7 prerecorded YouTube stream is useful when that hosting choice is still open.
Check health in YouTube Live Control Room
Use YouTube's Live Control Room as a second monitoring system. Check the preview, stream-health indicators, ingest messages, audio levels, resolution, frame rate, and dropped-frame information while the service is running. YouTube specifically advises testing before going live and monitoring stream health and messages.
Compare what FFmpeg says with what YouTube receives. If FFmpeg reports frames increasing but the preview is frozen, the problem may be in the output format, connection, or YouTube ingest rather than process supervision. If the preview is moving but audio is absent, inspect the source audio stream and the mapping or encoding options.
Test with the same sort of movement and audio that the final channel will carry. A static devotional image, a rain video, a local news loop, and a music programme do not exercise the encoder in exactly the same way. The guide to running a 24/7 Telugu songs stream from a PC covers some of the practical source and playback questions that also matter for a music-led channel.
If you are operating a prerecorded channel, decide how the end of the source is handled before the public launch. A long file can still end, become unreadable, or produce an unexpected final frame. You may also want to review how to loop a long rain video without restarting the YouTube stream, particularly if your output is a long ambience or sleep-sounds programme.
For channels where the computer should be switched off after upload, StreamNeo removes the need to keep a local FFmpeg process and Linux host running for the uploaded video, while still leaving YouTube event settings and content responsibility with you. It is a different operating model from managing your own systemd service, not a guarantee that every live-event issue disappears.
Troubleshoot process and ingest failures
Start with the layer that is failing rather than changing several settings at once.
| Symptom | First checks | Likely boundary |
|---|---|---|
| Service exits immediately | systemctl status, journal output, executable path, file permissions |
systemd or local process |
| FFmpeg cannot open the input | Absolute input path, ownership, format support, end-of-file behaviour | local source |
| Authentication or connection error | Current URL, rotated key, RTMPS support, DNS and outbound access | credentials or network |
| Process runs but preview is absent | Increasing frame count, output protocol, YouTube event state, stream-health messages | ingest path |
| Preview moves but picture or audio is wrong | Codec, mapping, sample rate, source streams, output settings | FFmpeg configuration |
| Repeated restarts | Exit status, restart delay, persistent input or network error | recovery policy |
| Stream becomes offline after a file ends | Loop or playlist behaviour and end-of-file logs | input workflow |
For a service that exits, read the first meaningful error in the journal rather than focusing on the final systemd summary. Common causes include a typo in the absolute FFmpeg path, an unreadable input, an invalid environment file, a missing encoder, or a wrapper that is not executable.
If FFmpeg connects and then disconnects, verify the current endpoint and key in YouTube Studio. Check whether the host can maintain an outbound connection and whether the upload path is stable. Restarting the service repeatedly will not correct a revoked key or a blocked route.
If the service reports success but YouTube reports no data, check that the URL is being built as intended without a blank variable, an extra quote, or an omitted key. Check that the output is actually being written with the intended protocol and that the command is not reading a local file faster or slower than expected. Keep the credential out of diagnostic screenshots and redact it from copied logs.
If the stream is unstable, reduce the number of simultaneous changes. First observe CPU and upload behaviour, then compare output bitrate and resolution with YouTube's current table. A host that cannot encode the selected mode in real time may fall behind even when the connection is sound. A host with sufficient CPU may still fail if the upload path cannot sustain the output.
If FFmpeg suspends when detached, confirm that -nostdin is present as a global option and that the service is not attached to a terminal. FFmpeg's background-process guidance also allows standard input to be redirected from /dev/null. Do not use a terminal multiplexer as the main fix when the intended workload is a managed service.
If systemd restarts the process but the stream remains offline, treat that as evidence that the process is exiting or reconnecting, not evidence of a healthy broadcast. Inspect the exit reason, YouTube's event state, and the source at the same time. A persistent fault needs correction, and an automatic restart can create a noisy loop without restoring the event.
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 systemd guarantee an uninterrupted YouTube stream?
No. It can keep a process supervised and may restart it after an exit, but it cannot prevent failures in the source, encoder, Linux host, upload connection, or YouTube ingest. Use systemd status and YouTube's stream-health view together.
Should the stream key be written directly in the service file?
No. Keep it in a protected secret file or another suitable secret mechanism, restrict access, and prevent it from appearing in public files, screenshots, command history, or logs. Rotate the key in YouTube Studio if it has been exposed.
Why is -nostdin important for a background FFmpeg process?
FFmpeg can check console input for commands, and the FFmpeg project notes that this can cause a background process to suspend. -nostdin prevents those input checks; redirecting standard input from /dev/null is another documented approach.
Should every YouTube FFmpeg command use -re?
No. It is useful for pacing a prerecorded file in real time, but a live camera or network input may already be paced. Choose the option according to the input workflow and test the complete command in YouTube's Live Control Room before enabling the service.