To stream a looping video to YouTube Live from an Ubuntu server, run FFmpeg on an always-on host, point it at a readable media file, and send its output to the RTMPS address and stream key for your broadcast. The command below is an illustrative template only: it has not been executed or tested, and you must check your FFmpeg build, media, bitrate and Live Control Room settings before relying on it.
A server can keep the process running while your own computer is switched off, but that does not guarantee uninterrupted delivery. The host still needs a dependable power and network connection, the video and key must remain accessible, and you need to monitor YouTube's preview and stream health. If you would rather not maintain an encoder process yourself, a cloud workflow such as StreamNeo removes the need to keep your own computer running for the broadcast.
Prepare an Ubuntu host that can stay on
An Ubuntu server is the machine that reads the file and runs FFmpeg for as long as you want the broadcast to continue. It could be a computer you maintain yourself or a rented host; whichever you choose, confirm that its operating terms, network connection and expected running costs suit a long-running stream. The available research does not establish a particular server size or provider plan, so avoid choosing a host based on an unsupported claim that a certain specification is enough.
The stream is only as continuous as the whole path from file to YouTube. A reboot, network interruption, exhausted storage, account problem or stopped process can interrupt it. An always-on host is a prerequisite, not an uptime promise. Decide who will notice a problem and what they can do if the preview goes offline, especially if the channel is meant to run unattended overnight.
Check outbound upload capacity against the selected video and audio bitrate, and leave practical headroom rather than matching the internet connection exactly to the stream's target rate. Congestion, other applications using the connection, or changes in network conditions can affect delivery. A speed test can give you a useful indication, but it does not guarantee what the connection will sustain at every hour.
If you are weighing a server against a managed encoder, the decision is mainly about who maintains the process and how much control you need over it. Our comparison of cloud encoder and VPS trade-offs is useful background, although its gaming example is not a substitute for checking your own requirements. A server gives you direct control over the command and files; it also leaves you responsible for keeping the process, host and credentials in order.
Check FFmpeg's protocols and codecs
FFmpeg needs to read your chosen input, encode or pass through the media appropriately, and output an FLV stream to the YouTube RTMPS endpoint. Builds differ. Before designing around a particular command, check that the FFmpeg installation has the output protocol and codecs you intend to use. The FFmpeg protocol documentation describes RTMP-family protocols and file input patterns, but its examples do not certify every Ubuntu package or build.
The command later in this guide uses libx264 for H.264 video and AAC for audio. Do not assume those encoders are available merely because a command can be copied into a terminal. Check your build's configuration and documentation, and confirm which audio and video streams the source file contains. If a required encoder or protocol is absent, select an FFmpeg build that supports it or adapt the approach; exact installation commands and minimum versions vary by Ubuntu release and have not been verified here.
The destination should use RTMPS copied from the current stream settings. YouTube describes RTMPS as RTMP carried over TLS/SSL and recommends it for secure delivery. Its guidance explains that the connection encrypts data to and through Google's servers. See YouTube's RTMPS instructions rather than relying on an old URL copied from a tutorial.
Put the media somewhere FFmpeg can read
Upload or copy the video to the Ubuntu host, then verify the exact path and filename. The process must be able to read the file under the user account that runs FFmpeg. A path that works in your interactive shell may not work for a service or scheduled process running with a different account, so check file permissions and avoid depending on a mounted drive that may disconnect.
Inspect the media before sending it live. Confirm that it has the audio and video streams you expect, that playback works, and that the sound is neither missing nor unexpectedly silent. Consider whether its aspect ratio, resolution, frame rate and audio format suit the broadcast you intend to make. A single file that loops continuously should also have a sensible beginning and ending: an abrupt cut, silence, or long black frame will recur at every loop boundary.
If you are deciding between one long file and a playlist workflow, remember that looping one input is not the same as scheduling or switching between separate items. For context on an alternate desktop workflow, see how OBS handles looping a source file. That article concerns OBS rather than this FFmpeg command, but the practical question is similar: what should the viewer see and hear when the media reaches its end?
Keep a known-good copy somewhere appropriate before editing or replacing the file on the host. If you replace media while FFmpeg is reading it, behaviour can depend on how the file is opened and changed; do not treat an in-place replacement as a safe way to update a live broadcast. Plan a controlled stop and restart if the video needs to change.
Get the current URL and key from Live Control Room
Open YouTube Live Control Room, create or select the intended stream, and copy the RTMPS URL and stream key shown in that stream's settings. Use the values for this broadcast, not an endpoint or key from an unrelated example. YouTube's current encoder settings and stream guidance is the reference for settings, while the stream's own settings supply the destination credentials.
Treat the stream key as a password. Anyone who obtains it may be able to send video to the associated stream, so do not paste a real key into a public guide, ticket, chat, screenshot or repository. The examples below use only placeholders. Do not test by publishing a key in a command that others can see; shell history and process listings may reveal command-line arguments depending on how you run the process.
Before starting, check that the broadcast selected in Live Control Room is the one you intend to use, and note what its preview shows when the encoder connects. If the connection fails, first compare the URL and key against the current settings and make sure the address is RTMPS rather than assuming an RTMP example is interchangeable. YouTube's RTMPS page distinguishes the secure protocol from the unencrypted alternative.
Choose settings and build a loop command template
Pick codec, resolution, frame rate and bitrate together. YouTube's encoder table lists H.264 recommendations including 5 Mbps for 720p at 30 fps, 10 Mbps for 1080p at 30 fps, and 14 Mbps for 1080p at 60 fps. These are configuration recommendations, not guarantees about what your connection can deliver. Check the current table for your precise combination rather than treating one of these examples as a universal setting.
For stereo audio, YouTube lists AAC or MP3 as supported and recommends 128 Kbps at 44.1 kHz. The input and chosen encoder need to support the settings you use. The template below encodes AAC audio at 128 Kbps, but you should confirm the source has an audio stream and check the actual preview. Similarly, -g 60 means a group of 60 frames; it corresponds to a two-second keyframe interval only when the video runs at 30 frames per second. Set the GOP size to match the selected frame rate and YouTube's guidance.
Untested Ubuntu/FFmpeg command template — adapt before use. Replace the file path and RTMPS destination placeholders with your own values, and adjust the settings to match your media, FFmpeg build and current YouTube recommendations. The template is illustrative and has not been executed or tested.
ffmpeg -re -stream_loop -1 -i "/path/to/video.mp4" \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-b:v 4500k -maxrate 4500k -bufsize 9000k -g 60 \
-c:a aac -b:a 128k \
-f flv "RTMPS_URL/STREAM_KEY"
This is not a ready-made YouTube command for every file or build. The bitrate values shown are template values, not a recommendation for every resolution or frame rate; choose a rate from YouTube's current guidance and check your upload capacity. The -stream_loop -1 pattern is used in an AWS example, but that example's endpoint and service-specific arguments are for AWS IVS and must not be copied as YouTube settings. The FFmpeg documentation's RTMP material supports the general file-to-network-output pattern; it does not validate this complete command against your installed software or media.
The -re option reads a file at its native playback rate rather than sending it as fast as possible. -stream_loop -1 requests repeated input, while -f flv selects the output container used for this style of RTMP-family delivery. The codec, pixel format, bitrate controls and GOP value are encoder choices that may need adjustment. In particular, the endpoint syntax must come from Live Control Room. Do not assume another service's path format, such as an /app/ suffix, applies to YouTube.
Test the process and watch stream health
Do a representative test before depending on the broadcast. YouTube advises testing representative motion and audio and monitoring stream health and messages. Check that the preview shows the right picture, that sound is present and intelligible, and that motion plays as expected. A static image may conceal problems that appear only when the source has movement or complex detail.
Start with a test whose consequences are manageable. Watch the encoder output for errors and check Live Control Room for connection status, preview and stream-health messages. If YouTube reports poor health, compare codec and bitrate with its current recommendations, then test the outbound connection. If the connection fails outright, recheck the RTMPS URL and key from the selected stream rather than blindly changing unrelated encoding options.
For long runs, plan how you will observe the process and respond to a stopped encoder or lost connection. A terminal window alone is not a monitoring plan if nobody is looking at it. Use a process supervisor or other restart arrangement only after understanding how it behaves, and test recovery deliberately; automatic restarting cannot fix a wrong key, an unreadable file or an unavailable network. Keep the distinction clear between restarting the local process and YouTube accepting a healthy stream.
Audio deserves its own check. Listen near the beginning and around the loop boundary, since a file may contain an unexpected gap or abrupt transition. For a stream that runs for a long time, gradual audio/video timing problems may be noticeable; our notes on audio drift in a long-running YouTube stream discuss that symptom in an OBS context. It is not proof that the same cause or fix applies to every FFmpeg stream, but it is a reminder to monitor both sound and picture rather than judging from a single preview frame.
Keep the stream key out of logs and history
A key embedded directly in the example command can be retained in shell history, exposed in a screenshot or copied into a log. Avoid saving a command containing a real key in a public or shared place. Do not paste it into support requests, source control, documentation or chat. If a key has been exposed, use the controls in Live Control Room to manage it and check the current official guidance for the appropriate response.
Also consider where command arguments may be visible to other users on the same host, and who can read the account's files, history and process information. Limit access to the account that runs the encoder. If you create a protected configuration file or environment-based mechanism, set permissions appropriately and understand what your process manager records; these techniques reduce casual exposure but do not make a secret impossible to disclose.
Keep logs useful without recording credentials. Redact the destination if your logging setup might capture it, and inspect any error output before sharing it. A screenshot of a successful configuration can expose the key just as readily as a failed command. Stream-key hygiene is part of the operating procedure, not a step to remember only after the stream is live.
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 I run this with my Ubuntu computer switched off?
Only if FFmpeg is running on a separate host that stays on and can reach YouTube. A server does not remove the need to maintain its network, files, process and account access, and it cannot guarantee uninterrupted delivery.
Is the command ready to paste into a terminal?
No. It is an untested template. Check FFmpeg's protocol and codec support, replace the placeholders privately, and adapt bitrate, frame rate and keyframe interval to the actual source and current YouTube guidance.
Why use RTMPS instead of an RTMP address from an example?
YouTube recommends RTMPS, which carries RTMP over TLS/SSL. Copy the endpoint and key from the stream's current Live Control Room settings; examples for other services may use different URL formats and arguments.