FFmpeg can read a video stored on a USB drive in real time on a Raspberry Pi and send it to YouTube Live as an incoming live feed. This is not a normal YouTube video upload: YouTube receives a broadcast feed while FFmpeg is running, rather than a file submitted through the usual upload flow.
You need a channel allowed to livestream, a mounted and readable file, a working FFmpeg build, and the current ingest details for the intended stream. Treat the stream key as a password, and check YouTube’s preview before making the broadcast public.
File-to-live ingest is not a video upload
A video upload gives YouTube a file to process and publish as an on-demand video. In this workflow, FFmpeg opens a local file and sends its audio and video over a live connection at playback speed. Viewers see a live broadcast, and when the process stops, the incoming feed stops too.
There are two related YouTube Live concepts to keep straight. A live stream represents the incoming feed and its ingestion details; a live broadcast is the event viewers watch. YouTube’s documentation on broadcasts and streams describes how those resources relate. In Studio, you may work with a scheduled broadcast and a stream assigned to carry its feed. For a straightforward setup, select or create the intended live event and use the stream details YouTube currently provides for it.
The file is not copied into YouTube’s video library by this command. FFmpeg keeps reading it from the Pi and sends a continuing signal. If you want a conventional on-demand video instead, use YouTube’s upload process; if you want viewers to join a live event, use live ingest and check the broadcast preview.
Decide whether the file should play once or repeat. Without looping, FFmpeg exits when playback reaches the end, and the live ingest may stop. With looping, the same file starts again, which suits a continuous music or ambience channel but can be repetitive for viewers. If you are comparing a local-file loop with another way of running an always-on feed, the prerecorded-video scheduling guide explains a different workflow.
Confirm the channel can livestream
Before preparing the Pi, sign in to the YouTube account that owns or manages the channel and confirm live streaming is available. YouTube’s current live-streaming permissions documentation describes permission-related requirements and errors. Follow the current guidance there and in Studio; eligibility and interface details can change, so do not rely on an old screenshot or a guide written for another channel.
This check matters because a correctly mounted file and a valid FFmpeg command cannot overcome a channel permission issue. If the channel has not streamed before, allow time to complete any activation steps YouTube presents and confirm that the relevant account has access. Do this before a planned devotional programme, local news loop, or study session rather than discovering a restriction at the start time.
Also decide whether you intend to go live immediately or prepare a scheduled broadcast first. A scheduled event gives you a place to inspect the incoming feed before viewers arrive. The controls shown in Studio can change, but the principle does not: identify the broadcast you mean to use, then verify that the selected incoming stream is associated with it.
Connect and inspect the USB media
Connect the drive to the Raspberry Pi and use the file manager or command line for the operating system you installed to find where it has been mounted. Do not assume one universal mount path. Linux distributions and desktop configurations can mount removable media in different locations, and a path may also change if the drive is reconnected.
Confirm the exact filename and that the Pi can read it. A simple shell check is:
ls -l "/path/to/usb/video.mp4"
Replace the example with the actual mounted path and filename. Keep the quotation marks if there are spaces in either part of the path. The command should show a file, not an error that it cannot find the path. If it does not, inspect the mount location, spelling, and access permissions before starting FFmpeg.
FFmpeg can read regular files, but it does not mount USB media or locate files for you. The FFmpeg command-line documentation covers input files and option placement. Check that the drive stays connected and that the file is not being moved or edited while the stream is running. For a long-running channel, a physical connection that can be disturbed or a drive that is shared for other tasks adds avoidable uncertainty.
The Pi must read the file continuously, process its streams as needed, and maintain network access. If you are planning a local always-on installation, power interruptions deserve attention too; the practical Raspberry Pi UPS setup guide discusses that separate part of the setup.
Prepare the stream and broadcast in YouTube
In YouTube Studio, create or select the live broadcast you intend viewers to watch. Then locate the assigned stream’s current ingestion details. YouTube’s liveStreams resource reference describes ingestion information, including the address and stream name used to send a feed. The labels and layout in Studio may differ from API terminology, so use the values presented for the selected stream rather than copying a URL from an unrelated tutorial.
Prefer RTMPS for the ordinary lower-latency workflow, unless your current YouTube instructions or a specific technical requirement say otherwise. YouTube documents RTMPS as RTMP carried through an SSL connection and specifies an appropriate endpoint and port. Its RTMPS ingestion guide is the place to check those current requirements. Avoid hard-coding an address from a blog post: use the current endpoint displayed or documented for your stream.
YouTube also supports other ingestion protocols, but that does not make them interchangeable in every encoder setup. The official protocol comparison outlines the available approaches. For a basic FFmpeg file-to-live job, RTMP or RTMPS is usually the simpler path; HLS or DASH can bring different encoder requirements and latency characteristics. Do not switch protocols merely to troubleshoot a typo in an RTMPS URL.
Before copying any values, make sure the selected stream belongs with the broadcast you expect. A feed can reach YouTube while the wrong event is selected or no viewer-facing broadcast is prepared. Check the broadcast’s status and association in Studio, then keep that page available for the later preview test.
Keep the ingestion key private
The stream key authorises a sender to deliver video to the corresponding live stream. Handle it as a credential, not as a harmless label. Do not paste it into a public post, documentation, screenshot, support forum, livestream description, or a shell command that you later share.
A command-line example necessarily has to show where the destination details go, but it should use placeholders only. Do not put your real key into an article draft, public chat, or a screenshot of your terminal. Shell history may retain commands, and logs or screen recordings can expose text that was visible only briefly. Keep access to the account and stream details limited to people who need to operate the channel.
If a key has been exposed, use YouTube Studio’s current controls to replace or reset it, then update the sender with the new details. A changed key can interrupt any process using the old value, so plan the change and verify the replacement in preview. Do not assume that deleting a public message removes copies, cached pages, or screenshots.
When a setup requires you to enter a real credential into a shell, avoid leaving it in a reusable public script or a shared command history. The precise safe method depends on your operating system and how you run the job. In all cases, keep the actual key out of examples and never ask someone to send it to you for troubleshooting. A redacted error message is usually enough to diagnose a connection issue.
Check FFmpeg, then configure the file and ingest
First check what the installed FFmpeg build on this Pi can do. Builds differ, so verify locally rather than assuming a codec or protocol is present:
ffmpeg -version
ffmpeg -encoders
ffmpeg -protocols
Look for the video and audio encoders you plan to use and support for the chosen output protocol. A build may not include libx264, AAC encoding, or RTMPS support in the way a command expects. If an encoder is unavailable, the command will fail before or during the attempt; use an available supported option or install a suitable FFmpeg build for the Pi’s operating system.
Here is a template, not a tested or guaranteed command for every Raspberry Pi. Replace the input path and the destination placeholder with the current values for your stream, while keeping the real key private. Confirm the selected codecs and RTMPS support in the installed build first:
ffmpeg -re -stream_loop -1 -i "/path/to/usb/video.mp4" \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-c:a aac -b:a 128k \\
-f flv "<RTMPS_INGESTION_URL>/<STREAM_KEY>"
The ordering is intentional: input options precede the corresponding -i, output options precede the destination, and the output URL is last. -re asks FFmpeg to read at the file’s native rate rather than sending the content as fast as possible. -stream_loop -1 means repeat indefinitely; omit that option if the file should play once. With a single play-through, FFmpeg finishes at the end of the file and the live feed may end with it.
The example uses H.264 video and AAC audio, but it is not a recommendation that those settings will run in real time on every Pi. Encoding capacity depends on the model, the input codec, resolution and frame rate, the FFmpeg build, and network capacity. If the source codecs and container already suit the selected YouTube ingest, copying the streams with -c:v copy and -c:a copy can avoid a fresh encode, but it is only appropriate when those streams are acceptable to YouTube. Otherwise, transcode and test.
There is no universal bitrate, frame rate, resolution, keyframe interval, or audio setting that can be promised for every file and Pi. Match output settings to YouTube’s current encoder guidance and the actual hardware and connection. If the Pi cannot sustain the chosen encode, symptoms can include delayed processing, dropped frames, or a feed that never becomes stable. Reduce the processing demand or use a more capable encoding setup rather than treating a template as proof of performance.
Options such as -preset veryfast affect the encoding trade-off, not the Pi’s fundamental capacity. A faster preset can reduce processing effort at the cost of compression efficiency, while copying may preserve an incompatible source stream. Run a short private or scheduled test with the actual file and intended network before relying on the configuration overnight.
Test the feed and verify the broadcast preview
Start FFmpeg with the broadcast ready in Studio, then watch the encoder output for connection or encoding errors. Allow YouTube time to show an incoming feed and inspect the preview for both picture and sound. Do not make the broadcast public simply because FFmpeg printed no immediate error; the preview confirms that YouTube is receiving something usable and that the viewer-facing event is the one you intended.
Check that motion appears at a sensible pace, audio is present if expected, and the file is not silently stuck on a black frame or an unintended opening slate. If looping, wait long enough to observe whether playback reaches the end and begins again as intended. For a one-play stream, understand when the file will finish and what you want the broadcast to do afterwards.
If YouTube does not show an incoming feed, work through the chain rather than changing several settings at once. Confirm channel permissions first, then check the exact current ingestion address and key, RTMPS spelling and port, and network access to port 443. Next verify the mounted path and read access, followed by the FFmpeg build’s encoders and output protocol. YouTube’s permissions and RTMPS documentation explain common classes of errors; a key copied from another stream or an outdated endpoint will not be fixed by changing video bitrate.
If the preview arrives but looks or sounds wrong, distinguish an ingest problem from a source-file problem. Check the local file playback, whether its audio track exists, and whether the selected codec handling matches the source. Inspect FFmpeg’s output for encoding or timing warnings. A shorter test file can help isolate a problem, but repeat the final test with the actual programme file before planning an unattended run.
For a 24/7 use case, test more than the first few minutes. Confirm that the Pi remains responsive, the USB connection stays stable, the network does not drop, and the loop behaves as expected. This cannot prove a future run will never fail; it gives you a chance to catch obvious problems while someone can still intervene. For broader context on a file-based YouTube channel, see the guide to streaming prerecorded 4K files continuously.
A local FFmpeg process also depends on the Pi remaining powered, connected, and available. If maintaining the machine is the part most likely to interrupt a long run, StreamNeo can remove the need to keep this particular computer running by accepting an uploaded video and sending it as a YouTube live stream; it does not remove the need to choose the right file, protect channel access, or check the broadcast.
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
How do I stream a video from a USB drive to YouTube Live with FFmpeg?
Mount the drive, confirm the exact readable file path, and use FFmpeg to read it at real-time speed while sending output to the current YouTube ingest details. Prepare the broadcast in Studio, keep the key private, and check the preview for picture and sound before making the event public.
How can I loop a video file on a Raspberry Pi and livestream it?
Use -stream_loop -1 before the input option in an FFmpeg command to repeat the input indefinitely. The Pi still has to read and process the file continuously, so verify that its build, hardware, storage connection, and network can sustain the actual stream.
Does FFmpeg upload the video to my YouTube channel?
No. It sends a real-time live feed from the local file to YouTube Live; it does not submit the file through YouTube’s normal on-demand upload flow. The feed and the viewer-facing broadcast are related but separate YouTube concepts.
What should I do if the YouTube preview stays blank?
Check livestream permissions, the current stream address and key, RTMPS connectivity, and whether the USB path is readable. Then confirm that the installed FFmpeg build supports the requested codecs and protocol, and inspect its output for an error.