To run a bhajan stream as a background service on Ubuntu, first make sure the source files are accessible to the machine running FFmpeg and that you have cleared the rights to use them. Then test a working FFmpeg command interactively, connect it to YouTube Live, and let systemd manage the foreground process.
A systemd service can restart FFmpeg after a process failure, but it cannot guarantee a healthy broadcast or detect every stream that has stalled while the process remains alive. This guide follows the path from Google Drive files to YouTube Live Control Room and explains where local Ubuntu and cloud-based streaming differ.
Prepare bhajan files in Google Drive
Start by deciding what the stream will actually play. It might be a single long recording, a set of separate tracks, or a video playlist with still images or other visuals. FFmpeg needs a defined input and a repeat or playlist strategy; it does not infer a continuous programme from a Drive folder.
Organise the material in Drive before moving it to the encoder. Use filenames that make the running order clear, and keep a separate record of the intended sequence. Check that each audio or video file opens and plays through to its end. Look for silent sections, clipped beginnings, unexpected pauses and image changes that do not match the audio. A local review is easier to fix than an issue discovered after the stream has started.
Google Drive is a file storage and sharing service, not a live broadcaster. A file in Drive does not become an FFmpeg input simply because it is in your account. The Ubuntu machine needs an accessible copy or a suitable, authorised way to retrieve the file. A shared link may lead to a web page, an access prompt or a download flow rather than a media stream that FFmpeg can read as intended.
For many non-technical operators, the least fragile first setup is to download the files to a named folder on the Ubuntu machine, then test playback there. Keep the original Drive copy as a source and make edits or conversions on a separate working copy. If you plan to use Drive synchronisation or another transfer method, check that it has completed before starting the service and that the Linux account running FFmpeg can read the resulting files.
If your programme is a sequence of recorded items rather than one continuous file, write down the order and how each item should transition. FFmpeg options differ for looping one file, consuming a playlist, and joining separate inputs. The related guide on setting up a 24/7 aarti stream can help you think through the continuous programme itself; the commands still need to match your own sources and destination.
Make source files accessible to the encoder
The encoder is the Ubuntu machine on which FFmpeg runs. That can be a desktop, a small computer, or a remote Ubuntu host. Wherever it sits, the machine must be able to read the media at the time the service starts and for as long as the stream needs it. Test access as the same Linux user that will run the service, not only from your administrator account.
A practical file layout might put the programme under /srv/bhajan, with a dedicated account named stream given read access. These are example names, not requirements. The point is to avoid relying on a personal desktop folder or a mounted location that disappears when you log out. Confirm the actual path with ls and try opening the file with your chosen player or FFmpeg before creating the unit.
If you use a network-mounted folder or a synchronised Drive folder, startup order matters. A service may start before the mount or synchronisation is ready. systemd can express dependencies and ordering, but those settings must match the mount arrangement you actually use. network-online.target can be useful for a network-dependent service; it does not prove that a particular remote file has finished downloading or that a share is healthy.
Check available disk space as well. A download that was interrupted can leave an incomplete file at the expected path. An encoder may then fail immediately, or it may read a file that is shorter than expected. Keep a known-good source copy until you have checked the transferred version from beginning to end.
Avoid making the unit depend on a command copied from a browser’s Drive share link unless you have tested that exact retrieval flow unattended. Browser authentication may be interactive, links can change, and access permissions may differ between your own account and the service account. A downloaded local file is often easier to reason about. For more context on unattended recorded streams, see the Windows mini PC playlist guide; the operating system differs, but the need to test the media source and restart behaviour remains.
Clear music and visual rights before launch
Make rights clearance a launch prerequisite, not a recovery task after a copyright match or complaint. A bhajan’s devotional subject does not by itself establish that the recording, arrangement, performance, lyrics, photograph, artwork or video is free for use in a public YouTube broadcast. A traditional composition may have a different rights position from a modern recording of it.
For every component, establish who created or controls it and what permission applies to your intended use. That includes continuous live streaming, use of a recording in a loop, visual material, and any monetisation plans. If a performer or label has granted permission, retain the written terms and make sure they cover this format and platform. If the material comes from a library or a contributor, read the licence rather than relying on a description such as “free”, “devotional” or “royalty-free”.
Keep a simple record: the asset name, source, rights holder or licence, permission evidence, and any limits such as attribution or territory. This is an operational record, not a guarantee that YouTube will accept every asset or that no claim will arise. Rights disputes and automated matches can interrupt a stream even when you believe you have permission. YouTube’s official copyright guidance explains its general copyright process; check the current official information and get qualified advice where the rights position is unclear.
The same care applies to visual assets. A still image, temple photograph, album cover or lyric display may have separate rights from the audio. If you create your own visuals, confirm that they do not include unlicensed third-party work. Do not use another channel’s stream, video or artwork as source material without permission.
If an existing stream has received repeated copyright matches, resolve that before building another unattended loop. The practical checks in how to stop repeated copyright matches interrupting a stream are relevant to troubleshooting, but no article or configuration can substitute for checking the rights to your own content.
Choose local or cloud streaming
With local streaming, FFmpeg runs on your Ubuntu machine. The machine reads the files, encodes or passes through the media, and sends an output to YouTube. A systemd service can start FFmpeg at boot and restart it after certain failures. Your computer, its power, its network connection, and its storage remain part of the stream path. If the machine sleeps, loses connectivity or runs out of resources, systemd alone cannot make those conditions disappear.
A remote Ubuntu host is still a local FFmpeg setup in the software sense: you administer an Ubuntu environment and run the service there, but the machine is elsewhere. It can be useful when you do not want a home computer running continuously. It also adds decisions about access, data transfer, bandwidth, cost and how you will monitor the host. No host should be chosen on a promise of uninterrupted broadcasting; assess its published limits and your own recovery plan.
A managed cloud workflow can remove the need to keep your own computer switched on and maintain an Ubuntu service. For a pre-recorded bhajan programme, StreamNeo removes the specific burden of keeping a personal machine and FFmpeg process running by turning an uploaded video into a YouTube live stream. It is YouTube-only; you still need to prepare the file, supply your YouTube stream key and clear the rights to the material.
| Consideration | Ubuntu with FFmpeg | Managed cloud workflow |
|---|---|---|
| Who prepares the source | You download and organise the media on the machine | You prepare and upload the programme file |
| Process control | You configure FFmpeg and systemd | The provider manages the broadcast workflow |
| Computer at your location | Must remain available if FFmpeg runs there | Your computer can be switched off after setup |
| Troubleshooting | You inspect service state, logs, files and network | You use the provider’s available controls and support |
| Protocol and settings | You choose compatible input, codecs and destination | The workflow determines the available settings |
Choose local FFmpeg when you need direct control over inputs and encoding, or when the programme involves a live source that a file-based service cannot handle. Choose a managed workflow when your source is a prepared video and the main operational problem is leaving a computer running. Neither choice clears music rights or guarantees that YouTube will keep accepting a particular stream. For broader operational considerations, see church live-streaming best practices.
Connect the encoder to YouTube Live
In YouTube Live Control Room, create or schedule a live stream and review the current stream settings and connection instructions shown for that broadcast. YouTube’s official encoder setup instructions explain how to connect an encoder. Follow the current instructions there rather than assuming that an older screenshot, preset or third-party tutorial still matches your account.
The connection information includes a stream key. Treat it as a credential: someone who obtains it may be able to send a signal to your broadcast destination. Do not paste it into a public post, share it in a screenshot, or include it in a file that other users can read. Use the key and destination information supplied for the stream you are configuring.
Before writing a systemd unit, make the FFmpeg command work in a terminal under the intended Ubuntu account. Check the installed build with ffmpeg -version. The online FFmpeg documentation is regenerated as the project changes, so the options available in an older Ubuntu package may differ; consult ffmpeg -h or the relevant local help when an option is rejected. The FFmpeg command-line documentation describes input, output, stream selection and the distinction between copying and transcoding.
There is no single correct full command for this article because the source type, codecs, output protocol and destination details are not specified. A local file, an HTTP input, a capture device and a network feed need different input handling. The destination’s accepted protocol and media requirements also matter. If your source is already encoded compatibly, stream copy may avoid re-encoding; if it is not, transcoding requires an available encoder and enough CPU capacity. Check the format and codec expectations in YouTube’s current encoder guidance before settling on settings.
For illustration only, a local-file command might use -re to read at a real-time pace, -stream_loop -1 to repeat a file, and an output format and destination supported by the receiver. Do not paste a placeholder URL or stream key into a live command. Confirm the file looping behaviour and available codecs on your build, and test the exact command before relying on it.
Once the interactive command connects, create a unit that runs FFmpeg in the foreground. A minimal shape is:
[Unit]
Description=FFmpeg bhajan stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
WorkingDirectory=/srv/bhajan
ExecStart=/usr/bin/ffmpeg [your tested options and inputs] [your tested output]
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
The bracketed text is explanatory and is not a working command. Replace it with the command you tested, with correct paths and protected credentials. Do not append & to ExecStart= or rely on shell pipes and redirection there; systemd does not interpret that field as a shell command. Ubuntu’s systemd.service manual documents service command and restart behaviour for the Jammy manual. Other Ubuntu releases may have different versions and details, so check the manual installed on your machine.
After saving the unit, reload systemd’s configuration and enable the service to start at boot. For example, sudo systemctl daemon-reload followed by sudo systemctl enable --now bhajan-stream.service asks systemd to load and start that named unit. Adapt the name, paths, user and permissions to your setup. The example restart delay is illustrative, not a universal value; choose a measured delay that avoids rapid repeated attempts while still allowing a reasonable recovery.
Test playback and stream output
A successful process start is not proof that the audience receives a usable stream. First check FFmpeg’s terminal output for input errors, missing codecs, rejected options and connection failures. Then check YouTube Live Control Room for an incoming signal and preview the picture and sound before going live. If you schedule the broadcast, verify which action actually starts the public event; an encoder connection and a live broadcast are not necessarily the same operational step.
Listen to the output on a separate device if possible. A desktop can play its local source correctly while the outgoing stream has silence, clipping, poor level balance or an unexpected repeat point. Check that the visual output is present and appropriate for the full programme, including any transitions. Watch a representative portion of the stream rather than relying on a single preview frame.
Run the service under systemd and inspect it with systemctl status bhajan-stream.service. Follow its logs with journalctl -u bhajan-stream.service -f. These commands help you see whether the process is active and what it reports; they do not independently confirm that YouTube is receiving healthy media. Confirm the receiving side in Control Room as well.
Test recovery deliberately before leaving the stream unattended. Stop the service, start it again and confirm that FFmpeg reconnects and the destination resumes receiving media. Separately test what happens after a process exits unexpectedly. Restart=on-failure asks systemd to restart a failed process, but repeated failures can encounter systemd start-rate limits. If the unit stops trying, inspect its state and logs rather than assuming the restart policy has fixed the cause.
A service manager reacts to process exit or certain timeouts. It does not inherently know that an FFmpeg process is alive but sending no useful media. Protocol-specific recovery is a separate layer: FFmpeg documents HTTP reconnection options for HTTP input handling, while its FIFO muxer documentation includes an RTMP output recovery example. Those are not interchangeable settings. Select recovery options for the actual protocol and the side of the connection that is failing, using the FFmpeg protocol documentation and FFmpeg component documentation.
Keep a short runbook beside the machine: how to check the unit, where its logs appear, how to stop it safely, and what to check in Control Room. Record the working FFmpeg version and command without recording an exposed stream key. A controlled recovery test is more useful than assuming an unattended service will recover from every possible outage.
Keep the stream key secure
Do not put the stream key in a world-readable unit file, shell history, shared notes or public troubleshooting post. A restricted unit file may be sufficient for a simple installation, but its access permissions and the users who can read it still matter. Consider storing sensitive values in a protected environment file or another mechanism appropriate to your system, with ownership and permissions limited to the service account and administrators who need access.
Be careful with logs. FFmpeg’s command line can appear in process listings or diagnostic output, depending on how credentials are supplied. Do not make logs broadly readable by default, and review them before sharing a support excerpt. Redact keys, private URLs and account details. Use a dedicated Linux account for the stream so that a configuration mistake does not expose unrelated personal files.
If you think the key has been exposed, use YouTube Live Control Room to replace or reset it as supported by the current interface, then update the service and test the new connection. Do not assume that changing a local file alone invalidates a previously exposed key. The current YouTube encoder help is the place to confirm the available stream controls.
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 Google Drive send the bhajan stream directly to YouTube?
No. Drive stores and shares files; it does not broadcast them as a live channel. The encoder must receive media in a form it can read, usually by downloading a prepared file to the Ubuntu machine or by using a separately tested retrieval method.
Does systemd keep FFmpeg running if the internet connection drops?
Systemd can restart FFmpeg after a process failure under a policy such as Restart=on-failure, but it does not repair every network condition or detect every stalled output. FFmpeg’s reconnection options depend on the protocol and whether the failure is on input or output, so test the failure mode you expect.
Can I copy a command from this guide into my unit file?
No complete command is provided because the source format, codecs and destination details determine the correct options. First test a command interactively with your own files and YouTube connection, then place that tested command in ExecStart= and run FFmpeg in the foreground.
Do I need to leave my Ubuntu computer on?
If FFmpeg runs on that computer, it must remain powered and connected for the service to continue. A remote Ubuntu host or managed cloud workflow can avoid keeping your own computer on, but each has different control, access and recovery trade-offs.