To run a continuous YouTube stream from Ubuntu, use FFmpeg as the foreground process of a systemd service. YouTube supplies the ingest URL and stream key; systemd can start FFmpeg at boot and restart it after some process exits, but it cannot fix a bad key, missing file, network outage or an ended YouTube broadcast.
The steps below take you from a tested source file to the YouTube preview and the systemd journal. They also cover an important limit: YouTube says streams under 12 hours are automatically archived, so a service that restarts FFmpeg is not, by itself, a plan for an indefinitely continuous channel.
Prepare the Ubuntu host and source
Choose where the stream will run before writing the service. A spare Ubuntu computer gives you direct access to the machine and its logs, but depends on the computer, power and local internet connection remaining available. A rented Ubuntu host avoids keeping a computer at home switched on, but you still need to manage the operating system, storage, network and service yourself. For a comparison of those trade-offs, see VPS versus a spare PC for a prerecorded stream.
Install FFmpeg from a package source you trust for your Ubuntu release, then confirm that it can read your media and supports the formats and network protocol you intend to use. Do not assume that every FFmpeg build has the same encoders or protocol support. Check your installed build and test the actual file before relying on it overnight.
Keep the source in a stable location that the service account can read. Use an absolute path, such as /home/streamer/media/channel-loop.mp4, rather than a path that only works from your interactive shell’s current directory. Check that the file is present, readable and has the video and audio you expect. A service running under a different account may not have permission to read files in your personal home directory.
For a prerecorded loop, FFmpeg options such as -stream_loop -1 can repeat a file, while -re can pace file input in real time. These are command-design choices, not YouTube requirements: test them with your installed FFmpeg version and source. If you are trying to keep a simple ambient scene running without unnecessary encoding work, the FFmpeg CPU-use guide for 24/7 ambient streams discusses the trade-offs.
Before turning the command into a service, run it interactively with the real source, intended resolution, frame rate and audio. YouTube recommends testing with audio and movement representative of the broadcast and checking stream health. A short successful test can reveal a missing codec or a path error; a longer test gives you a better chance of noticing intermittent network or source problems. It still does not prove the setup will run without interruption.
Create or schedule a YouTube Live stream
In YouTube Studio, create a live stream or schedule one, then open its Live Control Room. The stream’s settings and lifecycle are on YouTube’s side, separate from your Ubuntu process. Follow YouTube’s instructions for the intended stream type and check that the channel is enabled to stream before diagnosing FFmpeg.
YouTube’s guide to creating a live stream with an encoder describes entering the server URL and stream key into the encoder. Keep the Live Control Room open during setup: it is where you can see whether YouTube is receiving an incoming feed and whether a preview appears. FFmpeg printing output locally is not confirmation that a usable broadcast has reached the platform.
Decide how you will handle the YouTube-side broadcast when it needs to end or be replaced. Creating a stream event and starting an encoder are related actions, but they are not interchangeable. For a continuous channel, include a person or process in your operating plan to check the broadcast and manage its lifecycle rather than assuming that restarting a local process will reopen an ended event.
Get the server URL and stream key
Copy the server URL and stream key shown for your stream in Live Control Room. Use the values YouTube provides rather than guessing an ingest address. YouTube may show an RTMP address by default; when you want encrypted transport, select the RTMPS URL supplied there. YouTube describes RTMPS as a secure extension of RTMP using TLS/SSL.
Treat the stream key as a password. Do not put it in a public repository, screenshot, support post or command example that may be shared. Avoid making a configuration file readable by every local account. A key in a command line can also appear in places you did not intend, so think through who can inspect process details and logs on your host before choosing how to pass it to FFmpeg.
If the key is exposed, use Live Control Room to reset it, then update the encoder configuration with the replacement. A restart policy cannot turn an invalid or revoked key into a valid one. Similarly, an SSL or connection error is a reason to verify the actual URL, protocol and encoder support, not to repeatedly restart the same incorrect command. Where the URL configuration permits it, YouTube’s RTMPS guidance may help you check the secure endpoint and port 443.
Configure FFmpeg using current encoder guidance
Choose encoding settings to match your source and the upload connection you can sustain. YouTube’s current live encoder settings list RTMP/RTMPS transport, H.264, H.265 (HEVC) or AV1 video, up to 60 frames per second, constant bitrate (CBR), and AAC or MP3 audio. YouTube recommends a two-second keyframe interval and says it should not exceed four seconds. Check the current YouTube table for the exact combination of codec, resolution and frame rate you plan to use.
The following examples are YouTube-recommended video bitrates, not a promise that your host or internet connection can sustain them. YouTube’s guidance accessed in September 2026 lists these examples:
| Output example | H.264 recommended video bitrate | AV1 or H.265 recommended video bitrate |
|---|---|---|
| 1080p at 30 fps | 14 Mbps | 10 Mbps |
| 720p at 30 fps | 8 Mbps | 6 Mbps |
For stereo audio, YouTube recommends a 44.1 kHz sample rate and 128 Kbps. Its guidance gives 48 kHz and 384 Kbps for 5.1 audio, and notes that 5.1 over RTMP or RTMPS is supported only with AAC. These are reference settings. If your source is mono speech or music at a different sample rate, decide deliberately whether to preserve or convert it, then check the resulting feed in YouTube’s preview.
Do not copy a bitrate from an old configuration without checking the current table. A higher setting uses more upload capacity; if the connection cannot sustain it consistently, the feed may suffer. Test from the actual host and use a representative output. For an Ubuntu service, also consider whether the chosen encoder is available in your FFmpeg build and whether the host can encode it steadily. The always-live preflight checklist is useful for checking more than just the command itself.
Build and test an FFmpeg command that keeps the process in the foreground. The exact command depends on whether your source is a looped file, camera or production feed, so do not paste a sample without replacing its paths, input options, codecs, settings, URL and key. Verify that FFmpeg identifies the intended audio and video streams and that it connects to the RTMPS endpoint. Keep the key out of notes and logs you may publish.
Run FFmpeg as a systemd service
Once the command works interactively, put it in a system-level service so systemd can start and supervise the actual encoder process. A service file typically identifies the command, the account that runs it, the working directory where relevant, and how output is logged. Make FFmpeg the main foreground process rather than launching it in the background from a wrapper; otherwise systemd may track the wrapper instead of the encoder.
Set the service account and file permissions intentionally. The account needs access to the media and any configuration it reads, but should not receive broader access than the job needs. Be particularly careful with the file containing the stream key. A configuration readable by all users, or a unit that exposes the key unnecessarily, undermines the care taken to keep the key private. Check the systemd and Ubuntu documentation for the behaviour of the version you are using before relying on a particular secret-passing method.
Choose a restart policy and delay based on the failure you want systemd to recover from. A policy can respond to some local process exits; a delay can avoid an immediate, tight restart loop. It cannot repair a file that has been deleted, credentials that YouTube rejects, or a host with no network route. Nor does a new FFmpeg process necessarily restore a YouTube event that has ended. Do not treat a restart directive as a general continuous-broadcast guarantee.
After editing the unit, ask systemd to reload its unit definitions, then start the service and inspect its state. If the service fails immediately, read the error before trying repeated restarts. A typo in the executable path, a permission problem, an invalid FFmpeg option or an unavailable source each needs a different fix. Keep the unit readable enough that you can understand what it launches when you return to it months later.
Enable startup and inspect logs
Starting a service now and enabling it at boot are separate tasks. Once the interactive and service tests are sound, enable the unit for the machine’s normal startup path, then confirm its current state with systemctl status. A service being enabled means systemd is configured to start it in the relevant boot context; it does not mean that the source, network or YouTube broadcast is currently healthy.
Use the journal to see what FFmpeg and the unit reported. For example, journalctl -u youtube-live.service shows journal entries associated with that unit; add an appropriate recent-time filter when you want to focus on the latest attempt. systemctl status youtube-live.service gives a compact state and recent output. Replace the example unit name with yours. Avoid sharing unredacted log output if it contains a key, private path or other sensitive detail.
Diagnose by layer rather than treating every failure as a systemd problem:
| What you observe | What to check next |
|---|---|
| Unit is inactive or failed | Read the unit status and journal for the first error, then check the command and permissions. |
| FFmpeg reports that input cannot be opened | Confirm the absolute media path exists and is readable by the service account. |
| FFmpeg cannot connect or reports an SSL problem | Verify the Live Control Room URL, RTMPS selection and the host’s network access. |
| Unit is active but there is no usable preview | Check FFmpeg’s output, then confirm the incoming feed and health in Live Control Room. |
| The service restarts repeatedly | Find and fix the underlying exit cause; repeated process launches are not a substitute for diagnosis. |
A host can lose connectivity while systemd continues to regard a process as active. Conversely, FFmpeg can exit while YouTube’s Live Control Room still reflects the earlier state for a time. That is why the journal and platform view are complementary. If a process is not sending the expected feed, first fix that layer; if YouTube has ended the broadcast, handle the platform-side event rather than expecting systemd to recreate it.
Check the YouTube preview and duration constraint
With the service running, return to Live Control Room and verify that YouTube receives the stream and shows the intended preview. Listen for audio and inspect motion, framing and stream health. A running systemd unit only establishes that the process is running according to the host; the preview helps establish what YouTube is actually receiving. YouTube recommends monitoring stream health and testing with representative audio and movement.
Plan explicitly for duration. YouTube states that streams under 12 hours are automatically archived. That statement does not mean every stream lasting less than 12 hours suits a channel intended to be live around the clock. An archive is not the same thing as an uninterrupted live event, and restarting FFmpeg alone does not document or manage the transition between YouTube broadcasts. Check YouTube’s current guidance and decide how you will stop, schedule or replace a stream when needed.
For a devotional channel, local news loop, study stream or shop display, the right operating choice depends on the source and the amount of maintenance you can take on. An Ubuntu service suits someone who wants command-level control and is prepared to maintain the host and check both local and platform health. A dedicated encoder may fit a live camera or production workflow better; a managed cloud tool may remove the need to leave your own computer on for a prerecorded source. StreamNeo can remove that particular computer-on burden for an uploaded video, while you still need to supply and manage the YouTube stream details and check the channel’s requirements.
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 keep a YouTube broadcast live indefinitely?
No. systemd supervises a local process and can start it at boot or restart it after some exits. It cannot guarantee an uninterrupted connection or manage every YouTube-side event, and YouTube says streams under 12 hours are automatically archived. Plan the platform-side lifecycle separately.
Will a restart fix a rejected stream key or a missing file?
No. A restart repeats the same configured command, so it will not correct invalid credentials, missing media or a bad URL. Read the journal, correct the cause, and then start the service again. If the key has been exposed, reset it in Live Control Room and update the protected configuration.
Is RTMPS required?
YouTube supports RTMP and describes RTMPS as a secure extension that carries the connection over TLS/SSL. Prefer the RTMPS URL shown for the stream in Live Control Room when using encrypted transport, and verify that your FFmpeg build and configuration support it. Do not assume a default URL is RTMPS.
How do I know the stream is really reaching YouTube?
Check both sides: inspect the systemd state and journal for FFmpeg’s result, then confirm the incoming feed, preview and health in Live Control Room. A service marked active is not proof that the platform is receiving the intended audio and video.