A Raspberry Pi can run FFmpeg to send a music playlist to YouTube Live, provided the media, encoding settings, and upload connection suit the particular Pi. The basic path is to prepare compatible files, make an ordered concat list, pair the audio with a visual, and send the encoded feed to YouTube over RTMPS.
This is a practical outline, not an end-to-end tested Pi recipe. FFmpeg warns that concatenated inputs need matching streams and that inaccurate durations can cause gaps or artifacts; a continuous process also does not guarantee uninterrupted playback. Test with your own files and hardware before treating the channel as unattended.
Prepare compatible playlist media
Start with a folder of local audio files and decide what viewers will see while they listen. FFmpeg’s concat demuxer can read a text script and process files in sequence. It is not a playlist manager that repairs inconsistent media: the input streams need to match, including such properties as codecs and time bases. If one track differs, normalise it to a common format or test the sequence closely rather than assuming FFmpeg will make the boundary invisible.
Keep the source files on storage accessible to the Pi. A microSD card may hold the operating system and media, while a USB SSD is another storage option; neither is automatically the right choice for every installation. Keep a separate copy of original audio and the manifest so a damaged card or an accidental edit does not force you to rebuild the playlist.
Use clear filenames and avoid moving media after you have created the concat list. For example, a folder might contain track-001.mp3, track-002.mp3, and track-003.mp3. Check that every file opens and plays locally, and listen across at least one file boundary. Uneven loudness, silence at a track’s beginning or end, and abrupt edits are audible even if the stream connection is healthy.
If your channel has a visual identity, prepare a still image or a simple visual loop that you have the right to use. FFmpeg must produce a video stream as well as the audio stream if you intend to send video to YouTube Live. A still image can be made into a moving-timebase video feed, but that encoding work consumes Pi resources. A static visual is not a reason to skip testing the selected resolution and encoder on the actual device.
Music rights are separate from the technical setup. Having an audio file on your Pi does not establish permission to broadcast it, and neither YouTube settings nor this workflow determines whether a particular use is allowed. Check the rights and YouTube’s current requirements for the material and channel before scheduling a public stream. For a channel built around devotional repertoire, the practical considerations in planning a 24/7 Marathi bhakti geet stream may help you think through the content and format, but do not treat another channel’s approach as permission for your music.
Build and check the concat file list
The concat demuxer uses a plain-text manifest. Put one file entry per line in the intended playback order, using paths the FFmpeg process can resolve from its working directory. The syntax is particular to FFmpeg’s concat format; consult the FFmpeg formats documentation rather than treating the file as an arbitrary list of shell commands. Paths containing apostrophes or unusual characters need careful escaping, so simple filenames and a fixed media directory reduce avoidable errors.
An illustrative manifest might look like this:
ffconcat version 1.0
file 'track-001.mp3'
file 'track-002.mp3'
file 'track-003.mp3'
The header and entries are examples of the concat-demuxer format, not a complete broadcast command. Save the manifest alongside the media or use explicit paths, then make a small test input before setting up a long-running process. Verify that FFmpeg can open each path in order and that the resulting audio continues past the first transition. If the manifest cannot be parsed or a filename is misspelt, fix that before introducing YouTube ingest as another variable.
There are two distinct meanings of “24/7” to think about. One is a source sequence that repeats indefinitely; the other is a YouTube live event that remains active and viewable. The documentation consulted for this article confirms sequential concatenation, but does not establish a complete looping command or a restart mechanism for every Pi build. If you use an FFmpeg loop option or wrap the process in a service manager, check the current command-line documentation and your installed build, then test the behaviour deliberately. Do not assume a process restart resumes at the right song or that a live event automatically recovers in the way you intend.
Before the first public test, play the prepared output locally for long enough to hear several boundaries. Check that the first and last entries behave as expected when the sequence repeats, if you have configured a repeat. Note where silence occurs. This local check will not reproduce upload loss or YouTube ingest, but it separates media and manifest faults from network and broadcast faults.
Understand stream matching and duration pitfalls
The concat demuxer adjusts timestamps as it moves from one file to the next. That makes sequential input possible, but it depends on compatible streams and usable duration information. FFmpeg specifically warns that the streams in the files should match and that inaccurate durations can create artifacts. A file whose reported duration differs from its actual playback length can shift later timestamps and leave a gap or an awkward transition.
Inspect the media rather than relying only on extensions. Two files ending in .mp3 can still differ in properties relevant to a workflow, and a playlist mixing audio-only files with files that contain video adds more things to reconcile. If you need a predictable output, first convert or remux the playlist into a consistent set of inputs using FFmpeg options you understand. Keep the originals and test the converted sequence. Conversion can consume time and storage, and careless settings can alter quality; it is not a guarantee of perfect transitions.
Duration problems are especially easy to miss in a short test. A list may play once without an obvious fault while a later boundary produces a brief pause, overlap, or timestamp discontinuity. Compare the local output around transitions and inspect FFmpeg’s messages for warnings. If the output behaves differently from what you expect, stop and investigate the media and duration metadata before trying to compensate with arbitrary timing values.
A useful preflight record is simple: note each filename, its order, whether FFmpeg opens it, and whether a listener hears an unwanted pause or jump at its boundary. If you change an audio file, revise the manifest and repeat the affected transition check. This is more useful than labelling a playlist “compatible” once and forgetting what was tested. A Pi that runs cleanly with one set of files says nothing conclusive about a different set.
Prepare YouTube Live ingest
In YouTube Live Control Room, create or schedule the event and obtain its ingest details. The live event is the viewer-facing broadcast; the encoder sends media to an ingest stream. Google’s Live API documentation on broadcasts and streams describes these as related but distinct objects. For a basic setup, use the event controls provided by YouTube rather than trying to construct API workflows you do not need.
YouTube recommends RTMPS for ordinary live content. RTMPS carries RTMP over SSL; its official ingestion guide explains the endpoint, port, and URL form. Copy the exact server address and stream key shown for your event. A malformed path or wrong protocol can prevent connection even if FFmpeg is otherwise encoding correctly.
Treat the stream key as a password. Do not paste it into a public post, source repository, screenshot, or support request. A command line can be retained in shell history or visible to other local users, depending on how you run it. Restrict access to any script that contains the key, avoid sharing raw logs without reviewing them, and rotate the key in YouTube if you believe it has been exposed.
For a single always-on channel, begin with one event and one ingest path. A separate backup ingest or more involved arrangement may solve a particular operational problem, but it adds configuration and bandwidth demands. Keep the initial path understandable: the goal is to verify that the Pi can send a stable, correctly encoded feed and that the YouTube event receives it.
Configure the Pi and FFmpeg workflow
Install an FFmpeg build appropriate for the Pi operating system and confirm which encoders it actually provides. Availability can differ by model, distribution, and build options. Raspberry Pi 5 software encoding and hardware-assisted paths on other Pi generations should not be treated as interchangeable without checking the installed build. A music stream with a static visual still requires video encoding if sent as video; measure the actual workload rather than inferring capability from the board name.
Choose a modest output profile that fits the use case, then validate it. YouTube’s encoder settings page lists RTMP/RTMPS, H.264, constant bitrate encoding, AAC or MP3 audio, and a recommended keyframe interval of two seconds, not exceeding four seconds. It gives 44.1 kHz and 128 kbps as stereo audio guidance. For H.264 examples, the page recommends 3 Mbps for 720p at 30 fps and 5 Mbps for 1080p at 30 fps. These are YouTube’s published settings, not a promise that every Pi will sustain a selected mode.
For a music channel with a still background, higher resolution is not automatically useful. Choose based on the visual, the Pi’s sustained encoding performance, and available upload capacity. YouTube advises testing the connection and recommends leaving 20% upload headroom. Remember that the stream’s bitrate is ongoing traffic, not a one-off upload. If household use competes for the same connection, test during the hours when that competition is likely.
Conceptually, the FFmpeg process reads the concat manifest, encodes or maps its audio to an accepted audio codec, creates a video stream from the chosen image or visual source, and writes the result to the YouTube RTMPS URL. The exact command depends on the installed FFmpeg version, available encoders, input formats, and whether the playlist should repeat. Do not paste an unverified command from another Pi into a 24/7 setup and assume its option ordering or encoder names apply to yours.
Build the command in stages. First confirm that the concat input decodes locally. Next add the intended audio encoding and visual input, and write a short local output file to inspect. Then send a private or unlisted test to the YouTube event and check the preview. Keep the stream key in a protected configuration location rather than embedding it in a script that others can read. When you use command examples from FFmpeg’s current documentation, check each option against the installed version and run its help output for the relevant demuxer and encoder.
Do not confuse a process that remains running with a stream that viewers can receive. FFmpeg may exit, the network may fail, the Pi may overheat or lose power, or YouTube may no longer be receiving valid media. A restart strategy can relaunch a process after an exit, but it cannot by itself diagnose the failure, guarantee that the broadcast stays active, or ensure a seamless reconnect.
Test the feed and inspect YouTube stream health
Use YouTube’s test and preview workflow before promoting the channel. Start the encoder, wait for the Live Control Room to show an incoming feed, and listen and watch the preview. Check audio presence, channel balance, loudness, visual framing, and whether the expected resolution and frame rate are being received. A local file test answers whether your media sequence decodes; the YouTube preview answers whether the complete path reaches ingest. You need both checks.
Watch the stream-health messages while the test runs. YouTube recommends monitoring audio and video quality and checking the health feedback; treat warnings as diagnostic information rather than something to dismiss because the picture happens to look acceptable. If the feed stalls or breaks up, check the Pi’s load, FFmpeg output, connection stability, and configured bitrate. Change one factor at a time so you can tell whether the cause was encoding load, network capacity, or media input.
Listen through multiple track boundaries and, if configured, through a playlist repeat. Check for silence, clicks, abrupt changes in loudness, or a freeze in the visual. Then test a controlled interruption if you have a safe way to do so, and observe what the encoder and event do when the connection returns. A reconnect can behave differently from the first connection. Do not assume that a successful initial preview demonstrates recovery behaviour.
For music, a short test can reveal wrong routing or a broken manifest but cannot prove that a long run will stay healthy. Run a longer supervised trial on the intended Pi, power supply, storage, network, and location. Record the settings and any warnings. If you change the encoder, resolution, playlist, or network path, repeat the relevant checks. A related guide to backup streams for a YouTube live channel can help you consider resilience, but a backup configuration also needs its own testing and does not remove the need to monitor the primary feed.
Plan monitoring for continuous playback
An unattended channel needs an operating plan, not just a long FFmpeg command. Decide who will notice a failed process, a missing audio feed, or a YouTube health warning, and how they will access the Pi and Live Control Room. Check that the Pi has reliable power and ventilation in its actual location, that media storage is mounted at boot, and that the home router or upstream connection is not likely to be casually switched off. These are practical checks, not guarantees.
You can use a process supervisor or a scheduled check to restart FFmpeg after an unexpected exit, but design that behaviour deliberately. Avoid rapid restart loops that obscure a persistent error or expose the stream key in logs. Keep logs useful enough to diagnose a failed file or connection, but review them before sharing. Decide how you will distinguish a genuine recovery from a process that is running while YouTube receives no valid feed.
Check YouTube’s stream health and the channel’s public playback periodically. A viewer’s report that the stream is silent may arrive later than an ingest warning; conversely, the encoder can be healthy while a scheduled broadcast is not in the expected state. Keep a simple checklist for the person on duty: confirm the event is live, inspect the health indicator, listen to the output, and check that the playlist has not stopped at its final file.
If maintaining a Pi at home is the specific burden you want to avoid, StreamNeo addresses that particular need by letting you upload a video once and run it as a YouTube live stream without keeping your computer on. It is YouTube-only, so it is not a replacement if your goal is to experiment with a local FFmpeg workflow or to stream an arbitrary live input from the Pi.
For a Raspberry Pi approach, consider how you will recover after a power cut or internet outage, and whether a person can check the channel when an alert arrives. A setup that is easy to understand and restart may be more useful than one with many moving parts. For other playlist planning considerations, see assigning a different daily playlist to each YouTube livestream; the relevant point here is to keep the source order and the expected event behaviour documented.
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 a Raspberry Pi play a playlist to YouTube all day?
It can be configured to run an FFmpeg-based feed, but the result depends on the Pi model, FFmpeg build, media, cooling, power, storage, and upload connection. No particular configuration guarantees uninterrupted playback. Test the exact combination you plan to leave running and arrange a way to notice faults.
Does the concat demuxer make transitions seamless?
No. It reads compatible files in sequence, but mismatched streams or inaccurate duration information can cause artifacts or gaps. Check the FFmpeg warnings and listen across transitions in your own playlist; do not infer seamlessness from a successful start.
Should I use RTMPS or HLS?
YouTube recommends RTMPS for ordinary live content, and it is the straightforward choice for this workflow. HLS has different segment and media-format requirements, so it is not simply another URL to substitute without implementing and testing those requirements.
Does a running FFmpeg process mean my YouTube broadcast is live?
No. The process can be running while ingest is unhealthy, and a YouTube event can have a state distinct from the encoder connection. Confirm the Live Control Room preview and stream-health messages, then check public playback as part of your monitoring routine.