On Ubuntu Server, install FFmpeg from the repositories configured for your release by refreshing apt’s package metadata and installing the ffmpeg package. That gives you the encoder, not a continuous broadcast: you must also provide a repeating or live source, configure YouTube output, and supervise the process separately.
The package version depends on your Ubuntu release and enabled repositories, so verify what you installed rather than expecting a particular version. The steps below take you from the apt install through a test stream and process recovery, while keeping YouTube’s current settings and your stream key in view.
What you need on Ubuntu Server
You need shell access to a supported Ubuntu Server installation, a user account with permission to run administrative commands through sudo, and a network connection for package downloads. Before changing anything, confirm which Ubuntu release you are using. Run lsb_release -a if that utility is present, or inspect /etc/os-release; this matters because repositories and package versions differ across releases.
You also need an input that can keep producing media. For a prerecorded channel, that might be a finished video file stored on the server, or a playlist of files. For a live source, such as a camera or network feed, the source must be reachable and its own interruptions need consideration. A single ordinary file ends when playback reaches the end unless you arrange a loop or another continuing input.
Finally, you need a YouTube channel with access to Live Control Room and a stream configured there. YouTube provides an ingest URL and a stream key for the encoder to use. Treat the key as a password: anyone with access to it may be able to send video to that stream. Keep it out of public scripts, screenshots, source repositories and shared command history.
For a first setup, use the server’s normal Ubuntu repositories rather than adding a third-party package source just to chase a newer build. Ubuntu advises users to assess non-standard repositories before adding them, since they affect where packages come from and how they are updated. If you do have a specific feature requirement, establish that the repository build lacks it before taking on that extra maintenance.
Refresh apt metadata and install FFmpeg
The documented apt-based route is short. First refresh the local package index, then install FFmpeg:
sudo apt update
sudo apt install ffmpeg
apt update downloads current package metadata from the repositories configured on the machine; it does not upgrade every installed package. apt install ffmpeg asks apt to install the package and any required dependencies. Review the proposed changes before confirming, especially on a server that hosts other services.
Ubuntu’s package listing includes FFmpeg, but the version offered is tied to the Ubuntu release and its configured repositories. The presence of the package does not mean every release offers the same build or optional encoder support. Google Cloud’s FFmpeg guidance likewise uses sudo apt install ffmpeg as an example of installing the package on Ubuntu; that is a useful confirmation of the basic method, not a promise about a particular version or host.
If apt reports that it cannot locate the package, check the release and enabled repositories before copying commands for a different Ubuntu version. Confirm network and DNS access, then try sudo apt update again and read any repository errors it prints. Do not ignore a failed metadata refresh: apt could otherwise be working from incomplete or stale package information. Ubuntu’s package management guidance explains the standard apt workflow and cautions around repository sources.
Installing the package changes what is available on the host. It does not create a media loop, connect YouTube, launch a background service or configure restart behaviour. Those are separate tasks, and keeping them separate makes faults easier to locate.
Verify the installed version
After installation, ask the binary to report its build information:
ffmpeg -version
Check that the command runs and note the version string and configuration information. The version may differ from examples in older instructions because Ubuntu releases and repository states differ. If you need a particular codec or encoder, the version line alone is not enough to prove support; inspect the available encoders too:
ffmpeg -encoders
The output can be long. You can search it for a relevant encoder name, for example with grep, but remember that the name you need depends on the output format and whether encoding will be done in software or by supported hardware. A listing shows what the binary exposes; it does not confirm that your source, CPU, or server hardware can use it successfully in a real stream.
If ffmpeg is not found, first check whether installation completed without errors and whether the shell can locate the program with command -v ffmpeg. If apt says it installed the package but the command is still unavailable, start a fresh shell and review the installation output and package state rather than installing a random binary over the packaged one.
A package upgrade is a separate decision from the initial setup. If a feature is missing, identify the exact encoder or behaviour required, then compare it with the build provided for your Ubuntu release. Third-party repositories can introduce different update policies and dependency behaviour. The convenience of a newer version has to be weighed against the ongoing task of trusting, monitoring and maintaining that source.
Prepare a looping or live input
Choose the source before writing the output command. For local prerecorded material, confirm the path, file permissions, format, duration and audio/video streams. Use ffprobe if it was installed with the package to inspect a file, for example ffprobe -hide_banner /path/to/video.mp4. A file that decodes correctly at the start may still have an issue near its end, so test the full file or a representative section before treating it as a reliable channel source.
For a simple single-file loop, FFmpeg’s input looping option can repeat an input. A basic pattern is:
ffmpeg -re -stream_loop -1 -i /srv/media/channel.mp4 \
-c:v libx264 -c:a aac -f flv "rtmps://INGEST_URL/STREAM_KEY"
This illustrates the separation between a continuing input and an output; it is not a universal ready-to-run command. Replace the placeholders with the URL and key from Live Control Room, and check that the installed build includes the selected encoder. -re reads the file at its natural rate rather than sending it as fast as possible, and -stream_loop -1 asks FFmpeg to repeat the input indefinitely. Local file paths, audio tracks, codecs, dimensions and output settings may require adjustments. If your source has no audio, or uses a layout YouTube does not accept as expected, address that deliberately rather than assuming the example will work unchanged.
For more than one prerecorded item, prepare a playlist or another source arrangement that preserves intended order and transitions. Check how the chosen method handles differing resolutions, frame rates, audio levels and gaps between files. A video folder is not automatically a continuous programme; if you are comparing desktop workflows, the guide to streaming a video folder with Streamlabs Desktop covers a different route.
A live camera, capture card or network feed has different failure modes from a local file. Device names can change, network streams can disappear, and input reconnection is not the same thing as restarting the whole FFmpeg process. Test the exact source path and reconnection behaviour. In India, a locally hosted file avoids repeatedly fetching the media over the internet, but the outbound broadcast still uses upload capacity; the data-use guide for 24/7 prerecorded streaming in India can help you estimate the traffic implications.
Configure the YouTube Live output
Create or select the broadcast in YouTube Live Control Room and copy the ingest URL and stream key shown for the chosen encoder workflow. Use the exact values supplied there; do not guess the URL format. YouTube’s encoder connection instructions explain where to find these values and how to connect an encoder. Store the key in a file with access restricted to the account that runs FFmpeg, or use another protected method appropriate to your setup. Avoid putting a real key directly in a publicly visible command, a world-readable service unit, or a repository. If it is exposed, replace it in YouTube Studio.
For a conventional FFmpeg stream, RTMPS is the sensible starting protocol. YouTube recommends RTMPS for this ingestion mode. HLS is a separate option for circumstances such as HDR or codecs not supported through RTMP; it uses HTTPS and segmented output and has different settings and latency. Do not paste HLS instructions into an RTMPS command or assume that changing a URL alone converts one protocol into the other. YouTube’s live encoder settings list the current protocol and encoding guidance.
Match the output codec, frame rate, keyframe interval and bitrate to YouTube’s current recommendations and to what the server and connection can sustain. YouTube’s cited RTMP/RTMPS guidance supports H.264, H.265/HEVC or 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. Use those as platform settings to check, not as proof that your particular FFmpeg command is configured correctly.
Bitrate depends on codec, resolution and frame rate. For H.264, YouTube recommends 5 Mbps at 1080p30 (with a stated minimum of 4 Mbps) and 8 Mbps at 720p60 (minimum 3 Mbps). It recommends 128 kbps stereo audio and 44.1 kHz for stereo. Those are YouTube’s guidance values, not a measurement of your server’s sustained upload. Choose a stable output rate that leaves room beneath measured, sustained capacity; brief speed-test peaks do not establish that a connection can carry the stream throughout the day. The ambient-stream bitrate guide provides a related way to think about YouTube output settings.
| Ingest choice | When it fits | What to account for |
|---|---|---|
| RTMPS | A conventional encoder stream where the selected codec is supported | YouTube recommends it; configure the matching encoder output and key securely |
| HLS | A case requiring a supported feature such as HDR or a codec not supported through RTMP | It is a distinct HTTPS segmented workflow with higher latency and separate playlist and segment requirements |
Before leaving a stream unattended, watch its preview in Live Control Room and read the stream-health messages. Use content with motion and audio similar to the real programme. A static test image or a short run with a quiet soundtrack may not reveal bitrate or audio issues that appear under normal material.
Keep the process available and test recovery
A command running in an SSH terminal is not a persistence plan. If the shell closes, the process may stop depending on how it was launched; even if it continues, a reboot or process failure still needs a response. For a long-running server workflow, a systemd service can start FFmpeg at boot and restart it after certain failures. That is process supervision, not a guarantee of an uninterrupted YouTube broadcast.
Create a service only after you can run and observe the command manually. Use a dedicated, unprivileged Linux account with access only to the media, configuration and logs it needs. Put sensitive values in a restricted configuration or environment file rather than exposing them in a unit file readable by every local user. Review file ownership and permissions. The Ubuntu systemd service documentation describes unit management; adapt its patterns to the actual command and account on your machine.
A unit commonly specifies the executable and arguments, a working directory where appropriate, the user account, and a restart policy such as restarting after a process failure. It also needs a deliberate stop behaviour and logging route. Do not enable a service before validating paths, quoting, key handling and the exact FFmpeg command: a service that repeatedly launches a bad command only produces repeated failures. Keep the configuration understandable enough that another operator can identify the input and output without exposing the key.
After creating or changing a unit, reload systemd’s unit definitions, start the service and inspect its state. For a unit named youtube-stream.service, useful checks include:
sudo systemctl daemon-reload
sudo systemctl start youtube-stream.service
sudo systemctl status youtube-stream.service
sudo journalctl -u youtube-stream.service
Enable it to start when the host boots only after the initial run is sound. Then test the recovery path in a controlled window: stop or restart the service deliberately, verify that it returns as expected, and confirm the YouTube preview receives media again. A process marked active by systemd only tells you about the local process. It does not establish that YouTube has healthy video and audio or that viewers can play the stream.
The host itself still matters. Compare an existing server, VPS or dedicated host by sustained upload, CPU capacity for the selected encode, source-file access, storage, process limits and the network route to YouTube. Hardware encoding may reduce CPU demand if supported and configured, while software encoding may be adequate for a modest output on a capable CPU. Neither choice fixes an unstable source or upload link. For a guide to the broader machine trade-off, see VPS versus a spare PC for looping videos.
Troubleshoot installation and stream issues
If apt cannot find FFmpeg, check the Ubuntu release, enabled repositories and the output of sudo apt update. A failed repository refresh can explain missing or stale package information. If installation succeeds but the binary is unavailable, use command -v ffmpeg, review apt’s output and confirm that your current shell’s path is normal. Do not assume that an unrelated download is a safe substitute for the distribution package.
If FFmpeg starts and exits immediately, run the command interactively with the same account and paths used by the service. Read the first meaningful error from stderr or the journal. Common causes include a typo in the input path, unreadable media, unsupported options in the installed build, an unavailable encoder, or invalid output credentials. When a service is involved, check systemctl status and journalctl -u youtube-stream.service; a restart loop can hide the first error among repeated messages.
If FFmpeg reports a successful connection but YouTube shows no usable picture or audio, compare the command’s output with the current Live Control Room settings. Check that you copied the right URL and key, selected the corresponding ingest protocol, and supplied a stream format YouTube accepts. Confirm that the media actually contains the expected streams and that your chosen output mapping includes them. The preview and stream-health messages are the deciding evidence for whether YouTube is receiving a healthy feed, not just a running process.
If viewers see buffering, investigate sustained upload capacity and output bitrate before increasing quality. Repeated drops can also point to network interruptions, an unstable live source, resource pressure, or a service restart policy that reacts to a failure without fixing its cause. Change one relevant factor at a time and test again with representative content. If the upload is shared with other activity, account for that competing traffic rather than treating the line’s advertised maximum as dedicated capacity.
If the stream stops at the end of a file, confirm that a loop or playlist is configured and that the input remains readable. If the stream returns after a process restart but not after a host reboot, inspect whether the service is enabled and whether its account can access the source at boot. Installation, persistence, restart recovery and successful YouTube playback are distinct checks; write down the outcome of each so a later change does not blur them together.
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 installing FFmpeg make the YouTube stream continuous?
No. The apt package provides FFmpeg, but you still need a continuing input, a valid YouTube output configuration and a process-management plan. Test the source, broadcast and restart behaviour separately before relying on a long run.
Which FFmpeg version will apt install?
There is no single version guaranteed by the command. It depends on your Ubuntu release and configured repositories, so check the installed build with ffmpeg -version and confirm required encoders with ffmpeg -encoders.
Should I use RTMPS or HLS?
For a conventional FFmpeg setup, RTMPS is the straightforward starting point and YouTube recommends it for that ingestion mode. HLS is a separate, higher-latency workflow for particular requirements such as supported HDR or codecs that RTMP does not support; use its own current documentation and output configuration.
Does systemd guarantee a 24/7 broadcast?
No. A systemd service can start at boot and restart a failed process according to its policy, but it cannot guarantee the source, host, network, credentials or YouTube ingest will remain healthy. Monitor both the local service logs and YouTube’s preview and stream-health messages.