A Raspberry Pi can send a video from a USB drive to YouTube Live using FFmpeg, but the setup needs to be checked on the exact board, operating system, storage and network connection you plan to use. The safest approach is to mount the drive, confirm the file can be read, create the YouTube broadcast, and run a private or unlisted test before treating it as an always-on channel.
A looped stream is not automatically a reliable 24-hour archive. Power interruptions, a missing USB mount, network loss, FFmpeg errors and YouTube’s archive rules all affect the result, so build recovery checks and a broadcast plan into the setup from the beginning.
Check the USB media and mount
Start with the part that is easiest to overlook: whether the Raspberry Pi can still see and read the USB drive after a reboot. The exact mount path, filesystem, drive model and Pi compatibility depend on your installation, so do not copy a path from another guide and assume it applies to your system.
Connect the drive and identify where it has been mounted. On a desktop environment, the file manager may show the location. On a command-line installation, inspect the mounted devices and directories using the tools available in your operating system. You are looking for two separate facts:
- the USB drive is mounted at a known path
- the video file opens and can be read from that path
Use a simple filename without unusual punctuation while you are setting up. A file such as station-loop.mp4 is easier to reference than a name containing several spaces, brackets and symbols. This is not a requirement of YouTube, but it removes one source of shell quoting errors.
Check the file itself before involving YouTube. Play it locally if your setup permits, or ask FFmpeg to inspect its streams and duration. Confirm that it contains the expected video and audio, that the picture is not rotated or damaged, and that the audio is present. A useful early check can prevent the familiar situation where the broadcast is live but silent, covered by a black frame or repeating a short unwanted section. If that is already happening on an established channel, the troubleshooting steps in why a 24/7 YouTube radio stream has no sound are relevant here too.
Keep the drive connected directly and securely. A loose connector, an underpowered hub or a drive that goes to sleep can interrupt the source even when the Pi itself remains running. The reviewed documentation does not establish a particular USB drive, filesystem, capacity or Pi model as suitable for this job, so verify those details on your own hardware.
For a channel that must recover after a restart, decide what should happen if the drive is absent. FFmpeg should not be launched against an empty directory or a path that has changed. A small startup check that confirms the expected file exists is safer than allowing the process to fail with an unclear error message.
Create the YouTube Live stream
Open YouTube Studio and use the Live Control Room to create or open the broadcast. YouTube’s encoder setup instructions describe the flow for choosing an encoder, obtaining the server URL and entering a stream key.
You will need two values from YouTube:
| Value | What it does | How to handle it |
|---|---|---|
| Server URL or ingest endpoint | Tells FFmpeg where to send the live feed | Copy it exactly from the selected YouTube setup |
| Stream key | Identifies the broadcast for your channel | Treat it like a password and keep it private |
Do not confuse the public watch URL with the ingest URL. Viewers use the watch URL; FFmpeg uses the server address supplied by YouTube. If YouTube offers a choice of endpoint or protocol, follow the current instructions shown for your account and selected encoder.
Set the visibility deliberately while testing. Private or unlisted is usually more appropriate than sending an unfinished loop to subscribers, though the right choice depends on the purpose of your test. Confirm that the scheduled or created broadcast is the one you intend to feed before starting FFmpeg.
YouTube recommends RTMPS, which carries RTMP over an encrypted connection. Its encoder settings guidance explains the current protocol and video settings, while Google’s RTMPS ingestion guide describes the requirement for a correct RTMPS endpoint and port 443. Use the endpoint YouTube provides and confirm that your installed FFmpeg build supports the protocol you select.
Keep the Live Control Room open during the first setup. It can show whether YouTube is receiving a signal, whether the stream has health warnings and whether the incoming picture and sound match the source file.
Protect the ingest key
The stream key is not a label. It is a credential that allows an encoder to send to your channel. Do not place it in a public shell script, screenshot, tutorial, repository, shared chat, support ticket or file that is synchronised to a public service.
A safer arrangement is to keep the key in a protected local configuration file or supply it only when starting the process. Restrict access to that file according to the operating system’s permissions, and avoid commands that save the full key in a public command history. The precise method depends on the shell and process supervisor you use, but the principle is the same: the key should be available to the encoder without becoming part of the media folder or published documentation.
When writing notes for your own setup, replace the real key with a marker such as YOUR_STREAM_KEY. Never paste the real value into a guide that might later be reused. If you believe the key has been exposed, use YouTube Studio to reset or rotate it, then update the local configuration.
Also protect access to the Raspberry Pi itself. A device connected to your home or business network can expose more than the live stream if its login is weak or its software is left unmanaged. Keep the Pi in a place where the USB drive and power connection cannot easily be disturbed, and record the recovery steps somewhere you can reach if the device needs attention overnight.
Configure FFmpeg for the USB file
FFmpeg needs to read the file in real time, loop it, encode or copy the required streams, and send the result to YouTube using an RTMP-family output. The source file may already use a codec YouTube accepts, but copying it unchanged is not always the simplest route. A file can have an unsuitable frame rate, audio format, pixel format or container even though it plays locally.
The following is an illustrative command shape, not a tested command for a particular Raspberry Pi, operating system or FFmpeg build:
ffmpeg -re -stream_loop -1 -i "/path/to/usb/station-loop.mp4" \
-c:v libx264 -preset veryfast -b:v 3M -maxrate 3M -bufsize 6M \
-pix_fmt yuv420p -g 60 \
-c:a aac -b:a 128k -ar 48000 \
-f flv "rtmps://YOUR_YOUTUBE_ENDPOINT/YOUR_STREAM_KEY"
Do not replace the placeholders and assume the result is ready for an overnight broadcast. The correct input path, endpoint, protocol support, encoder, bitrate and keyframe settings depend on your installation. In particular, the command above uses software H.264 encoding, which may be too demanding for an unspecified Pi at the chosen resolution and frame rate. A board may need a lower output setting, a different available encoder or a source that can be copied rather than re-encoded. Confirm what the installed FFmpeg build supports and observe the Pi’s behaviour under load.
The -re option is important when a file is being used as a live source. FFmpeg documents it in its real-time streaming examples. Without real-time pacing, a normal file can be read as quickly as the system allows rather than at the speed viewers should receive it.
-stream_loop -1 requests repeated input playback in FFmpeg versions that support that option. Check the installed documentation because option availability and behaviour can vary between builds. If your file has a different extension or contains multiple audio tracks, inspect the input first and choose the required streams explicitly.
The output uses an FLV container because that is the format used by FFmpeg’s RTMP examples. Prefer RTMPS when YouTube’s endpoint and your FFmpeg build support it. The destination must remain private in any published example. A stream key embedded in a command is easy to copy accidentally, so use a protected substitution or local configuration in your actual deployment.
FFmpeg’s protocol documentation covers RTMP-related options, and its complete documentation includes output and recovery options. Read the documentation for the version installed on your Pi rather than assuming that an option found in a newer example is present locally.
If the source file is already encoded suitably, stream copying can reduce the Pi’s encoding workload, but it can also fail if the source parameters do not fit the intended live output. Re-encoding gives you more control over the output but consumes more CPU and power. Test both only if you understand the trade-off and can monitor the result.
Select and test stream settings
Choose the output from the limits of your actual installation, not from the highest setting shown in a general tutorial. YouTube Help currently lists H.264 guidance of 3 Mbps for 720p30 and 5 Mbps for 1080p30. Those are recommended ingestion bitrates, not a promise that an unspecified Raspberry Pi can encode them continuously.
YouTube also lists a recommended keyframe interval of two seconds, with a maximum of four seconds. At 30 frames per second, a two-second interval corresponds to a GOP setting of 60, which is why the illustrative command uses -g 60. Check the resulting stream health rather than assuming that the setting was applied correctly.
| Output target | YouTube H.264 bitrate guidance | Practical question |
|---|---|---|
| 720p at 30 fps | 3 Mbps | Can the Pi encode it while reading from USB and can the connection sustain it? |
| 1080p at 30 fps | 5 Mbps | Does the selected Pi maintain the required output without overheating or dropping frames? |
The table reflects YouTube’s current guidance, not an endurance test. A stable lower-resolution stream is more useful than a higher-resolution stream that drops frames, loses audio or stops when the CPU is busy. Leave upload headroom for the rest of the network, especially if the connection is shared with other people or devices.
Use representative material during testing. A quiet devotional image with a short audio loop may not expose the same problems as a video with movement, changing brightness and several audio transitions. YouTube advises monitoring the stream health and messages in the Live Control Room. Let the test run long enough to pass a loop boundary, because a file that starts correctly can still fail when FFmpeg returns to its first frame.
If the Pi becomes hot, the output stutters or the audio falls behind, do not immediately increase buffering or retry counts. First reduce the workload by choosing a suitable resolution and frame rate, simplifying the source or using an available hardware-accelerated path that you have verified on the selected board. Hardware acceleration is not a universal answer and may have its own codec and driver limitations.
For a wider comparison of source-device choices, the guide to making a 24/7 YouTube music stream with OBS on an Indian internet connection explains why the encoder and connection need to be considered together. The Pi approach can be compact, but it leaves you responsible for the local power, storage, network and process.
Verify playback and recovery behaviour
A successful first frame is only the beginning of the test. Check the preview in the Live Control Room, then open the viewer-facing result from a separate device or connection. Confirm the following:
- the picture is moving and has the intended framing
- the audio is audible and remains synchronised
- the loop returns to its beginning without a visible failure
- YouTube reports a healthy incoming signal
- the public, private or unlisted visibility is what you intended
- the Pi is not running out of CPU, memory, storage or power
Test the failure points you can safely reproduce. Stop and restart FFmpeg, temporarily disconnect the network if appropriate, and reboot the Pi after confirming that you can restore the USB mount. Do not perform an outage test on a public broadcast that viewers depend on. Use a separate or private test broadcast where possible.
FFmpeg documentation describes retry and recovery options, including output FIFO examples intended to attempt recovery after temporary errors. These options can help with transient failures, but they do not establish uninterrupted service. Recovery still depends on the cause of the error, the network, the source drive, the YouTube broadcast state and the way the process is supervised.
A practical always-on arrangement needs a restart strategy. That may be a service manager, a scheduled task or another supervisor available on your operating system. The supervisor should check that the USB file exists, start FFmpeg with the protected key, record useful logs and restart the process only when appropriate. It should not repeatedly launch dozens of copies after a configuration error.
Decide how you will know that recovery worked. A process can be running while YouTube receives no usable video. Check the Live Control Room, inspect logs and, for a channel that matters overnight, use a separate viewer check or notification method. You can also review the local temperature and resource usage during the test.
This is the point where a local Pi setup differs from a managed cloud loop. You keep control of the hardware and source drive, but you also inherit the responsibility for mounting, power, process supervision and physical access. If those duties are the part you do not want to maintain, uploading once versus streaming forever with cloud loops describes the alternative workflow. StreamNeo removes the need to leave this particular computer running by taking an uploaded file and sending it to YouTube from the cloud, but it remains a YouTube-only option and should still be tested for your channel.
Plan for YouTube’s archive limit
A 24/7 source loop and a 24-hour YouTube replay are not the same thing. YouTube Help states that “All streams under 12 hours will be automatically archived.” That condition matters if you need viewers to replay yesterday’s devotional programme, music block or local information loop.
Do not build your plan around the assumption that one uninterrupted 24-hour broadcast will always be saved as one complete replay. The archive condition is a YouTube platform rule and can change, so check the current encoder setup guidance before publishing a long-running schedule.
If preserving replays matters, plan intentional broadcast segments that remain under the stated archive threshold. Each segment needs its own lifecycle: stop or end the broadcast, start the next one, and confirm that the new stream is receiving the expected source. That may require scheduling, a process supervisor and a way to refresh the YouTube broadcast rather than merely looping the file forever.
There is a trade-off. One long-running broadcast may be simpler for a viewer who wants a continuous channel, while planned shorter segments make the archive behaviour easier to reason about. Segments can also create brief transitions, new watch URLs or additional operational steps. Choose based on whether live continuity or replay preservation is more important.
Do not promise a true uninterrupted 24/7 archive, and do not describe this workflow as guaranteed uptime. A continuous installation depends on electricity, the USB mount, the source file, the Pi, the network, FFmpeg and YouTube’s live broadcast lifecycle. Test the complete chain on your own equipment before inviting viewers to rely on it.
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 loop any video file from a USB drive?
Not reliably without checking it first. Confirm that the Pi can read the mounted file, that it contains the expected video and audio, and that its codecs and parameters can be handled by the FFmpeg build and chosen output settings.
Should I use RTMP or RTMPS?
YouTube recommends RTMPS for encoder delivery when the selected endpoint and FFmpeg build support it. Use the current endpoint supplied by YouTube, check that the connection uses the expected port and protocol, and never publish the stream key.
Will the Raspberry Pi run the stream without supervision?
It may continue while every dependency works, but a running FFmpeg process is not a guarantee that YouTube is receiving a healthy broadcast. Test restarts, USB availability, network interruptions and loop boundaries, then use a supervisor and a monitoring method suited to your channel.
Will YouTube save a complete 24-hour replay?
Do not assume that it will. YouTube states that streams under 12 hours are automatically archived, so use planned shorter broadcasts when preserving replays is important and recheck the current official archive guidance before relying on it.