To run a prepared Gurbani stream on YouTube around the clock from Ubuntu, install the FFmpeg package for your actual release, test a publishing command with your media, then run it under a supervisor and monitor both the process and YouTube’s stream health. A restart policy can relaunch a failed FFmpeg process; it cannot guarantee uninterrupted publishing or fix every cause of a drop.
This guide builds that workflow in stages instead of relying on a single command copied without context. Test each step with a short session before leaving it unattended, and keep the stream key private throughout.
Check your Ubuntu release and install FFmpeg
Ubuntu’s repositories package FFmpeg, but the version depends on the Ubuntu release and the repository state of the machine. First identify the release and codename:
lsb_release -a
You can also inspect /etc/os-release. Check that the repositories configured for that release are enabled and available, then refresh package metadata and install the package:
sudo apt update
sudo apt install ffmpeg
Do not use a version number found for another Ubuntu release as an installation instruction. For example, Ubuntu Packages lists FFmpeg 7:6.1.1-3ubuntu5 for Ubuntu 24.04 LTS (noble) in universe; that listing is specific to noble and can change as updates are published. Check the package information for your own release before drawing conclusions. See Ubuntu Packages’ FFmpeg entry for noble.
Confirm what is installed:
ffmpeg -version
This identifies the installed build, but it does not prove that every encoder, filter or protocol you need is available. Check the local help and available components when a command option fails:
ffmpeg -h full
ffmpeg -encoders
ffmpeg -protocols
The output may be long. Search it for the encoder and protocol your planned command uses. If you expect hardware encoding, verify both that the machine has a suitable device and that this FFmpeg build exposes the required encoder; do not assume that the option is present just because a guide shows it. Software encoding is often a simpler baseline to test, though its CPU use depends on the input and output settings.
Prepare and inspect the media inputs
Decide exactly what FFmpeg will read. The simplest arrangement is one local video file containing both the moving picture and its audio. Another common arrangement is a video file plus a separate audio file. A folder of clips or a playlist introduces additional questions about ordering, transitions and matching audio; solve those locally before trying to publish.
Check that each file plays on the Ubuntu machine and that the intended audio is present. Inspect media streams with ffprobe, which is installed with many FFmpeg packages:
ffprobe -hide_banner -i gurbani-video.mp4
The output helps identify the video and audio streams, dimensions, frame rate, codecs and duration. Treat it as a diagnostic rather than a guarantee that YouTube will accept the result. Play the file from beginning to end, or at least inspect representative points, to catch silent sections, damaged media, an unexpected aspect ratio or an audio track that does not match the picture.
Use recordings and visual assets you have permission to broadcast. A devotional text or composition does not by itself establish permission for a particular recorded performance, arrangement, accompaniment or video. Keep records of permissions where relevant and check any applicable terms for your material.
If you are choosing between a single combined file and separately managed audio and video, consider how you will test and maintain the result. With a combined file, you have one input to validate, but you need to listen for an audio gap when the file loops. Separate inputs can give you more control over the picture and continuous audio, but their timing and their individual failure modes need testing. For a broader look at keeping music continuous across a visual loop, see how to keep background music playing across a YouTube video loop.
Create a YouTube Live stream key
In YouTube Live Control Room, create or select the broadcast and obtain the current ingest address and stream key from its stream settings. The labels and screens can change, so use the current instructions in YouTube Help on encrypting a stream with RTMPS. YouTube describes RTMPS as its secure streaming option; Google’s developer documentation on delivering live content via RTMPS explains it as RTMP carried through an SSL connection.
Prefer the RTMPS ingest address shown for your broadcast where it is available. Do not publish the key in a public script, a repository, a screenshot or a support post. Anyone who obtains it may be able to send a stream to your channel. If a key is exposed, replace or revoke it through the current Live Control Room controls rather than assuming that deleting a local file has made it secret again.
For an initial test, use placeholders in notes and replace them only in a protected local configuration. Avoid pasting a real key into a shell command that may be retained in shell history. A systemd service can read a separate environment file with restricted permissions, or you can use another access-controlled method suitable for your machine. Treat that file as a credential: limit who can read it, keep it out of version control and make a plan for updating the service if the key changes.
Before depending on the channel, confirm the account can start a live stream and that the selected broadcast is ready in Live Control Room. This guide does not establish account eligibility, waiting periods or duration limits; check YouTube’s current Live Help and the channel interface for those details.
Build and test the FFmpeg command
Start with a command that reflects your actual input, then add only the settings you need. The sketch below assumes one local file with both video and audio, an H.264 output, and a reachable RTMPS URL. It is a template, not a tested universal command: confirm input options, encoder availability and protocol support against your installed build and files.
ffmpeg -re -stream_loop -1 -i /path/to/gurbani-video.mp4 \
-c:v libx264 -preset veryfast -b:v 6M -maxrate 6M -bufsize 12M \
-r 30 -g 60 -pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://INGEST-URL/STREAM-KEY"
Replace the input and destination placeholders. The values shown describe a possible 720p30 H.264 profile, not a command tested on your machine and not a recommendation for every source or network. A source with different dimensions or a different frame rate needs deliberate handling; encoding a low-quality source at a higher output resolution will not restore detail. If your installed build does not include libx264, choose a supported encoder only after checking its options and testing its output.
YouTube’s current encoder settings guidance lists H.264, H.265/HEVC and AV1 video options, up to 60 fps, constant bitrate, a recommended two-second keyframe interval with a four-second maximum, and AAC or MP3 audio. For the H.264 profiles listed there, the bitrate comparison is:
| Output profile | YouTube-listed minimum video bitrate | YouTube-listed recommended video bitrate |
|---|---|---|
| 720p30 H.264 | 3 Mbps | 6 Mbps |
| 1080p30 H.264 | 5 Mbps | 10 Mbps |
These are YouTube’s published encoder-setting values, not a promise that your connection can sustain them. Select a profile appropriate to the source, the computer’s encoding capacity and the available upload line. Leave room for network variation rather than targeting the whole measured upload capacity. Test at the intended time and from the same connection you plan to use. A home line can behave differently overnight or when other devices are active.
In the sketch, -re reads a file at its native playback pace, -stream_loop -1 requests indefinite input looping, -i names the input, and the output options select codecs and a destination. The GOP value of 60 corresponds to a two-second interval at 30 frames per second. These options interact with source properties and build support; check the installed FFmpeg protocol documentation and local help rather than assuming every option is accepted by every build. If YouTube’s preview or health panel reports a problem, change one variable at a time and retest.
Run the command interactively for a short private or scheduled test. Confirm that FFmpeg reports frames being processed without repeated errors, that YouTube receives the feed, and that both the sound and movement look right in the preview. The frame-rate considerations for YouTube Live are also worth checking if your source has a variable frame rate or inconsistent timing.
Loop audio and video appropriately
The loop strategy depends on the inputs. For one file containing both tracks, input looping can repeat the file as a unit. This is simple, but the end-to-start boundary may produce a pause, click, abrupt image change or silence. Listen and watch across that exact boundary, not just in the middle of a sample playback.
For separate audio and video, they must each be managed and mapped deliberately. Do not add a second -i simply because a command found online uses one: verify each input, its duration and the intended output mapping. If the visual is a still image and the audio is a longer programme, the video needs a suitable looping or repeating method while the audio remains continuous. If you are using a playlist of clips, first make a local playlist that represents the intended sequence and test its transitions before introducing YouTube ingest.
Looping is also not the same as a seamless presentation. A repeated recording may have a natural pause, but an abrupt cut can be distracting in prayer, recitation or music. Decide whether the stream should include a short transition, whether the audio can be joined without a click, and how long the visual can repeat before it appears frozen. Keep a known-good local sample for regression checks whenever you edit the playlist or replace a recording.
There is no universal loop command for every media arrangement. FFmpeg’s input and filter options differ in behaviour and in where they apply; a filter that repeats video does not necessarily loop audio, and an input loop can repeat all streams together. A conservative approach is to validate the source in isolation, inspect the stream mapping, then test the output boundary at YouTube. For other ways to repeat a playlist, compare the workflow with streaming a YouTube playlist continuously with VLC; that is a different tool and should not be treated as a drop-in FFmpeg recipe.
Run FFmpeg unattended on Ubuntu
Once the command works interactively, put it under a process supervisor rather than leaving a terminal session open. On an Ubuntu machine using systemd, a service unit can start FFmpeg at boot and keep its output in the system journal. This handles process lifecycle more deliberately than a shell opened by hand, but it does not make the machine, network or YouTube ingest infallible.
A basic unit can be placed at /etc/systemd/system/gurbani-stream.service. Adjust the account, paths and command for your installation. Keep secrets outside the unit file, and do not paste a real stream key into an example or public configuration:
[Unit]
Description=Gurbani YouTube stream
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=streamuser
EnvironmentFile=/etc/gurbani-stream.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/media/gurbani-video.mp4 -c:v libx264 -preset veryfast -b:v 6M -maxrate 6M -bufsize 12M -r 30 -g 60 -pix_fmt yuv420p -c:a aac -b:a 128k -ar 44100 -f flv ${INGEST_URL}
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This unit is an implementation pattern to adapt and test, not a guarantee that systemd will expand every value exactly as intended for your setup or that FFmpeg can publish with it. In practice, check how your service passes the destination and credentials, and validate that it starts under the specified service account. Use a protected environment or credential mechanism compatible with your systemd version; do not put the key in a world-readable file. Restrict an environment file, for example, with root ownership and permissions that allow only the intended service access, and verify those permissions before enabling the service.
After saving a unit, reload systemd’s configuration and test it deliberately:
sudo systemctl daemon-reload
sudo systemctl start gurbani-stream.service
sudo systemctl status gurbani-stream.service
Enable startup on boot only after the test succeeds:
sudo systemctl enable gurbani-stream.service
A local Ubuntu machine gives you direct control over the media and hardware, but must remain powered, connected and maintained. A hosted machine shifts some physical upkeep elsewhere while adding provider, access and network considerations. The right choice depends on who can monitor it and what failure modes you can respond to. See the VPS versus cloud streaming trade-offs for an always-on YouTube channel before choosing where to operate the process.
Log failures and plan restart recovery
Use the service manager’s status and journal to find out what actually happened. For a recent service log:
sudo journalctl -u gurbani-stream.service -n 100 --no-pager
To follow new messages while testing:
sudo journalctl -u gurbani-stream.service -f
Look for the first meaningful error, not just the last line. An invalid path, unreadable file, missing encoder, unsupported protocol, expired key, rejected stream or network failure each calls for a different response. If FFmpeg exits, systemd can restart it according to the configured policy. If FFmpeg remains running but cannot publish useful data, a simple process supervisor may not recognise the problem as a failure. You still need to inspect YouTube’s preview and stream-health messages, and decide what should trigger a human check.
A restart can restore a process after a crash, but it cannot fix a damaged input, a revoked key, an outage on the network path, an overloaded machine or an interruption on YouTube’s side. It also may not reconnect in the way you expect; test what happens when you stop the process, briefly disconnect the network, and then restore it. Check whether the service retries, whether YouTube accepts the returning feed, and whether the broadcast remains in the expected state. Do this during a controlled test, not during a stream you cannot afford to interrupt.
A sensible pre-launch checklist covers the local file and its loop boundary, the installed FFmpeg encoders and protocol, upload capacity at the intended bitrate, preview and health status in Live Control Room, restart behaviour, audio continuity and synchronisation, journal access, and secret handling. YouTube advises testing with representative audio and movement and monitoring stream health and messages; keep doing that after launch, especially after changing files, keys, settings or the host. If looking after a machine and logs through the night is the part you cannot sustain, StreamNeo removes that specific burden by running an uploaded file as a YouTube live stream without keeping your own computer on; it remains important to prepare the content and verify the channel’s feed.
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 stream 24/7 on YouTube with FFmpeg?
Install the FFmpeg package for your Ubuntu release, prepare and test the media, then publish to the current ingest address and key from YouTube Live Control Room. To operate unattended, use a supervisor, inspect its logs and monitor YouTube’s stream health; no single command guarantees continuous availability.
How do I loop audio and video with FFmpeg?
If both tracks are in one file, an input-looping approach can repeat them together, subject to a boundary test. Separate audio and video require deliberate input, mapping and loop choices, so verify each stream and listen and watch across transitions before publishing.
How do I run FFmpeg in the background on Ubuntu?
A systemd service is one way to start the process at boot and collect its output in the journal. Test it under the service account and protect the stream key; do not assume a command that worked in your terminal will work unchanged as a service.
Will systemd reconnect my YouTube stream if it drops?
Systemd can restart FFmpeg when the process exits, if the service policy is configured to do so. It cannot resolve every network, input, credential or YouTube-side problem, and a running process may not mean the broadcast is healthy, so test recovery and monitor the Live Control Room.