A Raspberry Pi 5 can play a folder of recorded videos into YouTube Live by feeding FFmpeg an ordered file list and sending its output to the ingest address shown in YouTube Studio. The reliable approach is to test the files and complete broadcast path first, then choose stream copy or software encoding based on what the source media and Pi can sustain.
The Pi 5 can decode HEVC video, but it does not have dedicated hardware video encoding. If your files need re-encoding, the workload matters: resolution, frame rate, codec, and audio all affect whether software encoding can keep up. Treat a successful short test as a starting point, not proof that an overnight broadcast will behave the same way.
What the Raspberry Pi 5 workflow involves
Think of this setup as four separate jobs: prepare the playlist, read it in real time, either copy or encode the media, and deliver the result to YouTube. Separating those jobs makes troubleshooting easier. If the broadcast stutters, for example, you can ask whether FFmpeg is reading the next file, whether the Pi is encoding fast enough, or whether the network or YouTube ingest is the problem.
First, put the videos on storage that the Pi can read consistently. Create a text playlist in the order you want. FFmpeg’s concat demuxer reads that list as a single input sequence, but it does not decide what “next” means for your channel: the order comes from your list. A filename sort is a convenient choice only if the names reflect the intended sequence.
Next, pace playback at real time. Without real-time pacing, a command-line tool can process input faster than it should, which is not the same as sending a live programme at its normal speed. Then decide whether to pass through the existing video and audio streams or convert them to a consistent output. Finally, connect the output to the current stream URL and key shown in Studio.
This is a local playback-and-broadcast arrangement: the Pi must remain powered, have access to the files, and retain a stable network connection. A folder is not automatically a 24/7 playlist. You need to decide what happens at the end of the list and test that behaviour with the FFmpeg build you install. If you want to compare this with a workflow that does not rely on your own connection, see how a YouTube stream can run without using your own internet.
Check the video files and Pi setup
Start by inspecting a representative set of files rather than assuming everything in the folder matches. Note each file’s video codec, dimensions, frame rate, audio codec, sample rate, and duration. FFmpeg’s ffprobe utility can report media properties; check its output for the first file, a typical file, and any file that looks different. A mix of camera exports, downloaded clips, or edited videos can have different streams even when the filenames look alike.
Check that the Pi can read the files without pauses. Keep them on the microSD card or a USB drive with enough space for the library and predictable access. Pi 5 has USB 3.0 ports and a microSD slot, but this does not make every drive, cable, or file system interchangeable. Test the actual storage path you plan to use, and avoid unplugging a drive while FFmpeg is reading it.
Use a suitable Pi 5 power supply and place the board where it can run without being disturbed. If the workload is substantial, monitor the system during testing for throttling or instability rather than assuming that a short run proves it is ready for a long one. No particular case or cooling arrangement is required by this workflow, but an enclosure that blocks airflow can make a sustained CPU task less comfortable than a brief setup check.
The file properties should drive your output choice. A folder of H.264 video and AAC audio with matching parameters may be easier to pass through than a mixture of formats. If the list contains different frame rates, resolutions, audio layouts, or time bases, a single output may require conversion, or you may encounter problems at the transitions. Keep a small inventory of exceptions so you can test those boundaries deliberately.
The same source checks matter for channels with spoken lessons or devotional programmes: a silent intro, clipped first syllable, or abrupt switch in loudness is visible to viewers even if the ingest indicator is green. For long programmes, the practical issue is not only whether the file plays once, but whether audio remains aligned after successive transitions. The guide to diagnosing FFmpeg audio drift in a long-running meditation stream covers a related symptom and gives you a useful checklist if sound and picture begin to diverge.
Build an ordered playlist
Make a plain-text concat file, for example playlist.ffconcat, with the required first line and one file entry per video:
ffconcat version 1.0
file 'videos/01-introduction.mp4'
file 'videos/02-lesson.mp4'
file 'videos/03-recap.mp4'
The paths can be relative to the directory where you run FFmpeg, which makes a project folder easier to move as a unit. Use quotes where paths contain spaces, and test the list before the broadcast. The FFmpeg concat demuxer documentation explains the list format, timestamp handling, and safe-path behaviour. The default rejects some paths considered unsafe; do not disable that protection casually. If you need absolute paths or unusual filenames, understand the implications and test your exact list locally.
Do not assume that FFmpeg will sort a directory for you. If you want lexical ordering, name files with a consistent numbering scheme such as 01, 02, and 10, then generate or write the list in that order. Otherwise, arrange the entries manually. Keep the list itself under version control or make a dated backup if it represents a programme schedule you need to repeat.
Check the joins, not just the first file. Run through a few minutes around a transition and look for a black gap, repeated audio, a sudden change in volume, or a timestamp warning. The concat demuxer works best when the files’ streams are compatible. When durations or timestamps are unusual, transitions can behave differently from a normal edit in a video editor.
Plan the end of the list explicitly. If the schedule should stop after the last file, verify that the process exits cleanly and understand what YouTube displays when the encoder disconnects. If the programme should repeat, test the loop or list-regeneration method with your installed FFmpeg version and representative sources. There is no universal repeat command that is safe to assume for every mix of formats and builds.
A playlist is also a programming decision. For a study channel, you may want a lecture followed by a revision segment, while a bhajan channel may need a deliberate order that avoids an abrupt change in loudness. If you rotate episodes or schedule content by time of day, decide that logic before making the concat list; a static list simply plays the sequence you have given it. The guide to rotating episodes in a 24/7 YouTube cartoon stream is relevant if your folder is part of a larger repeat schedule.
Choose stream copy or software encoding
Stream copy and software encoding solve different problems. Stream copy passes the compressed streams through without decoding and re-encoding the video. It reduces the Pi’s encoding work, but it only works cleanly when the input streams, timestamps, parameters, container and output requirements align. Software encoding decodes and creates a new output stream, giving you control over format and bitrate at the cost of CPU time.
| Path | Useful when | Main trade-off | What to test |
|---|---|---|---|
| Stream copy | The source codecs and parameters already suit the output | Low encoding demand, but less control and more sensitivity to mismatches | Audio/video compatibility and clean transitions |
| Software encoding | You need a consistent output format or different settings | More control, but the Pi must encode in real time | Sustained CPU load, dropped frames and output quality |
Raspberry Pi’s Pi 5 specifications list HEVC decoding support. That is decode support, not an encoder for creating a new live output. Raspberry Pi software engineering director Gordon Hollingworth explained that Pi 5 encoding is done on the processors and that the board omits dedicated hardware encoding. The practical implication is simple: do not infer software-encoding performance from the decoding specification.
For compatible files, stream copy may avoid the most demanding processing step. But one file with a different codec, a varying frame rate, or incompatible timestamps can undermine that choice. If you have a mixed folder, either test each transition or convert the sources into a consistent format before relying on a long-running list. Converting files in advance can also move the workload away from the live broadcast, though it adds preparation time and another quality check.
If conversion is necessary, begin conservatively. Choose an output resolution and frame rate that suit the content and that the Pi can sustain in your own test. Watch CPU load and FFmpeg’s progress while a representative moving scene is being encoded; a static black frame is not a useful stress test. Increase output demands only after the complete path runs steadily for an extended test. YouTube’s encoder settings guidance lists supported codecs and recommends a two-second keyframe interval, with a maximum of four seconds. It also lists CBR and audio options; check the current guidance for the target mode rather than copying one universal bitrate into every setup.
Use a codec and audio format that YouTube currently accepts for live ingest, and select bitrate values for the chosen codec, resolution, and frame rate from YouTube’s guidance. Those values are not interchangeable. Your connection must also sustain the outgoing stream with room for normal variation; if the Pi is simultaneously reading a drive and encoding, diagnose CPU and network conditions separately.
Connect FFmpeg to YouTube Live
In YouTube Studio, create or select the live stream and copy its ingest server URL and stream key. The URL identifies where to send the broadcast; the key identifies your stream. Treat the key as a password: do not post it in a public script repository, screenshot, or support message. If you expose it, replace or reset it in Studio before broadcasting.
Use RTMPS when the selected FFmpeg build and workflow support it. YouTube’s RTMPS developer reference describes a secure ingest endpoint and stream name; Studio supplies the current values for your stream. Some tools take URL and key separately, while others expect the key appended to the URL. Follow the syntax expected by your installed build, and confirm RTMPS support rather than assuming it is present.
A conceptual FFmpeg invocation has four parts: the concat input, real-time pacing, the output handling choice, and the destination. For example, a stream-copy test might be structured like this, but it is not a universal command for every source or build:
ffmpeg -re -f concat -safe 0 -i playlist.ffconcat -c copy -f flv "rtmps://INGEST_URL/STREAM_KEY"
Use -safe 0 only when needed for paths that the default safe-path check rejects, and only after you understand which files the list can reference. The placeholder destination is not a real URL: replace it with the current value from Studio using your build’s required URL/key format. If stream copy is not suitable, replace the copy settings with explicit video and audio encoding settings that meet current YouTube guidance and are within the Pi’s tested capacity. Check ffmpeg -encoders and the FFmpeg build documentation for available codecs and protocols before planning around a particular option.
Scheduled broadcasts can show a preview before they are actually live. Start the encoder, inspect the preview and health indicators in Studio, and press Go live when the schedule flow asks you to. First-time live streaming may require account enablement time, so do not leave channel activation to the night of the event. YouTube’s live streaming setup instructions describe the current Studio flow; follow the instructions shown for your account.
Keep the command in a private, readable script if you need to run it repeatedly, but avoid hard-coding a reusable secret in a file that others can read. A protected environment variable or an operator-entered value can reduce accidental exposure, depending on your comfort with shell tools. Verify the final command on a short private or unlisted test before scheduling public viewing.
Test playback, ingest, and stream health
Test the complete chain, not merely whether FFmpeg launches. Start with a short sequence containing representative motion and audio, including at least one transition between files. Confirm that FFmpeg advances through the playlist at real time and that it does not report sustained encoding lag, timestamp errors, or repeated read failures. A process that has opened a connection has not yet proved that the programme is watchable.
Then inspect YouTube Studio’s preview and stream health. Check that the image and sound arrive, that the aspect ratio and level look right, and that the health status remains acceptable while the representative section plays. YouTube advises testing before an event; its guidance is worth following even when the programme is prerecorded. A preview that works for a few seconds does not establish that a much longer broadcast will stay healthy.
For a software-encoded output, compare the processing load with the pace of the media. If encoding falls behind, reduce the workload, for example by selecting a less demanding output mode, or prepare a compatible version in advance. For stream copy, investigate the source streams and timestamp continuity instead. If only the boundary between two specific files fails, the folder is not homogeneous enough for the tested path.
Also test the network and storage arrangement you will actually use. Prefer a stable wired connection where practical; avoid placing the Pi on a network that routinely changes or where other traffic can consume the available upload capacity. Leave the storage connected, and test a longer section than a single clip so that transitions, disk access, and sustained processing are represented. The Raspberry Pi FFmpeg disconnect troubleshooting guide is useful if the stream drops when the network changes.
Write down the known-good playlist, command options, output mode, and Studio health observations. Do not store the stream key in a shared log. If you change the files, FFmpeg build, output settings, storage device, or network path, repeat the relevant test; a previous result does not validate a materially different setup.
Common limits and recovery options
The Pi’s main constraint is software encoding capacity, which depends on the workload. A low-motion clip and a busy scene can impose different work, and a settings change can alter the load again. There is no performance figure that can replace a test on your own files. If encoding is unstable, stream copy may help only if the source fits; otherwise use a less demanding encode or move the broadcast workload to a platform that better suits your requirements.
Long broadcasts add operational concerns. YouTube states that streams under 12 hours are automatically archived, but do not rely on that behaviour for a broadcast planned to exceed the stated duration; check the current official guidance and make a recording plan if an archive matters. A long playlist also needs a deliberate end-of-list and restart strategy. Test any scheduled restart or loop rather than assuming FFmpeg will resume exactly where it left off after a failure.
For a disconnect, first note whether FFmpeg exited, lost its input, or remained running without a healthy ingest. Check power, storage connection, network link, and the relevant FFmpeg error before restarting. If the key or ingest URL changed, fetch the current Studio values. A restart can restore a broadcast, but it may create a gap or a new stream state; it is not a substitute for monitoring.
If the local Pi proves too demanding to operate, be candid about the trade-off. Keeping the Pi means you manage power, storage, network and recovery yourself. A managed cloud playback workflow can remove the need to leave your own computer running for file-based streaming; StreamNeo is designed for the specific pain of a local machine having to stay on, though it is YouTube-only and does not change the need to prepare and verify your programme files.
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 5 stream a folder of videos to YouTube Live?
Yes, if FFmpeg can read the ordered list and the Pi can pass through or encode the media at real-time speed. Test the whole playlist path and YouTube preview before relying on it for a scheduled broadcast. The result depends on source compatibility, output settings, and your network.
Should I use stream copy or software encoding?
Use stream copy when the file streams already meet the output needs and remain compatible across transitions. Choose software encoding when you need a consistent codec or different output settings, then check the Pi’s sustained processing load. Neither path should be assumed to work for every folder without testing.
Does Raspberry Pi 5 have hardware video encoding?
No dedicated hardware video encoding is listed for Pi 5; Raspberry Pi’s engineering explanation says encoding is done on the processors. Its HEVC decode capability does not mean that it can encode a new stream in hardware. Software encoding performance varies with the media and chosen output settings.
Will FFmpeg repeat the folder forever?
Not automatically just because the input is a folder or concat list. You must implement and test the repeat behaviour supported by your installed FFmpeg version and media set, or regenerate the list deliberately. Check the end of one pass and the start of the next in YouTube preview before leaving it unattended.