A YouTube 24/7 stream with FFmpeg on Ubuntu needs four things: an enabled YouTube channel, a repeating video file, a carefully configured encoder, and a plan for failures. FFmpeg can keep sending the file, but it cannot guarantee that YouTube, your connection, or the Ubuntu machine will remain available.
You will create the live stream in YouTube Studio, keep its stream key private, test the media locally, and publish it over RTMPS. The example below is a starting pattern rather than a tested recipe for every Ubuntu release or FFmpeg build, so check the options supported by the software installed on your machine.
Enable and check the YouTube channel
Before touching FFmpeg, confirm that the channel is allowed to livestream. YouTube says the channel must be verified and must not have a live-stream restriction within the previous 90 days. First-time live-stream activation can take up to 24 hours, so do this before the planned launch rather than immediately beforehand.
Open YouTube Studio and look for the Live Control Room. If YouTube asks you to enable live streaming, complete that process and wait for the channel to become eligible. The current requirements and activation steps are described in YouTube's live-streaming help. Check the page again when you set up the channel because platform requirements can change.
This check matters even if the Ubuntu computer and FFmpeg are working correctly. A rejected or unactivated channel will not become usable because the encoder keeps retrying. Equally, a channel restriction is a YouTube-side issue, not something a process supervisor can repair.
Decide what the stream is meant to contain before you create it. A devotional loop, a lofi station, a local news loop and a shop promotion may all use the same FFmpeg pattern, but their media rights, update frequency and audience expectations differ. For example, a shop may need to replace the file when an offer changes, while a bhajan channel may use one long prepared programme.
If your source is a single devotional loop, review the practical considerations in how Hanuman Chalisa loop channels are run. That is separate from the technical ability to send the file: a file can encode successfully and still contain material you should not broadcast.
Create a live stream and protect its key
In YouTube Studio, open Live Control Room and create or select a stream. YouTube will provide an ingest URL and a stream key. The exact labels and URL format can vary with the current Studio workflow, so use the values shown for the stream you are configuring rather than copying a URL from an old tutorial.
Treat the stream key as a credential. Do not place it in a public shell script, Git repository, screenshot, article, support ticket or shared chat. Do not send it to somebody who only needs to edit the video. Anyone who obtains the key may be able to send a feed to that stream.
A safer arrangement is to keep the key in a protected environment variable or a local file with restricted permissions, and to prevent shell history from recording the command containing it. The exact approach depends on how you administer Ubuntu, but the principle is the same: the key should not be visible to other users or accidentally backed up with public project files.
If you think the key has been exposed, reset it in YouTube Studio before testing again. A key reset means that any old command, service configuration or saved environment value must be updated. The YouTube encoder guidance explains the role of the stream URL and key and should be your reference for the current Studio interface.
Keep a written record of which local file and Ubuntu machine belong to which YouTube stream, but do not record the secret itself in that document. This becomes useful when you operate several channels and need to identify the correct stream without pasting credentials into every troubleshooting note.
Prepare the repeating video file
Start with a file that has a usable video stream and a usable audio stream. Inspect it with the FFmpeg tools available in your Ubuntu package, or open it in a local media player. Confirm that it plays from beginning to end, has the intended aspect ratio, and does not contain a silent section or damaged ending that will be repeated throughout the broadcast.
A single-file loop repeats that file. It does not create a playlist, insert new announcements, remove a sponsor message, or change the programme when a festival or local event ends. If you need several videos, different frame rates or scheduled changes, prepare and test a playlist workflow separately. The FFmpeg playlist guide for files with different frame rates covers a different problem from looping one compatible file.
For a dependable first test, use a file whose video and audio properties are already close to the output you intend to send. FFmpeg can transcode many inputs, but every extra conversion creates another possible failure: an unsupported codec, a missing stream, unexpected frame timing, or an output that consumes more CPU than the Ubuntu machine can sustain.
Do not judge the file only by its size. A large high-quality source may be unnecessary for a simple static background, while a small file can still contain an unsuitable frame rate or audio layout. Choose the output format for the audience and the available upload capacity, then test the entire route to YouTube.
Copyright and programme rights are separate from encoding. If your loop contains music, prayers, news footage, stock material or customer-supplied clips, check the permissions that apply to the way you plan to use them. For music-heavy channels, it is also worth understanding how YouTube Content ID affects internet radio livestreams.
Build an FFmpeg loop-and-encode command
The basic mechanics are straightforward. -re tells FFmpeg to read the input at approximately its native playback rate rather than sending the file as quickly as the computer can process it. -stream_loop -1 repeats the input indefinitely. The output is sent to YouTube using the ingest URL and stream key supplied by Studio.
Here is an illustrative command:
ffmpeg -re -stream_loop -1 -i video.mp4 \
-c:v libx264 -preset veryfast \
-b:v 4500k -maxrate 4500k -bufsize 9000k -g 60 \
-c:a aac -b:a 128k \
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
This combines the real-time and looping behaviour described in the FFmpeg documentation with an FLV output commonly used for RTMP-family publishing. It is an illustration, not a tested command for every Ubuntu release, input file or FFmpeg build. Confirm that your installed build includes the codecs and options shown before relying on it.
The example assumes a 30-frame-per-second output when -g 60 is used for a two-second keyframe interval. If you select a different frame rate, adjust the GOP value to match the intended interval. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds in its live encoder settings.
-b:v, -maxrate and -bufsize affect the video rate and rate-control behaviour. The example values should not be treated as universal settings. Choose a video bitrate that fits the selected resolution and frame rate, then confirm that the complete output remains within the upload capacity available to the machine.
The -c:v libx264 and -c:a aac choices also need to match the capabilities of the installed build and the requirements of the current YouTube ingest service. YouTube documents H.264 video and AAC or MP3 audio among its supported encoder settings. If FFmpeg reports that a codec or option is unavailable, fix that local compatibility problem rather than repeatedly restarting the same command.
For the URL, set YOUTUBE_RTMPS_URL to the ingest address supplied by YouTube and YOUTUBE_STREAM_KEY to the matching key. Confirm the exact RTMPS URL format expected by the current stream setup. YouTube recommends RTMPS because it encrypts data in transit to its servers; use it when the current Studio configuration and your FFmpeg build support it.
Do not paste the real key into this article's command, a public script or a copied terminal transcript. When testing, watch the terminal output for connection, authentication, input and encoding errors. A command that remains open is not automatically a healthy broadcast.
Set stream parameters and plan bandwidth
Select resolution, frame rate and bitrate together. YouTube publishes recommendations that vary with codec, resolution and frame rate. For H.264, its examples include 5 Mbps at 480p30, 10 Mbps at 1080p30 and 17 Mbps at 1080p60. These are recommendations, not a promise that a particular source will look good or that a particular connection will sustain them.
YouTube also recommends keeping 20% upload headroom. The total includes video, audio and the behaviour of the encoder, so do not treat the video bitrate alone as the whole network requirement. The practical rule is to measure sustained upload under the same conditions in which the stream will operate, leave room for the stream's total bitrate, and account for other people and devices using the connection.
| Decision | What changes | What to check |
|---|---|---|
| Resolution | More pixels can require more video bitrate and encoding work | The source quality, CPU capacity and YouTube recommendation for the chosen format |
| Frame rate | More frames can increase processing and bitrate requirements | Whether the content benefits from it and whether the GOP interval remains appropriate |
| Video bitrate | Higher values can preserve more detail but consume more upload | Sustained upload capacity with YouTube's recommended headroom |
| Audio bitrate | Adds to the total stream bitrate | Whether the audio content needs the selected setting |
| RTMPS or RTMP | RTMPS encrypts the feed in transit to YouTube | The current ingest URL and support in the installed FFmpeg build |
The best FFmpeg bitrate and resolution guidance for a 24/7 YouTube stream can help you compare the choices, but it should not replace a test on your own connection. A shared broadband line may produce a good speed-test result while other traffic is quiet and then fail when backups, video calls or household use begin.
Run an upload test at the location and time where the stream will operate. If the Ubuntu machine is in a shop, temple, office or home, include normal traffic in the test. A connection that barely matches the selected output leaves little room for variation. Lowering the output settings is often more useful than allowing the encoder to run at a rate the link cannot sustain.
Also consider data usage and service terms. A pre-recorded live feed can send data continuously, even when the picture barely changes. If you are deciding between local Ubuntu hosting and a hosted arrangement, compare sustained upload, machine access, operating cost, monitoring and recovery access rather than looking only at the initial setup.
Send the feed and verify it in Studio
Begin with a short controlled test. Start FFmpeg, return to Live Control Room, and check whether YouTube receives the feed and shows a preview. Inspect both picture and sound. A green-looking connection indicator is not enough if the audio is missing, the image is frozen or the source is cropped incorrectly.
Use YouTube's stream health information to look for dropped frames, bitrate warnings, keyframe problems and other ingest messages. Let the test run long enough to expose the normal transition from the start of the file back to its beginning. A file can play once and still fail at the loop boundary.
Do not make the public stream the first place you discover a bad title, wrong aspect ratio, silent audio track or exposed private information. Use the preview and the channel settings to check the presentation before announcing the URL. YouTube recommends testing before an event and monitoring stream health during it.
If Studio does not receive the feed, work through the layers in order. First confirm that FFmpeg can read the file. Then check the URL and key, followed by the RTMPS connection, firewall or network path, codec availability and upload capacity. Avoid changing several settings at once, because that makes it difficult to identify which change fixed or caused the problem.
Remember that YouTube treats live sessions as platform events, not simply as an endlessly growing file. YouTube says streams under 12 hours are automatically archived, so do not assume that a broadcast longer than 12 hours will be preserved as one complete recording. If the archive matters, plan how sessions will be managed and verify the current behaviour in the official documentation.
Supervise the process and plan recovery
A loop option keeps FFmpeg reading the selected file, but it does not repair every failure. The process may exit because the file is unreadable, the key is invalid, the encoder cannot allocate resources, the connection is unavailable or YouTube refuses the ingest. A supervisor can restart an exited process, but it cannot correct the reason for the exit.
For a local Ubuntu machine, decide who will notice a failure and what they can do. At minimum, record the command, the media path, the intended YouTube stream and the last known test result without recording the secret key in plain text. Keep access to the machine available if a restart, key reset or media replacement is needed.
A practical recovery plan has separate responses:
- If FFmpeg exits immediately, inspect the final error lines and test the input file and installed options.
- If YouTube rejects the feed, check the current stream status, URL and key rather than increasing retries.
- If upload capacity falls, reduce the output to a setting the connection can sustain or investigate the network.
- If the source file is damaged, replace it with a known-good copy and run a complete test.
- If the machine stops or loses power, arrange a person or remote-access method that can restore it.
- If a key is exposed, reset it and update the protected value used by the command.
You can use a process manager to restart FFmpeg when it exits, but treat automatic restarts as one part of observation rather than as proof of continuous availability. Repeatedly restarting a bad command can create noisy logs and hide the original error. Add a check that tells you whether YouTube is receiving a healthy feed, not just whether an Ubuntu process exists.
For people who do not want a computer running at the broadcast location, StreamNeo removes the need to keep your own Ubuntu machine and connection active: you upload the file, provide the YouTube stream key, and the cloud-run broadcast can be monitored and restarted when it drops. It is still YouTube-only, and you should continue to check the channel, source rights and YouTube's current requirements.
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 run a YouTube stream indefinitely?
It can repeat an input and keep publishing while the process, machine, network and YouTube session continue to work. That is not a guarantee of uninterrupted viewing or a permanent broadcast. Plan monitoring and recovery instead of treating -stream_loop -1 as an uptime promise.
Should I use RTMP or RTMPS?
YouTube recommends RTMPS because it encrypts the feed in transit to Google's servers. Use the current ingest URL shown in YouTube Studio and confirm that your FFmpeg build supports the required connection format.
What should I do if the stream key appears in a log or screenshot?
Reset the key in YouTube Studio and replace the protected value used by FFmpeg. Do not continue using an exposed key simply because the current stream still works.
Can a process supervisor fix a broken stream?
It can restart FFmpeg after an exit, but it cannot fix an invalid key, damaged input, unsupported codec, exhausted upload or YouTube restriction. Pair automatic restart with logs, a health check and a person who can investigate the underlying cause.