A Linux server can send a prerecorded video to YouTube as an encoder feed, with systemd supervising FFmpeg after you have tested the command yourself. The safe order is to prepare the event and credentials, confirm the feed in the foreground, and only then make the process a service.
Scheduling creates a shareable upcoming watch page and gives viewers a reminder option; it does not start playback. You still need the encoder to connect, check the preview in Live Control Room and take the event live there.
Prepare the YouTube event before touching systemd
In YouTube Studio, open Create → Go Live and choose the encoder workflow. Create an event or schedule one, then set its title, privacy and other details. If you want viewers to have an upcoming page to share or a reminder to set, scheduling is useful. If you are testing privately, choose the privacy and event arrangement that suits that test rather than assuming a scheduled page is required for every test.
The event and the feed are related, but they are not the same thing. YouTube’s Live Streaming API concepts distinguish a liveBroadcast, the viewer-facing event, from a liveStream, the incoming media feed. In practical terms, you prepare the event in Studio and configure FFmpeg to send media to the ingest details associated with it.
Do not mistake an upcoming page for an active stream. At the scheduled time, start the encoder, allow YouTube to receive enough data to show a preview, inspect the preview and stream health, then use Go live in Live Control Room when you are ready. Scheduling alone neither starts FFmpeg nor makes a connected feed visible as live playback to viewers.
Keep the event lifecycle in mind while testing. A foreground test can be done before the audience-facing event, but sending data to the same event may affect what Studio shows and when the event can be taken live. Check the current YouTube guidance for scheduling a live stream and the current Studio workflow before you set a public time; YouTube can change its interface and event behaviour.
Retrieve the ingest details and protect the key
When you set up the encoder stream in Studio, note the server URL and stream key YouTube provides. Use the details issued for this stream rather than copying an ingest address from a blog example. An address can differ by protocol or account workflow, and the key is the credential that lets an encoder send to the channel’s feed.
Treat the key like a password. YouTube describes stream keys as password-like and provides a reset process in its stream-key help page. Do not put a real key in an article, public repository, screenshot, shared shell transcript, or a unit file readable by every local user. If someone else has seen it, reset it in Studio and update the configuration that uses it.
For a small Linux setup, keep the URL and key in a separate configuration file readable only by the account that needs it, or use an appropriate secret store. You can create a dedicated account such as youtube-live and give it access only to the media and configuration it requires. That reduces accidental exposure, but it does not replace checking who can administer the machine or read its process information.
Prefer YouTube’s secure RTMPS ingest where your installed FFmpeg supports it. RTMPS is encrypted RTMP, and YouTube’s RTMPS requirements require the correct endpoint details, port 443 and TLS server name. Do not substitute a guessed hostname or drop part of the URL while adapting it. FFmpeg builds vary, so check the protocols available in your own installation with ffmpeg -protocols and confirm how it handles the exact address before relying on it.
A useful distinction: the channel’s stream key is not itself the whole ingest URL. The server address and key together identify where and how the encoder connects. Keep both accurate, and keep the key private.
Validate FFmpeg in the foreground
Run the first test in a terminal as the account that will eventually run the service. This makes errors visible and avoids introducing systemd, boot behaviour and restart policy before you know the basic command can read the file and connect.
FFmpeg documents a real-time file-to-RTMP pattern like this:
ffmpeg -re -i input.mp4 -f flv 'rtmp://server/app/stream-key'
This is a shape example, not a YouTube command to paste unchanged. Replace the input path and destination with the actual media file and the current YouTube ingest address and key. For RTMPS, use the RTMPS URL supplied for the channel and check that the installed build supports it. The -re option makes file input proceed at approximately its natural rate instead of sending the file as fast as the machine can read it; that real-time pacing is important when using a file as an encoder source. See FFmpeg’s streaming documentation for the documented pattern and options.
Do not assume every MP4 can be sent with stream copy. The input’s codecs, timestamps, frame rate, audio layout and container compatibility affect whether the resulting feed is accepted and plays correctly. If the source needs encoding, specify an intentional video and audio encoding configuration based on the source and YouTube’s current recommendations. Avoid copying a bitrate recipe without checking the current requirements and the characteristics of your own programme.
Watch the terminal output for file access errors, connection errors and repeated warnings. Then check Live Control Room: does a preview appear, is there audio, and does the picture play as expected? YouTube recommends advance testing and checking the preview, availability and audio/video quality. If your programme includes a devotional track or an ambience bed, listen to the start and a representative passage rather than relying only on a moving picture.
Keep the initial test finite and observable. A prerecorded file normally reaches its end and FFmpeg exits. That is different from a 24/7 channel that must repeat a programme or rotate material indefinitely. If you need a playlist or intervening slate, first decide how that programme should behave; the guide on streaming an FFmpeg playlist with a static image between videos covers a different media pattern. Do not add looping options or complex filters to the first test unless they are part of the actual requirement and have been tested.
If the command fails, fix the foreground case before proceeding. Check that the file exists, the URL has no accidental spaces, the key is current, outbound connectivity is available, and FFmpeg reports the expected protocol. A successful process start is not enough: verify the preview and listen to the result.
Put the tested command into a systemd service
Once the exact media, arguments and destination work interactively, move that command into a system service. A service is useful because systemd can start a foreground process, track its exit and apply a restart policy. It does not make a bad command correct, nor does it ensure YouTube will accept every reconnect.
Use absolute paths. Choose a dedicated unprivileged user and group, an explicit working directory, and a protected environment file. The following is an illustrative skeleton; replace the paths and command with the version you tested, and confirm the syntax against the systemd version installed on your Linux distribution:
# /etc/systemd/system/youtube-live.service
[Unit]
Description=Prerecorded YouTube Live encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=youtube-live
Group=youtube-live
EnvironmentFile=/etc/youtube-live/stream.env
WorkingDirectory=/srv/youtube-live
ExecStart=/usr/bin/ffmpeg -re -i /srv/youtube-live/program.mp4 -f flv ${YOUTUBE_INGEST_URL}
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
This example shows the shape of a unit, not a verified configuration for your host. In particular, systemd’s EnvironmentFile parsing and ExecStart argument handling are not identical to a shell script’s variable expansion. Check the installed systemd manual and confirm how your intended URL is parsed. If you use a wrapper, keep argument handling safe and make sure it does not hide FFmpeg’s exit status or interfere with signals.
Do not put a real stream key in a unit that other local users can read. A protected environment file is one approach, but check its ownership and mode, and ensure the service account can read it. Also consider whether command-line arguments are visible to other users on your host. Your threat model may call for a different secret-handling approach.
The Wants and After lines express a relationship to the network-online target; they do not prove the internet route, DNS or YouTube ingest is actually ready. Similarly, Type=simple is appropriate for a foreground process in a basic arrangement, but check local distribution documentation if you are changing service behaviour or using a more involved launcher.
Enable startup and choose a cautious restart policy
After saving a unit, ask systemd to reload its configuration, inspect the unit and start it deliberately. Typical commands are:
sudo systemctl daemon-reload
sudo systemctl status youtube-live.service
sudo systemctl start youtube-live.service
Do not enable boot startup until you have decided what should happen if the machine reboots while an event is not scheduled, or after the video file has ended. When the service is ready for the intended lifecycle, enable it with sudo systemctl enable youtube-live.service. Enabling registers the service for the configured boot target; it does not schedule a YouTube event or take one live.
Restart=on-failure asks systemd to restart the process after certain failures. RestartSec=5 introduces a delay before a restart. These are example policy choices, not guarantees that the broadcast will resume successfully. A process restart may lead to a gap, a rejected reconnect, or a changed state in Live Control Room. Test the behaviour against the event and keep a person able to check Studio rather than assuming a restart is invisible to viewers.
A finite input that reaches the end may exit normally; a restart-on-failure policy should not be treated as a repeat button. If the channel’s purpose is a continuous station, plan the media schedule separately and verify the installed FFmpeg behaviour and timestamps for the intended sequence. For a wider 24/7 design, the article on creating a 24/7 YouTube Live TV channel discusses the programming and operating questions beyond a single file.
Systemd supervision can remove the need to keep an interactive terminal open, but it cannot guarantee an uninterrupted broadcast. FFmpeg has its own documented network recovery and FIFO options, yet these too need testing and can affect what YouTube receives. Keep restart behaviour conservative until you understand how your event responds.
Check the service account, files and network
A command that works for your administrator may fail under the service account. Test file access explicitly. The programme file, any subtitle or auxiliary file, the working directory and the environment file must all be accessible to the configured user. Avoid solving a permission error by making private files world-readable; grant the service account the access it needs instead.
Use absolute paths in the unit. An interactive shell may have a different PATH, home directory, current directory and environment from systemd. If you depend on a particular FFmpeg binary, use its full path and verify it is the same build you tested. Check that the media is still present after reboot and that storage does not fill during operation.
Check network upload capacity with the actual output configuration. YouTube recommends headroom above the total stream bitrate, including primary and backup feeds if you use them. The relevant rate is the stream you will send, not simply the size of the source file. If you change resolution, encoding settings or add a second feed, recheck the connection rather than assuming yesterday’s test still applies. For a higher-resolution setup, the upload-speed considerations for 4K 60fps streams offer a related way to think about capacity and headroom.
If the stream is specifically restricted to secure ingest, check that your key and encoder URL are aligned with that requirement. The article on whether a YouTube stream key can be restricted to RTMPS addresses that narrower choice. Do not assume switching the URL alone proves that the entire connection is using the intended protocol; verify the FFmpeg build and Studio status.
Finally, consider what the audience should hear and see if the feed drops. A systemd restart can bring the process back, but it does not decide whether a scheduled event should be taken live again or whether viewers should be notified. StreamNeo can remove the need to keep your own Linux host and FFmpeg process running for an uploaded video, which is useful when that machine’s overnight availability is the pain you are trying to avoid.
Review logs and preview before the event goes live
Use systemd’s status and journal to see whether the process is running and what FFmpeg has reported. For example:
sudo systemctl status youtube-live.service
sudo journalctl -u youtube-live.service
Add -f to the journal command when you want to follow new messages as they arrive. Look for a clear connection, ongoing output, and any repeated reconnection or encoding errors. Redact the key before sharing logs: a URL or argument can contain sensitive ingest information.
At the same time, use Live Control Room to check the incoming preview, stream availability and audio/video quality. A running service only tells you about a local process; Studio tells you what YouTube is receiving. Confirm the picture, audio level and sync, then use the event’s Go live control when you intend to make the scheduled event public. Scheduling did not start playback, and a healthy local process does not by itself mean the event is live to viewers.
For an event that should be archived, check YouTube’s current archive guidance. YouTube says live streams under 12 hours are automatically archived, but this and the Studio workflow are subject to current platform guidance. Save a local copy of the source and verify its integrity rather than relying on a platform archive as the only copy.
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 scheduling a YouTube Live event start my FFmpeg stream?
No. Scheduling gives you an upcoming event page and lets viewers choose a reminder, but your encoder must connect separately. Check the preview in Live Control Room and take the event live there when it is ready.
Can I paste the example FFmpeg command as written?
No. It uses placeholder input and ingest values, and plain RTMP may not be the protocol you intend to use. Substitute the current details from YouTube Studio, check that your FFmpeg build supports the chosen protocol, and validate the feed in the foreground first.
Will systemd restart guarantee that viewers never see an interruption?
No. A restart policy can relaunch FFmpeg after a process failure, but it cannot guarantee that the connection returns cleanly or that the YouTube event remains in the desired state. Test the exact setup and monitor both systemd logs and Live Control Room.
Will one prerecorded file run for 24 hours?
Not by default. FFmpeg normally exits when it reaches the end of a finite input, and restarting after failure is not the same as looping or scheduling a playlist. Test the media sequence and lifecycle you actually need before enabling an unattended service.