A 24/7 YouTube stream from an Ubuntu VPS can be built with FFmpeg, but a running process is not proof that viewers are receiving healthy video. The reliable approach is to use YouTube’s current encoder details, protect the stream key, test your media and settings, and monitor both the VPS and YouTube.
This guide is for a prerecorded video, audio programme, or playlist sent to YouTube Live. Commands below are examples to adapt and test against your Ubuntu release, FFmpeg build, media, and chosen output settings; none guarantees uninterrupted service.
Prerequisites: access, media, and a VPS
You need an Ubuntu VPS you can administer, media you are entitled to stream, and a YouTube channel with Live access. Check the channel’s current access status in YouTube Studio before preparing a long-running service. YouTube’s Live streaming overview explains the current setup and access flow; requirements and interface details can change, so use the page as the authority rather than an old screenshot or tutorial.
Choose a VPS based on the workload you will actually run. If FFmpeg re-encodes video, CPU demand depends on the codec, resolution, frame rate, and encoding settings. If it copies an already compatible stream, the CPU work may be lower, but you have less control over the incoming format and must still confirm that YouTube accepts it. There is no universal CPU or memory minimum that fits every source and output.
Check outbound transfer terms as well as connection speed. A constant payload of 1 Mbps for 30 days works out to roughly 324 GB in decimal units before protocol overhead; this is arithmetic from the bitrate and duration, not a provider allowance or a YouTube estimate. Ask the VPS provider how outbound data is metered and whether sustained transfer is permitted. A short speed test can show a connection’s conditions at that moment, but it cannot establish that the route will stay healthy overnight.
Before uploading anything, confirm that your files play correctly and that you have the necessary rights to stream their video and audio. Keep an untouched copy of original media. For a useful checklist on keeping evidence organised, see how to document video and music licences for a YouTube livestream review. Rights and platform review are separate concerns; keeping records is prudent, but it does not guarantee approval.
Create the live event and collect encoder details
In YouTube Studio, create or schedule the live stream, then open Live Control Room and find the encoder details for that event. Copy the ingest URL and stream key exactly as displayed. Select the RTMPS URL when YouTube offers it: RTMPS carries RTMP over TLS/SSL, encrypting the connection between the encoder and ingest endpoint. YouTube’s stream with an encoder guidance describes the current workflow and where those details appear.
Treat the stream key like a password. Anyone who has it may be able to send a broadcast to the associated stream, so do not paste it into a public forum, commit it to a repository, or include it in a command that will be saved in a shared shell history. Use the event’s current details rather than reusing an old key without checking that it is still the right one. If you think the key has been exposed, replace or reset it in YouTube Studio and update the service configuration.
YouTube can show an ordinary RTMP URL by default in some flows. Check the scheme and host rather than assuming the first displayed address is encrypted. If an RTMPS connection fails, compare the configured destination with the current values in Live Control Room, then consult YouTube’s connection guidance, including its port 443 advice where applicable. Do not “fix” a TLS problem by switching to a guessed endpoint.
Install and verify FFmpeg on Ubuntu
Ubuntu package availability and FFmpeg build options depend on the release and configured package sources. Install FFmpeg using a suitable source for your release, following the package guidance for that system rather than copying a command intended for a different Ubuntu version. Record the version and inspect the local build before planning around a codec or protocol.
Useful checks include:
ffmpeg -version
ffmpeg -protocols
ffmpeg -codecs
These report information about the binary you installed; they do not prove the entire broadcast path works. Check that the build includes the input and output protocols and codecs you intend to use, and note the version in your operating notes so you can relate later behaviour to an update. Ubuntu’s server documentation is the appropriate place to check release-specific system administration guidance.
Run FFmpeg as a dedicated, unprivileged account for the broadcast rather than as root. Give that account access only to the media, configuration, and log locations it needs. Keep the operating system and packages maintained, but plan updates deliberately: a service restart or reboot can interrupt an active event. Ubuntu notes that update-related service restart behaviour can depend on release and configuration, so check the guidance for the version you run and schedule maintenance with the stream in mind.
Prepare a file or playlist workflow
Start with one representative file and confirm that it decodes, plays through to the end, and has the expected audio. Use ffprobe if available to inspect codecs, dimensions, frame rate, and audio streams. A devotional video with a still image and music, a lofi loop, and a news package with frequent motion may place different demands on the encoder even at the same output resolution.
A loop can repeat a file, and a playlist can sequence several items, but either approach needs testing at the transitions. Listen for silence or a sudden volume change at the join; look for a blank frame, unexpected aspect ratio, or a pause. If the source has incompatible properties, combining files does not automatically make them seamless. Keep filenames and paths stable, and ensure the service account can read every input.
For an already compatible input, stream-copying may reduce encoding work. It also means the source determines more of the output characteristics, so inspect it and verify the resulting stream in YouTube. Re-encoding gives you control over output codec, dimensions, frame rate, and bitrate, but requires a CPU that can sustain the selected settings. Test representative content for long enough to expose heat, load, or loop-boundary issues, rather than assuming that a file that plays locally will behave well as a live feed.
An FFmpeg command commonly uses -re to read a file at its native playback rate and -f flv for an RTMP-family destination. The FFmpeg documentation’s protocol examples demonstrate the general publishing shape, not a complete YouTube configuration. A simple example such as ffmpeg -re -i input.mp4 -f flv rtmp://example/live/key is deliberately not ready to paste: the destination is a placeholder, there are no selected encoding settings, no loop behaviour, and no protection for credentials. Build from your actual file and YouTube details, then test.
If you need a more detailed example of the general VPS and FFmpeg workflow, the Indian VPS guide to an always-on YouTube stream may help you compare the choices. It is a separate configuration, not a command to copy unchanged. If you are using a multi-item audio programme, the continuous podcast stream guide offers another useful context for planning source order and continuity.
Choose output settings and protect the key
Use YouTube’s current encoder table as the source of truth. Its recommended live encoder settings list RTMP/RTMPS, supported video codec options including H.264, H.265/HEVC, and AV1, AAC or MP3 audio, constant bitrate encoding, frame rates up to 60 fps, and a recommended two-second keyframe interval that should not exceed four seconds. Settings depend on resolution and frame rate; do not assume the same bitrate or codec choice applies to every stream.
The table below reproduces selected values from YouTube’s published settings. The alternate latency column has different recommended and maximum values. These are platform settings, not evidence that your VPS or network can sustain them continuously.
| YouTube output example | Standard column: video bitrate | Alternate latency column: video bitrate | Audio detail listed |
|---|---|---|---|
| 720p at 30 fps | 2 Mbps minimum; 6 Mbps maximum | 3 Mbps recommended; 8 Mbps maximum | Stereo: 128 Kbps |
| 480p at 30 fps | 0.3 Mbps minimum; 3 Mbps maximum | 0.4 Mbps recommended; 4 Mbps maximum | Stereo: 128 Kbps |
| 360p at 30 fps | 0.3 Mbps minimum; 3 Mbps maximum | 0.4 Mbps recommended; 4 Mbps maximum | Stereo: 128 Kbps |
YouTube lists 44.1 kHz for stereo audio and 48 kHz for 5.1 surround, with 384 Kbps for 5.1 audio. Treat these as values from its current guidance, not a universal prescription. For an ordinary stereo programme, inspect the source and select a compatible output rather than forcing surround settings that the media does not contain.
Size outbound capacity for the chosen video bitrate plus audio and protocol overhead, and allow for the provider’s transfer accounting. Prefer a quality level that fits the connection you can sustain over one that only works in a brief test. YouTube transcodes live streams for viewers, but that does not remove the need to send it a valid, steady encoder feed.
Keep the key out of scripts that are readable by other users. One practical pattern is to place the destination and key in a root-owned configuration file with restrictive permissions, readable by the service account only where possible, or to use an appropriate secret mechanism available on your system. Avoid putting credentials directly in a command line that other local users or diagnostic tools could inspect. Restrict access to logs too, since errors or debug output can sometimes repeat destination details. Rotate a key after accidental disclosure.
Run a short test and check YouTube health
Before scheduling an unattended broadcast, start a private or otherwise controlled test event if that suits your channel workflow. Test the actual file or playlist, the actual VPS, and the intended output settings. Include a segment with representative motion and audio, then check the video and sound on the watch page as well as the status shown in Live Control Room. YouTube advises testing before going live and monitoring stream health.
Watch for warnings about the incoming feed, dropped or unstable delivery, audio problems, and differences between the encoder’s output and the public playback. Check that the picture is not stretched or unexpectedly soft, that the audio is present and in sync, and that the event is receiving data. A process can appear active while the remote stream is frozen or not reaching viewers, so local status alone is not enough.
Use the test to compare encoding choices. If CPU remains heavily loaded or the output stutters, try a lower resolution or frame rate, or determine whether a compatible source can be stream-copied. If the source is not accepted or the output misses YouTube’s current settings, re-encode with a suitable configuration and test again. Do not infer from a successful short test that every network condition or overnight period will be trouble-free.
Add recovery and monitoring for failures
A service manager such as systemd can start FFmpeg at boot and restart it after an unexpected process exit. A restart policy is useful for process failures, but it cannot establish that the YouTube ingest or public playback remains healthy. Configure the service with the dedicated account, stable media paths, protected credentials, useful logs, and a deliberate restart delay. The exact unit settings depend on your chosen command and Ubuntu release; test the unit rather than deploying an unverified template.
For example, a service definition might set a working directory, run the FFmpeg command as the broadcast account, and specify a restart policy for failures. Keep the actual stream key outside the unit file where it might be exposed through broad file access or management tooling. Ensure logs rotate or have a sensible retention policy, since a long-running encoder can generate a large log. Check systemctl status and the journal when troubleshooting, while remembering they describe the local process, not the end-to-end stream.
Build a monitoring routine that checks two sides. On Ubuntu, look at service state, recent logs, disk availability, and whether the expected input files remain accessible. In YouTube Live Control Room, inspect stream health; also view the public watch page from a separate device or connection. This matters because a silent remote freeze may not cause the local process to exit. The plain-English guide to live streaming terms can help distinguish an encoder process from the ingest and viewer-facing stream.
Test recovery in a controlled period before relying on the setup: stop and start the service, simulate a process exit, reboot the VPS, and confirm what happens to the event. Test a missing or unreadable media file, a network interruption if you can do so safely, and a key rotation. Record the expected manual action for each failure. A restart loop can repeatedly fail if the key is wrong or the media path is broken, so alerts and a human response path still matter.
StreamNeo addresses a different operational burden when the problem is keeping a personal computer powered and maintaining the broadcast process: you upload the video, provide YouTube’s stream key, and the stream runs without your computer, with monitoring and automatic restarts if it drops. It is YouTube-only, and it does not remove the need to choose suitable media, confirm your channel details, or review the live result.
Plan capacity and maintenance for continuous use
A live encoder sends data for as long as the event runs, so a VPS plan that looks adequate for occasional uploads may not suit a continuous broadcast. Estimate transfer from your chosen sustained bitrate, include audio and overhead, then compare that estimate with the provider’s metering and permitted use. Do not assume a “large” monthly allowance is unlimited or that an advertised network speed is a guarantee of steady delivery.
Also consider what happens when you change source files or update the system. Keep a known-good copy of the configuration and media, document where credentials are stored without writing the key itself into the notes, and schedule a test after FFmpeg or Ubuntu updates. If you change codec, bitrate, playlist order, or stream key, verify the new configuration with a short controlled broadcast before relying on it.
A useful operating note can be brief: the Ubuntu release and FFmpeg version, media path, selected YouTube output settings, service name, log location, and recovery steps. Record the date you last tested a restart and checked the watch page. That creates a repeatable handover for you or another operator without confusing a green local process status with verified viewer playback.
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
Can FFmpeg loop one video continuously on YouTube Live?
FFmpeg can be configured to repeat a file, but the command must match the input, output format, and current YouTube encoder guidance. Test the join for silence, blank frames, or a pause, and monitor the remote stream rather than assuming that a repeating local file means continuous viewer playback.
Should I use RTMP or RTMPS?
YouTube supports both RTMP-family delivery and recommends the encrypted RTMPS option when available. Copy the URL shown for your event in Live Control Room and keep its stream key secret; do not substitute a guessed address if a connection fails.
Will systemd keep the broadcast online all the time?
Systemd can start FFmpeg and restart it after some process failures, but it does not prove that the ingest endpoint or watch page is healthy. Check service logs and state alongside YouTube’s stream health and public playback, and define how you will respond to failures that an automatic restart cannot resolve.
What Ubuntu VPS size do I need?
There is no single verified CPU or memory minimum for every combination of source and output. Re-encoding requires more processing than copying a compatible stream, while sustained bandwidth and transfer allowance depend on the bitrate and duration you choose. Test the actual workload and confirm the provider’s outbound-use terms.