Running an always-on YouTube stream with FFmpeg on Ubuntu 24.04 means setting up a YouTube Live event, sending a suitable media input through FFmpeg, and operating the host so you can detect and respond to failures. The pieces work together, but no process supervisor or command guarantees that one YouTube event will remain uninterrupted indefinitely.
This guide gives you a documented RTMP command pattern and a way to check your local FFmpeg capabilities before relying on it. Treat the example encoding values as a starting point to verify against YouTube’s current settings and your own media, not as a universal preset.
Verify YouTube Live eligibility and create an event
Before configuring Ubuntu, confirm that the channel can go live. YouTube Help says the channel must be verified and must not have had live-streaming restrictions in the preceding 90 days. Check the current YouTube Live streaming eligibility guidance in case the requirements or account status have changed. If live streaming is not available yet, resolve that first; a correctly built FFmpeg command cannot enable it on the channel.
Open YouTube Studio and go to Live Control Room. Create a stream or choose the scheduled stream you intend to use. Decide whether the audience should arrive at a scheduled watch page or whether you are preparing an unscheduled broadcast. That choice affects what you do after FFmpeg connects: for a scheduled event, YouTube’s workflow can require you to review the preview and use the Live Control Room control to go live.
An encoder connection and a public live event are related, but not the same operational step. Starting FFmpeg sends media to YouTube; check the event’s status and preview rather than assuming that a successful process launch means viewers can already watch. YouTube describes the encoder setup and event workflow in its live encoder guide.
A single local file also has an end. If you need a continuous sequence, plan the source and transitions as part of the production setup. The guide to keeping a livestream from ending when the video file finishes covers that editorial problem separately. A successful event setup will not make a finite input repeat by itself.
Get the ingest URL and protect the stream key
In Live Control Room, find the event’s encoder settings and copy the ingest server URL and stream key. The server and path are specific values YouTube supplies; do not substitute a guessed hostname or reuse a sample URL from a tutorial. Depending on the interface and event settings, you may see a server URL and a stream key intended to be combined by the encoder.
Treat the stream key like a password. YouTube’s stream key settings help explains how keys are managed and reset. If you think one has been exposed, reset it in YouTube Studio and update the encoder configuration. Do not publish it in a screenshot, paste it into a public issue, or leave it in a script that other users can read.
The simple command form shown later places the destination on the command line, which can leave sensitive text in shell history and may expose arguments to local process inspection. For a one-off test on a machine used only by you, consider those risks before typing the real key. For unattended use, arrange secret handling with the host’s access controls and your operational process; do not assume that putting the command in a service definition automatically makes the key private. Restrict who can read configuration and logs, and avoid logging the destination string if it includes the key.
YouTube recommends RTMPS for an encrypted connection. Confirm that your installed FFmpeg build supports the secure protocol and use the exact endpoint YouTube provides for the event. Do not change rtmp:// to rtmps:// by guesswork: the scheme, server address, and available protocol support must match the event and the local build.
Prepare the media input
For a file-based stream, choose a source whose video, frame rate, aspect ratio, audio and duration suit the channel. A devotional playlist, a lofi visual, and a local information loop put different demands on the input. Play it locally first, check that the audio is present and balanced, and inspect the beginning, a representative busy passage, and the end. If the source ends while FFmpeg is reading it, the process normally has no further file content to send; continuous programming therefore needs an intentional looping or playlist design.
The -re option in the documented pattern tells FFmpeg to read the file at its native rate instead of processing it as fast as it can. That is important when sending a prerecorded file as a live feed. It does not create a live event, repeat a file, repair an inconsistent source, or reconnect after a network failure.
Check what your actual Ubuntu installation can do rather than assuming every package build includes the same encoders and protocols. Run ffmpeg -version, ffmpeg -protocols and ffmpeg -encoders on the host. Confirm that the intended video encoder, audio encoder, and output protocol are available. The FFmpeg project notes that its online documentation is regenerated for the newest revision and advises users of older releases to consult documentation for their installed version; see FFmpeg documentation. If an encoder is missing, identify a suitable package or build for your system and verify its source and support before changing the production host.
Live cameras, capture devices and network inputs use different input options and have different failure modes from a local MP4 file. Do not paste a file command into a camera workflow and expect it to work unchanged. For media that should repeat without a visible gap, test the actual transition and audio continuity before scheduling it. The article on looping recorded lectures into a 24/7 stream is useful for thinking through the programme and file-boundary side, though the command syntax you use still needs to be checked against your installed FFmpeg version.
Build the FFmpeg RTMP command
The FFmpeg project documents this basic real-time file-to-RTMP pattern in its protocol examples:
ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
Replace myfile with your input file and replace the sample destination with the current ingest URL and stream path from Live Control Room. The example establishes the shape of the command, not a claim that the sample server exists or that your build has every required codec. RTMP output uses the FLV container in this documented pattern.
For a typical SDR file, the following is an illustrative H.264/AAC command pattern. It assumes that the installed FFmpeg has libx264 and AAC encoding available; check before using it. The destination is a placeholder, not a real YouTube key.
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4500k \
-maxrate 4500k -bufsize 9000k -pix_fmt yuv420p \
-g 60 -c:a aac -b:a 128k -f flv \
'rtmp://INGEST_SERVER/live/STREAM_KEY'
These values are an example, not settings tested as a complete Ubuntu 24.04 recipe and not a universal YouTube preset. In particular, -g 60 means a 60-frame group of pictures. At 30 frames per second, that is a two-second keyframe interval; at a different frame rate, choose a GOP that corresponds to the intended interval. YouTube recommends a two-second keyframe interval and says it should not exceed four seconds. Its current encoder settings table lists supported codecs and resolution-specific guidance. Use the matching current row for your output rather than copying the sample bitrate blindly.
YouTube’s published ordinary SDR guidance includes H.264, H.265 or AV1 video, up to 60 frames per second, constant bitrate, and AAC or MP3 audio for RTMP/RTMPS. The recommendation for H.264 at 1080p30 is 10 Mbps, as listed in YouTube Help’s encoder settings accessed in October 2026. That is a YouTube recommendation for that format, not a promise about picture quality on every source or connection. Do not mix H.264 values with another codec’s table, or apply this SDR example to an HDR workflow without checking the separate requirements.
The sample uses a constant target and maximum video bitrate, a buffer value, pixel format, and AAC audio bitrate. These are command-line choices that need to fit the source, output resolution and available upload capacity. Start by matching the output to the media and the YouTube table, then test motion and sound. If you change the encoder, resolution or frame rate, revisit the bitrate and GOP rather than assuming the old values still make sense.
Run FFmpeg reliably on the Ubuntu host
A reliable operating plan begins with a known-good manual test. Run the command in a controlled session, check FFmpeg’s output for input and encoding errors, and confirm that Live Control Room receives a preview. Only after that should you decide how the process will run unattended. Keep a record of the command options, input path, event identity, and how the person on duty can stop or restart the process without exposing the key.
Ubuntu can run long-lived processes under a supervisor such as systemd, but a supervisor only manages a local process. A restart policy may relaunch FFmpeg after it exits; it cannot decide whether YouTube still considers the original event active, whether a reconnect is accepted, or whether viewers have landed on the intended watch page. A service that restarts repeatedly without alerting anyone can conceal a broken stream rather than solve it.
If you create a systemd unit, test it first with a non-production stream and document its user, working directory, environment and log destination. Use a restricted account and file permissions appropriate to the media and secret configuration. Decide how an operator will discover repeated restarts, inspect logs, and stop the unit deliberately. Do not copy a generic unit from another server without checking paths and security settings. This guide does not provide a tested unit file, so treat any service definition as host-specific work.
For a local file, plan separately for process failure and media completion. A restart after a crash may simply start the same file from its beginning, while a normal end-of-file may be treated differently from an error. Repeating a source or selecting the next item requires an explicit playback design. Verify exact loop-option syntax in ffmpeg -h full or the manual for the installed version before putting it into an unattended command. The guide to restarting a failed FFmpeg stream automatically discusses recovery as a separate concern; its Raspberry Pi examples should not be assumed to apply unchanged to Ubuntu.
If the main reason you are considering a VPS is avoiding a computer that must stay switched on at home, there is also a managed route: StreamNeo takes a file and YouTube stream key so you do not have to keep your own Ubuntu host running and watch its local FFmpeg process. It still depends on a correctly prepared file and YouTube event, and you should choose it only if a file-based, YouTube-only workflow fits your channel.
Monitor network and stream health
A process marked active is not proof of a healthy broadcast. Keep three checks distinct: FFmpeg is running and reading the input, the host can upload the outgoing stream, and YouTube is receiving acceptable audio and video for the intended event. Watch Live Control Room’s preview and stream-health indicators during testing and while an operator is available. Also check the public watch page from a viewer’s perspective when appropriate.
YouTube recommends that your available upload capacity exceed the stream’s total outgoing bitrate by 20%, as listed in its streaming tips accessed in October 2026. This is headroom guidance, not a guarantee against congestion, packet loss, router issues or an ISP outage. The total includes video and audio; if you run another upload or a backup encoder on the same connection, that traffic competes for capacity. YouTube’s streaming tips also advise testing with movement and audio similar to the real programme.
Run a speed test from the actual connection you will use, preferably at a time and under conditions representative of operation. Then test the real stream for long enough to observe changing scenes, audio and transitions. A still image with silence is not a meaningful test for a music or video channel. Watch for dropped frames, encoder overload, audio clipping or silence, and changes in YouTube’s stream health. A speed-test result by itself does not model every evening’s network conditions.
Keep a simple incident path. Note where FFmpeg logs are written, how to check the process and supervisor status, who should receive an alert, and what the operator should inspect in Live Control Room before restarting. Repeated failures need diagnosis: input read errors, an unsupported encoder, credentials, network interruption and event state call for different responses. If you use a backup encoder, test the switch deliberately and account for the additional outgoing bitrate; a backup is not useful if the connection cannot carry both feeds or nobody knows how to activate it.
Always-on is an operating goal, not a property conferred by the command. YouTube says streams under 12 hours are automatically archived in its current encoder workflow guidance, accessed in October 2026. Do not infer from that that a single event or archive will continue forever. For a channel meant to be available around the clock, define who checks it, how long each event should run, and what the response is if the event ends or the host loses connectivity.
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
How do I loop a video on YouTube Live with FFmpeg?
The basic command sends a file in real time, but it does not establish a repeating playlist. FFmpeg options and their exact syntax vary by installed version, so check ffmpeg -h full or the versioned manual before adding looping behaviour. Test the transition, audio continuity and what happens at end of file before relying on it unattended.
What do I put in FFmpeg for my YouTube stream key?
Use the ingest URL and stream path supplied for the event in Live Control Room; the RTMP example’s destination is only a placeholder. Protect the key as a credential and avoid leaving it in shell history, readable scripts, logs or shared screenshots. If it is exposed, reset it in YouTube Studio and update the encoder.
How do I restart FFmpeg if my livestream stops?
A process supervisor can restart FFmpeg when the local process exits, but first identify why it stopped and check YouTube’s event state. A restart does not guarantee that the original event or watch page remains live. Configure logging and a way to notice repeated failures, then test recovery before using it for an unattended channel.
Does Ubuntu 24.04 include every FFmpeg feature this command needs?
Do not assume so: installations and package builds can differ. Check ffmpeg -version, ffmpeg -protocols and ffmpeg -encoders on the actual host for the selected encoder and output protocol. If something is unavailable, verify the package or build you plan to install rather than relying on a tutorial’s assumptions.