A 24/7 acoustic guitar radio stream needs three things working together: music you have the right to stream, a video-and-audio feed, and a host that can restart the publishing process after a failure. FFmpeg can assemble and send that feed to YouTube Live, but it does not make a computer, network connection or stream immortal.
The practical route is to prepare a lawful playlist and a still or looped visual, configure YouTube Live, then run FFmpeg under a process supervisor and monitor the result in YouTube Studio. This guide gives you a working pipeline shape and explains which settings are YouTube guidance, which are choices, and what to test before leaving the channel unattended.
Clear music and visual rights first
Treat rights as a launch requirement, not a problem to investigate after the stream is public. You need permission that covers the recordings, the music, the intended live use and the places where the stream may be available. A purchase, a subscription to a listening service, or permission to use a track in an ordinary video does not by itself establish that you can rebroadcast it continuously on a live channel.
Original recordings are often the clearest route if you control all relevant rights. For third-party music, read the actual licence and keep a copy with the project files. Check that it covers live streaming, the relevant platform and territories, and the duration you intend to use it. If the track is registered with Content ID, ask whether the rights owner needs to allowlist your channel. YouTube warns that live streams are scanned for third-party content; a match can lead to a warning or placeholder, and an unresolved issue can interrupt or terminate a stream. See YouTube's guidance on live-streaming copyrighted content.
Do not assume that every YouTube music licence covers live radio. YouTube's Creator Music guidance limits its licensed and revenue-sharing tracks to long-form videos, rather than live streams. Check the current terms on the Creator Music help page before choosing a source. The same distinction applies to monetisation: having permission to use a recording does not promise approval for monetisation, because channel-level reused-content policies are a separate consideration.
Your visual needs rights too. A photograph, album cover, animation or background video may have an owner distinct from the music rights holder. Use original artwork, a properly licensed image, or a visual you are explicitly permitted to use in a live broadcast. Save the source and licence details somewhere you can find them if a claim or question arises. YouTube's live-streaming terms describe the creator's responsibility for necessary rights, including music rights; for your situation, check the current official terms rather than relying on a general rule of thumb.
Prepare the playlist and visual layer
FFmpeg can read local media files, concatenate them, and add a separate video source. The first decision is how your acoustic playlist will be represented. You can prepare one long audio file, or keep tracks as separate files and use a concat list. Separate tracks are easier to rearrange, but transitions and pauses need checking. A single pre-rendered programme simplifies playback, but changes require creating that file again.
For a list of compatible local files, make a text file such as playlist.txt:
file '/media/guitar/track-01.wav'
file '/media/guitar/track-02.wav'
file '/media/guitar/track-03.wav'
This is an input list, not a guarantee of a smooth musical transition. Check that paths are correct, that formats can be read by your installed FFmpeg build, and that the joins sound acceptable. If you use FFmpeg's concat demuxer, the files should be compatible in the ways the demuxer expects; converting them to a consistent format first can reduce surprises. Listen through the beginning and end of the combined programme, including the transition where a repeat will occur.
Use a video source that continues to produce frames. A still image can be looped by FFmpeg into a video stream, or you can use a short visual loop. An image with the channel name and a restrained scene suits an acoustic radio format, but the particular design is optional. The required point is not a moving picture for its own sake: YouTube Live ingest here is an audio-video feed, so an audio-only FFmpeg output is not sufficient. Keep the aspect ratio, text placement and image dimensions sensible for the display you choose, and inspect the actual encoded picture in Studio.
You can prepare a playlist video in advance if that is easier to maintain than building the audio and visual together at runtime. The Punjabi playlist preparation guide covers that adjacent workflow. This FFmpeg approach is useful when you want the audio playlist and visual source to remain separate and adjustable.
Before running all night, establish a known-good local test: play the source through its full repeat boundary, look for silence or gaps, and confirm that the visual does not freeze or disappear. A loop that is technically valid but has a noticeable pause can make a radio stream feel broken. Do not rely on a filename, duration display or successful FFmpeg start message as evidence that the listener experience is right.
Create the YouTube Live destination and protect its key
In YouTube Studio, create or select the live stream in the Live Control Room. For the ordinary encoder workflow, use the server address and stream key shown for that destination. The key acts like a publishing credential: anyone who obtains it may be able to send a feed to your channel. Keep it out of public scripts, screenshots, shared logs and chat messages. Store it in a restricted configuration file or inject it through a protected environment setting, and rotate it in Studio if you believe it has been exposed.
YouTube describes the broadcast and the incoming stream as related but distinct concepts. A broadcast is the event viewers watch; a stream configuration is the transmission endpoint and settings. This distinction matters if you are using the YouTube API or managing scheduled events, but for a simple Studio setup, confirm that the selected broadcast is the one you intend to use and that its stream status reflects incoming data. Google's Live Streaming API overview explains the broadcast and stream resources.
Use RTMPS for the normal FFmpeg-to-YouTube path unless you have a concrete reason to use another supported ingest workflow. YouTube recommends RTMPS because it encrypts the connection to Google's ingest servers. The stream key remains sensitive even over an encrypted connection; encryption protects the transmission, not careless key storage.
Build FFmpeg audio-video output
The command below illustrates the full shape: read a still image, read the playlist, loop the playlist, map one video stream and one audio stream, encode them, then publish to YouTube. Replace paths and the ingest URL with the values for your own system. The example uses a Linux-style image loop input and the concat demuxer for audio; input options and loop behaviour can differ with formats and FFmpeg versions, so test against the build installed on your host.
ffmpeg \
-loop 1 -framerate 30 -i /media/guitar/radio-art.jpg \
-stream_loop -1 -f concat -safe 0 -i /media/guitar/playlist.txt \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -pix_fmt yuv420p -r 30 \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-g 60 -keyint_min 60 -sc_threshold 0 \
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
This is a starting point, not a universal command to paste without inspection. It assumes an installed FFmpeg build with the listed components, a compatible local playlist, and an RTMPS URL/key arrangement matching the destination shown in Studio. YouTube's current encoder settings guidance lists H.264 video, AAC or other supported audio options, CBR guidance, and recommended keyframe interval. It specifies a two-second recommended keyframe interval and says not to exceed four seconds. The sample's -g 60 corresponds to two seconds only when the output frame rate is 30 frames per second; if you change the frame rate, adjust the GOP value accordingly.
The sample's audio values reflect YouTube's listed baseline for stereo music: AAC at 128 Kbps and 44.1 kHz. Those are supported encoder choices, not a requirement that every source be resampled in precisely this way. If your source is mono, high-resolution or variable-format, test the resulting audio, and consider preparing consistent inputs before the stream. Do not claim a particular sound quality based only on a bitrate flag; the source recording, encoding and playback device all matter.
Video resolution, frame rate and bitrate are choices within YouTube's current guidance, not qualities of the music itself. A static artwork frame does not need an elaborate visual treatment, but it still has to encode reliably. Choose a modest output matching the image and the sustained upload capacity of the host. YouTube's encoder page provides bitrate ranges by resolution and frame rate; choose within the current range and leave network headroom rather than sizing the output to a peak speed test. If you need to align dimensions, the guide on matching FFmpeg output resolution to YouTube Live ingest explains the practical checks.
The concat input shown does not by itself guarantee infinite playback in every build or for every input arrangement. Confirm that the installed FFmpeg accepts the options and that the audio continues at the end of the list. For predictable operation, create a long programme file, or use a wrapper that starts the next playlist segment after EOF and reports failures. Avoid hiding all diagnostic output: logs are often the only clue that the audio input ended while the video kept running.
Choose the ingest protocol
RTMP and RTMPS are the straightforward options for this encoder pattern. RTMPS adds encryption in transit and is YouTube's recommended choice for a standard encoder connection. The output container in the example is FLV, commonly used for this ingest path. Check the exact server address YouTube provides instead of constructing it from memory, and keep the key separate from the script where practical.
HLS is a different ingest workflow, not a drop-in synonym for the RTMP URL. YouTube's HLS guidance specifies its own requirements, including HTTPS, transport stream segments and a rolling playlist, and notes that segment-based delivery has higher latency. Unless you have an HLS-specific requirement, the standard RTMPS path is simpler for this acoustic radio use. The RTMP and RTSP comparison helps distinguish protocol names that are often confused; RTSP is not the same thing as YouTube's normal encoder ingest choice.
The protocol decision does not remove the need for a stable video-and-audio output. A successful network connection only says that a publisher reached an endpoint. It does not prove that Studio is receiving the right broadcast, that the playlist is audible, or that the image is visible to viewers. Use Studio's preview and health feedback as part of protocol validation.
Keep FFmpeg running and recover deliberately
A 24/7 stream depends on the host staying available. If FFmpeg runs on a home computer, that computer must remain powered, connected and free from sleep or maintenance interruptions. A rented Linux host or another remote machine can separate the stream from your desk, but it introduces its own network, administration and cost considerations. Neither arrangement is inherently unbreakable.
Run FFmpeg as a managed process rather than leaving it attached to a terminal you may close. On Linux, systemd is one common supervisor: it can start a service at boot and restart it if the process exits. The unit should run under an account with access only to the necessary media and configuration, use a protected key source, and write logs that you can inspect. Restarting a failed process is helpful, but a rapid loop of repeated failures can conceal a bad key, missing file or incompatible command. Configure a restart delay and check the logs after a restart.
Input reconnection and output recovery are separate problems. FFmpeg protocol reconnect options can help with some network inputs, but they are specific to the input protocol and do not automatically recreate every failed YouTube output session. A local playlist input may not need network input reconnection at all. For a dropped publishing connection, the supervisor may need to restart the whole FFmpeg process; verify that YouTube accepts the reconnect and that the broadcast is still the intended one. The automatic restart guide for a church live stream describes the broader restart pattern.
A system service might be configured with a restart policy and a start limit, but the exact unit depends on your operating system and security model. Test service behaviour by stopping FFmpeg deliberately, then confirm it restarts and produces fresh video and audio. Also test a missing file and an invalid key in a safe private test: you want clear failure logs rather than endless silent retries. Retain enough log output to see timestamps, process exits and FFmpeg errors, while avoiding logging the stream key itself.
Monitoring is part of the design. Check YouTube Studio's stream health messages, the host's process status, storage availability and network connection. If the service reports active but Studio says no data is being received, inspect the destination URL, key, output format and firewall path rather than merely restarting repeatedly. The no data received troubleshooting guide is useful when the publisher starts but Studio does not show an incoming feed.
If the host runs on a Raspberry Pi, power draw and thermal conditions may shape the choice of output resolution and local setup. They do not change the need for a process supervisor and monitoring. See ways to reduce power use on a Raspberry Pi FFmpeg stream if that is your chosen host.
Test the real stream before relying on it
Run a private or unlisted test using the actual playlist, visual, host, encoder command and intended network path. YouTube's encoder guidance says to test before starting a live stream, and the test should resemble the content viewers will see. A one-minute colour-bar test cannot reveal a quiet music source, an awkward track boundary, or a still image that stops updating after a reconnect.
Check the preview in Studio for visible video and audible audio. Listen on headphones and a separate device if possible: check that the guitar is not clipping, that the stereo image is sensible, and that silence between tracks is intentional. Look for black frames, a wrong aspect ratio, text cut off at the edge, frozen motion in a loop, and gaps at the playlist repeat point. A picture that looks correct in a local player can still be incorrectly mapped or scaled in the outgoing stream.
Test sustained upload, not just a brief speed result. Watch for dropped frames or health warnings while the stream runs, and leave capacity for ordinary variation in the connection. If you change resolution or frame rate, confirm the resulting bitrate and keyframe interval against YouTube's current encoder recommendations. Keep the outgoing settings stable once the test is satisfactory; change one variable at a time if you need to diagnose a problem.
Finally, simulate an interruption. Stop FFmpeg and confirm the supervisor's restart behaviour, then observe whether Studio receives the resumed feed and whether the broadcast remains viewable. If possible, test a short network interruption as well, but do this on a private test rather than a public programme. Recovery should be treated as a process to verify, not an assumption based on a configuration file. After a real reconnect, check quality again: the reconnect resolution troubleshooting guide covers one symptom to look for.
For a channel that is ready to run continuously, you may prefer not to keep a personal computer awake just to host the publisher. StreamNeo takes the specific burden of running the uploaded programme on your own machine out of that workflow: you upload a video, provide the YouTube stream key, and its cloud-based broadcast can be monitored and restarted if it drops. It is YouTube-only, so it is not a replacement if you need to publish to another platform or tune an FFmpeg command yourself.
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 I send only acoustic guitar audio to YouTube Live?
No. In this setup the outgoing live feed needs both audio and video. Pair the playlist with a still image or looped visual and confirm that Studio's preview shows both streams.
Does FFmpeg make the stream truly 24/7?
No. FFmpeg encodes and publishes while it is running, but the host, network, input files and YouTube connection can fail. Use a supervisor, logs and Studio monitoring, and test how the process recovers before depending on it unattended.
Can I use music from Creator Music for a live radio stream?
Do not assume so. YouTube's current Creator Music guidance says those licences are for long-form videos rather than live streams. Check the official terms and obtain rights that explicitly cover the live use you plan.
Should I choose RTMP or RTMPS?
For this standard FFmpeg workflow, RTMPS is the usual choice because YouTube recommends encrypted ingest. Copy the current server address and key from Studio, keep the key private, and test the actual output before announcing the stream.