To run a recorded video continuously on YouTube Live from Ubuntu, use FFmpeg to loop a local file and send it to the ingest address and stream key from YouTube Live Control Room. The command below is an example to adapt and test, not a tested uptime recipe or a guarantee that a stream will remain live.
Before leaving it unattended, confirm your channel can stream, check that the host can encode and upload the chosen quality, and arrange a way to notice and respond to failures. A process that loops a file is only one part of an always-on broadcast.
Check channel eligibility before preparing the stream
YouTube requires a verified channel with no live-streaming restrictions in the preceding 90 days to live stream. Check the current requirements and your account status in YouTube’s live streaming tips before spending time configuring an encoder. Eligibility is determined by YouTube, not by Ubuntu or FFmpeg.
If live streaming is not enabled, follow the steps shown in YouTube Studio and allow for any account-specific setup or activation time. Do not assume that creating a stream key means the channel is ready to go live. The official encoder setup guide explains how to create or select a stream and connect an encoder; check the current page because Studio screens and available settings can change.
Decide whether the broadcast should be public, unlisted, or private while you test. A private or unlisted test makes it easier to inspect the picture and sound without presenting a rough setup as the finished channel. Check the visibility setting again before publishing to your intended audience.
Prepare Ubuntu and the local video
First decide where the file and Ubuntu host will live. With a local machine, you maintain the operating system, power, and network connection. With a cloud VPS, the provider manages physical hardware, but you still need to manage the Ubuntu instance, your media file, the encoder process, and the stream key. Neither arrangement is automatically cheaper or more reliable for every channel.
| Consideration | Physical Ubuntu host | Cloud VPS |
|---|---|---|
| Hardware and operating system | You maintain the computer and Ubuntu installation. | The provider maintains the physical host; you maintain your instance and software. |
| Power and connectivity | Depends on your site, router, and power arrangements. | Depends on the provider and the instance’s network path. |
| File access | Convenient when the video is already on that computer or local storage. | The file must be transferred to a location the instance can read. |
| Optional power backup | A UPS can help with some brief local power interruptions, but not an internet outage. | A personal UPS is not relevant to the provider’s data centre. |
On Ubuntu, confirm you have an FFmpeg build available and understand how it was installed. Package names, build options, and supported encoders can differ by Ubuntu release and installation method. Check the installed version and its available options rather than assuming a command copied from another machine will work. The FFmpeg documentation describes the command-line options; use it alongside the help output for your installed build.
Place the video somewhere that the account running FFmpeg can read. A service account may not have access to a file in your personal home directory, even if you can open it from your login. Check the path, permissions, available disk space, and whether the file can be read from the host where the encoder will run.
Inspect the media before streaming. Confirm that it contains the video and audio you expect, that the picture has the intended dimensions and orientation, and that the sound is audible and not clipped. Test the parts near the start and end; an input that plays well once may still have an abrupt transition when it loops. If the file is a music playlist rather than one rendered video, the workflow and gap handling differ; see the guide to streaming a music playlist with OBS for that alternative.
Get the stream URL and key in Live Control Room
In YouTube Studio, open Live Control Room and create or select the encoder stream you intend to use. The page supplies the ingest URL and stream key. Use those actual values rather than guessing an address or reusing details from another stream. YouTube describes stream keys as a credential used to identify and authorise an encoder feed; treat the key like a password.
Prefer the RTMPS address when it is offered and supported by your encoder setup. YouTube says RTMPS encrypts data in transit to Google’s servers. The interface may show ordinary RTMP by default, so check the available stream settings and copy the address shown for your setup. YouTube’s encoder settings guidance covers supported ingest and video settings.
Do not put a live key into a public repository, a screenshot, a shared document, or a command that other users can read in shell history. A key embedded directly in a command can be exposed through terminal history or process inspection, depending on how the host is used. Restrict access to any script or service configuration containing it. If you think the key has been exposed, replace or reset it in YouTube Studio and update the encoder configuration.
Before sending a production feed, make a short test using the selected stream. Confirm that the preview appears in Live Control Room, inspect sound and motion, and check how the stream looks from its watch page. Do not move directly from a successful command launch to unattended operation: YouTube may report a connection while the viewer-facing picture or sound still has a problem.
Run the FFmpeg loop command
The following illustrates the shape of a single-file loop. It assumes an FFmpeg build with the listed options and a compatible local input. Replace the input path and ingest URL with your own values, and confirm the options against your installed version. This is an example, not a tested configuration, and it does not establish that any Ubuntu server can encode or sustain the stream indefinitely.
ffmpeg -re -stream_loop -1 -i /path/video.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://a.rtmp.youtube.com/live2/STREAM_KEY'
In this example, -re reads the input at its native rate rather than sending it as fast as possible. -stream_loop -1 requests that FFmpeg repeat the input indefinitely. The input path after -i must point to the file available on the host. The video and audio options select an output encoding, while -f flv sets the container format commonly used for RTMP ingest. These choices are illustrative; check that your build supports them and that the output settings fit the stream you plan to send.
The sample uses an RTMP-shaped address as an illustration. If YouTube provides an RTMPS URL for your encoder, use the provided endpoint and confirm your FFmpeg build and configuration support it. Do not simply append or remove characters to guess an encrypted endpoint. The stream key belongs in the URL in the form expected by the ingest service, but avoid leaving the real credential in a shared or publicly visible command.
The example’s bitrates are not a recommendation for every video or connection. YouTube’s published H.264 guidance lists 5 Mbps minimum and 14 Mbps recommended for 1080p30, and 3 Mbps minimum and 8 Mbps recommended for 720p30, as listed in its encoder settings guidance accessed in October 2026. These are YouTube’s encoding targets, not a measurement of your host’s upload capacity. Your actual output should match the selected resolution, frame rate, codec, and current guidance, while leaving room for fluctuations in the connection.
YouTube’s guidance calls for constant bitrate and a keyframe interval of two seconds, not over four seconds. The example’s -g 60 only corresponds to a two-second interval if the output frame rate is 30 frames per second. If your intended frame rate differs, adjust the keyframe setting accordingly and verify what FFmpeg is actually producing. Review the current recommendations before settling on a profile.
The same video can behave differently on a modest VPS, a powerful local computer, or a host already doing other work. Test with the intended file and quality, and watch CPU use, dropped frames, and network behaviour. If the machine cannot encode smoothly, reduce the output demands or use a host that can sustain them; if the connection cannot carry the feed consistently, lowering resolution or bitrate may be necessary. A static command cannot compensate for insufficient compute or upload capacity.
Check encoder output and YouTube stream health
FFmpeg’s terminal output is your first indication of what the encoder is doing. Watch for input or file errors, encoder initialisation failures, repeated reconnects, and signs that frames are not being processed as expected. A command that remains open is not proof that viewers are receiving a healthy stream. Save logs somewhere access-controlled if they include command details, and ensure the stream key is not recorded in a broadly accessible log.
At the same time, inspect YouTube’s Live Control Room preview and stream-health indicators. Check that the picture is moving, the audio is present, and the preview remains connected. YouTube recommends checking stream health and testing in advance in its live streaming tips. Also view the watch page as a viewer would, since a healthy encoder message does not verify every audience-facing setting.
A useful test is representative of the content you will actually run: include the normal picture changes, audio level, and file transitions. Listen through headphones and check that a loop does not create an unwanted silent gap, click, or abrupt cut. If the channel is a radio-style stream made from a playlist, consider whether playlist transitions require a different arrangement; the FFmpeg playlist gap guide addresses that particular issue.
Check sustained upload performance rather than relying on a brief speed-test peak. The outgoing stream needs capacity for its selected bitrate, and other devices or transfers can compete for the same connection. Leave headroom for normal variation, then observe an actual test stream under the conditions in which it will operate. If the connection varies, a lower and stable output can be more practical than a higher setting that repeatedly strains it.
Review the whole path before calling the test complete: FFmpeg can read and encode the file, Ubuntu can send the data, YouTube can ingest it, and the audience can hear and see the result. Keep notes on the chosen output profile, observed errors, and any changes made. This makes later troubleshooting more useful than restarting repeatedly without knowing what changed.
Keep the process monitored
A foreground FFmpeg process ends when the terminal session or host ends, and it can stop because of an error or interruption. For an unattended stream, decide how the process will be started after a host restart and how you will learn that it has stopped or become unhealthy. A terminal multiplexer can keep a session accessible, but it is not by itself a monitoring or recovery plan.
Ubuntu operators often use a process supervisor or a service manager to start a command at boot and restart a process after a crash. The appropriate configuration depends on your Ubuntu release, account permissions, secret handling, and the way the host is administered. Treat any sample service file you find elsewhere as something to review and test, not a universal recipe. A supervisor can restart FFmpeg when it exits; it cannot prove the new feed is healthy, restore missed footage, or guarantee a seamless broadcast.
Monitoring should include more than whether the process exists. Check the encoder’s logs, host resource pressure, connectivity, and YouTube’s stream-health view. Choose a practical alert path that you will actually see, and periodically verify the alert itself. If nobody is available to respond overnight, be clear about what the system can recover automatically and what still requires a person.
If you would rather not leave a computer or Ubuntu process running and maintain it, StreamNeo removes that specific operational burden: you upload the video once, provide the YouTube stream key, and the broadcast can continue with your own computer switched off, with monitoring and automatic restarts if it drops. It is YouTube-only, and the stream key still needs careful handling.
Plan for interruptions, archives, and recovery
Write down what you will do when the stream stops. Determine who can inspect the host, restart or repair the encoder, check the stream key, and confirm the audience-facing stream has returned. Keep a known-good copy of the input file and the working configuration somewhere you can reach, without putting credentials into a public backup. Test the recovery steps during a planned test rather than waiting for a night-time failure.
A process restart is not the same as continuous playback. If the connection drops, YouTube may show an interruption, and restarting the encoder does not recover the missed part or guarantee that the broadcast resumes without a visible break. YouTube recommends testing failover behaviour; decide whether your channel can tolerate an interruption and what you will tell viewers if one occurs. The article on what happens to Super Chats when a stream is interrupted discusses a separate consequence for channels using that feature.
Plan separately for recording or preserving the broadcast. YouTube’s encoder setup information says streams under 12 hours are automatically archived, as listed in its guidance accessed in October 2026. A single 24/7 continuous broadcast exceeds that stated threshold, so do not assume it will yield one complete archive. If a complete record matters, arrange a separate recording and storage plan and verify YouTube’s current behaviour for your channel and stream configuration.
Finally, keep the content and channel settings in view as well as the technology. A continuously repeated video needs to be appropriate for your channel and audience, and streaming by itself does not establish eligibility for monetisation. YouTube says live-stream monetisation is available to channels in the YouTube Partner Program; check the current official rules rather than treating a working encoder as approval.
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 this command guarantee a 24/7 stream?
No. It is an example of how to loop a local file and send an encoded feed, not a tested uptime configuration. The host, upload connection, YouTube ingest, file, and monitoring all affect whether the broadcast continues and appears healthy.
Can I use RTMPS instead of RTMP?
Use the RTMPS ingest URL shown by YouTube when it is available and supported by your encoder setup. YouTube describes RTMPS as encrypting data in transit to its servers. Retrieve the address from Live Control Room rather than guessing it.
Will YouTube save the whole 24-hour broadcast automatically?
Do not count on one complete automatic archive for a continuous 24/7 stream. YouTube’s encoder guide states that streams under 12 hours are automatically archived; verify current behaviour and make a separate recording plan if the full broadcast matters.
What should I check first if viewers see a frozen or missing stream?
Check whether FFmpeg is still running and inspect its recent output for errors, then check the host’s network and YouTube’s Live Control Room health and preview. Confirm that the key and endpoint are current and that the file remains readable. A restart may help when a process has exited, but it does not restore missed content or guarantee a seamless return.