A Raspberry Pi 3 can send an FFmpeg encoder stream to YouTube Live, including a sequence of local video files you are authorised to rebroadcast. The setup has separate parts: prepare the media, decide how files advance, configure YouTube ingest, and test the complete stream on your own Pi.
This guide is for local files, not for extracting and rebroadcasting videos from arbitrary public YouTube playlists. The commands below are examples, not a Pi 3-tested recipe; check your installed FFmpeg build and validate performance before depending on it overnight.
What this setup does—and does not do
The Pi reads media available on its local storage, FFmpeg encodes or passes through that media as configured, and the resulting live stream is sent to YouTube using your account’s ingest details. For a single file, FFmpeg can repeat the input indefinitely. For a group of files, you need an additional sequencing method: looping one input is not the same as playing a multi-file playlist.
A public video URL, or the fact that a video appears in a YouTube playlist, does not establish permission to rebroadcast it. Use content you own, content you have licensed for this use, or other material for which you have confirmed the necessary authorisation. YouTube’s video and audio formatting guidance says the uploader must be the copyright holder or an authorised representative for the delivered files. That is a platform requirement, not a determination of the rights status of any particular file.
This is also a hands-on encoder setup rather than a managed way to turn an uploaded file into a live broadcast. A Pi must remain powered, connected and able to sustain the chosen workload. If you are deciding whether the board is suitable for an always-on channel, the broader Raspberry Pi 24/7 stream setup guide covers the operational questions around using one continuously.
Prepare media you are authorised to stream
Start with files stored locally on the Pi or on storage that remains mounted and readable throughout the broadcast. Local files avoid relying on an internet source for every next item. They also make it possible to check the sequence, sound and playback before going live. Keep a separate copy of the originals, and avoid changing filenames or moving files once you have built the playlist unless you update the playlist too.
FFmpeg can only read formats supported by the build and input libraries installed on your system. Check a sample file before preparing a whole collection. A simple inspection command is:
ffprobe -hide_banner -i "intro.mp4"
This reports information about the streams FFmpeg can identify; it does not prove the Pi can encode that file in real time. Note its video codec, dimensions, frame rate, audio codec and duration. Then try a short playback or a short private test stream using representative material. If the collection mixes dimensions, frame rates, codecs or audio layouts, do not assume every transition will work simply because the first file did.
A consistent set of files is easier to operate. If you can choose the export settings, use the same frame size, frame rate and audio characteristics for each item. If you cannot, test transitions between the files that differ most. Inspect audio levels and the start and end of each clip: a silent opening, abrupt cut or long black frame may be technically playable but still make the channel feel broken.
Make sure storage has enough room for the prepared files and that the filesystem will be available after a reboot. A USB drive that has not mounted, a path with a typo, or a file that was renamed can stop a playlist before YouTube reports anything useful. Use plain, stable paths and filenames without relying on a graphical file picker.
Build a local playlist for FFmpeg
FFmpeg’s concat demuxer can read a text manifest listing files in order, provided the files have compatible streams and formats. A basic manifest named playlist.txt looks like this:
file '/home/pi/live/intro.mp4'
file '/home/pi/live/song-01.mp4'
file '/home/pi/live/song-02.mp4'
Paths must refer to files that actually exist from the Pi’s point of view. The manifest is not a YouTube playlist and does not fetch media from YouTube. It is simply an ordered list of local inputs for FFmpeg. The files’ ownership and permissions matter too: the account running FFmpeg needs read access to each file.
For compatible files, an example concat input begins like this:
ffmpeg -re -f concat -safe 0 -i /home/pi/live/playlist.txt \
-c:v libx264 -c:a aac output-or-ingest-options
This is illustrative, not a complete command to paste unchanged. -re asks FFmpeg to read at a rate resembling real time; encoding choices and output options still need to match your files, installed codecs, and YouTube’s current requirements. -safe 0 allows absolute paths in the manifest, so use it only with a manifest you control. Read the installed FFmpeg documentation and test the actual command against your version.
If the concat demuxer rejects the list, first test each file on its own and compare stream properties. Transcoding every input can make mismatches easier to handle, but it adds work for the Pi. Do not presume that a Pi 3 can keep up with a particular transcode merely because the command starts successfully.
Choose a sequencing and looping method
There are two distinct decisions: how to move through several files, and whether to repeat the whole sequence. For one file, -stream_loop -1 is the straightforward repeat mechanism. FFmpeg documents -stream_loop as an input option, with -1 meaning infinite looping; place it before the -i for the input it applies to. For example:
ffmpeg -stream_loop -1 -re -i /home/pi/live/one-video.mp4 \
-c:v libx264 -c:a aac output-or-ingest-options
That example loops one input. It does not create a playlist from multiple filenames. For a sequence, the concat manifest shown above provides the order; test whether your installed build and selected concat method can repeat the whole sequence as intended. A common approach is to use the concat input with the input-loop option before its -i, then verify that playback returns to the first entry after the last. Do not treat that combination as validated for every file set or FFmpeg build.
A different operational choice is to run one file at a time from a script and launch the next when the current one ends. That gives you more control over per-file handling, but it means the script must detect failures, preserve the intended order and avoid gaps or overlapping FFmpeg processes. It is more moving parts than a simple manifest, so it needs its own restart and transition tests.
| Method | Useful when | Main trade-off |
|---|---|---|
| Single file with input looping | You want one long visual or audio bed repeated | Simplest sequence, but there is no variation between files |
| Local concat manifest | Files are compatible and should play in a fixed order | Less scripting, but file compatibility and whole-list looping need testing |
| Script launches successive files | Files need different handling or the sequence changes often | More control, with more failure points to monitor |
Choose based on the collection and the maintenance you can support, not on an assumption that one method is faster on a Pi 3. The reviewed guidance does not establish a Pi 3 performance ceiling for a playlist stream. The FFmpeg main options documentation describes input looping, but it cannot tell you how your board, cooling, storage and files will behave together.
Configure YouTube Live ingest and stream key
In YouTube Studio, open Live Control Room and prepare the live event or stream settings. YouTube provides the ingest server URL and a private stream key for the encoder. Enter the current values shown for your account and event rather than copying an endpoint or key from an old tutorial. Keep the key out of public scripts, screenshots, chat messages and shared documents. If it is exposed, replace it in YouTube Studio before relying on the stream.
YouTube’s encoder setup help explains encoder-based live streaming and the settings expected at ingest. YouTube recommends RTMPS for encrypted transport. The current encoder guidance lists H.264, H.265/HEVC or AV1 in the applicable encoder modes, AAC or MP3 audio, constant bitrate, and a two-second recommended keyframe interval that should not exceed four seconds. For a common FFmpeg H.264 workflow, check that the output is configured accordingly and that the keyframe interval is actually being produced.
Do not select a resolution and bitrate just because they appear in a tutorial. YouTube’s published H.264 recommendations include 4 Mbps for 480p30, 8 Mbps for 720p60, 14 Mbps for 1080p30 and 17 Mbps for 1080p60. These are YouTube ingest recommendations, not measured Pi 3 capabilities. The appropriate choice depends on your source, what the Pi can encode or pass through reliably, and sustained upload bandwidth at the location.
| Intended H.264 output | YouTube recommended bitrate | Practical check before choosing |
|---|---|---|
| 480p30 | 4 Mbps | Confirm a stable upload connection with room for normal variation |
| 720p60 | 8 Mbps | Test encoding load and sustained upload at this output setting |
| 1080p30 | 14 Mbps | Confirm both the Pi workload and connection can sustain the selected output |
| 1080p60 | 17 Mbps | Do not assume the Pi 3 can encode this; test the full setup first |
The figures are YouTube’s recommendations as accessed in 2026, not a promise that a given internet connection or board can deliver them. Measure the connection during the hours when the channel will run, and leave headroom rather than treating a best-case speed test as sustained capacity. If your available upload is variable, choosing a lower output may be more dependable than targeting a higher resolution.
If you are operating a channel in India and cannot find the stream key in Live Control Room, check YouTube’s current account and activation state before rebuilding your FFmpeg command. This guide to a missing YouTube stream key in India can help separate an account setup issue from an encoder issue.
Run FFmpeg and check the live preview
First-time live streaming activation on YouTube may take up to 24 hours, so do not leave activation until the intended broadcast. YouTube’s live streaming setup guidance describes getting started and preparing an encoder stream. Create or ready the event, confirm the ingest details, then start FFmpeg. Sending an encoder stream before the event is ready can leave you troubleshooting the wrong stage.
Build the command from the tested input and output options, substituting the current ingest URL and your private key. Avoid putting a real key into a script that will be shared or committed to a public repository. Shell history and process listings may also expose arguments to other users on the same machine; limit access to the Pi and protect files containing credentials. For further precautions, see the practical advice on keeping a YouTube stream key secure, which applies even when your encoder is a Pi rather than a VPS.
Use YouTube’s preview or stream health information to confirm that video and audio arrive before making the event public or relying on it. Include movement and sound in the test, not only a static opening frame. Check that the preview shows the correct sequence, that the audio is present at a sensible level, and that the stream health messages do not indicate dropped frames or an unstable connection. A successful FFmpeg process alone does not prove the audience is receiving a healthy stream.
Keep the Pi in the physical conditions in which it will run: same power supply, storage, network connection and placement. Watch CPU behaviour and temperature during a representative test, and look for throttling, dropped frames, stalled playback or an unexpectedly growing delay. The supplied sources do not establish a tested Pi 3 performance limit, and this guide’s commands have not been tested on a Pi 3. Treat a short clean preview as a start, then run a longer supervised test before scheduling unattended use.
Diagnose common setup issues
When YouTube does not receive a signal, check the layers in order. Confirm FFmpeg can open each local file; confirm the manifest paths and permissions; confirm the output URL and current stream key; then check the network route and YouTube’s event state. A typo in the input path and an invalid key can produce very different symptoms, so use FFmpeg’s full error output rather than changing several settings at once.
If the stream starts but ends at the final playlist item, the input loop may apply to one file rather than the whole sequence, or the selected playlist method may not support the expected repeat in your build. Test a short manifest with two small files and observe whether it returns to the first entry. If it does not, use a sequencing method that explicitly starts the next pass or next file, and test end-of-file handling before the real broadcast.
If video appears but sound does not, inspect the input audio stream with ffprobe, then check the output audio codec and channel configuration. If the picture freezes or frames drop, distinguish a media problem from an encoding or upload problem: test a simpler file, reduce the output setting, and compare local playback with YouTube’s stream health messages. Do not infer from a single symptom that the Pi is too slow; isolate one variable at a time.
If the stream is stable at first but fails later, check power, cooling, storage mounting and network continuity as well as FFmpeg logs. A reboot can clear a temporary fault but does not explain it. Record the time and the last useful log message, and run another supervised test with the same settings. For a related FFmpeg case involving a different hosting setup, the guide to a stream stopping on an Indian VPS offers troubleshooting ideas, but VPS-specific causes do not necessarily apply to a Pi.
Decide whether to keep the Pi in the loop
A Pi-based encoder is sensible when you want local control, can maintain the device and are comfortable testing the exact file sequence and output settings. It gives you direct access to the files and command behaviour, but it also leaves power, cooling, network stability, restarts and credential handling in your hands. A playlist that runs once at your desk is not yet an unattended channel; include a reboot and recovery test in your plan.
If the recurring pain is keeping a computer powered and watching for dropped broadcasts, consider whether that operating model fits the channel before you invest time in more scripting. StreamNeo removes the specific need to leave your own computer running by turning an uploaded video into a YouTube live stream from the cloud, with monitoring and automatic restart if it drops. It is YouTube-only and is not a Raspberry Pi or FFmpeg feature; it does not change your responsibility to confirm content rights or YouTube settings.
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 stream videos from any public YouTube playlist with FFmpeg?
No. Public visibility or playlist membership does not give you permission to rebroadcast the videos. Use local files you own, have licensed for this use, or are otherwise authorised to deliver, and check the applicable rights and platform rules.
Does -stream_loop -1 loop a whole playlist?
It repeats the input to which the option applies; it does not itself define a multi-file sequence. Use a separate sequencing method, such as a compatible local concat manifest, and test that your chosen build repeats the complete sequence in the intended order.
What bitrate should I use from a Raspberry Pi 3?
There is no verified Pi 3 performance figure in the reviewed sources. Start from YouTube’s encoder recommendations as a guide to ingest settings, then test the complete workload at the chosen resolution and bitrate while watching upload stability, CPU behaviour and YouTube stream health.
Have these commands been tested on a Pi 3?
No. They are examples based on documented FFmpeg and YouTube mechanisms, not a claim of testing on a particular Pi 3 revision or software build. Check your installed FFmpeg options and run a supervised end-to-end test before relying on the setup.