This workflow sends a prerecorded file to YouTube as a Live encoder feed. It is not the same as uploading an ordinary video to your YouTube library: FFmpeg reads the file in real time and publishes it to a live event.
You need a Raspberry Pi that can read the external drive, an FFmpeg build with the required protocol support, a video that fits YouTube's ingest requirements, and the stream URL and private key shown in YouTube Studio. The commands below are illustrative, so verify your own path, media properties, network and stream health before relying on the setup overnight.
A live encoder feed is different from a normal upload
A normal upload transfers a completed file to YouTube for processing and later playback. A live encoder feed keeps a connection open while an encoder sends audio and video packets at the pace they should be viewed. YouTube receives that feed as a live broadcast and may show it to viewers while the encoder is still running.
Here, the Raspberry Pi is the encoder host. The external hard drive provides the source file, FFmpeg reads and optionally converts it, and YouTube receives the output through RTMP or RTMPS. The Pi does not need to upload the file first as a normal video.
That distinction matters when you plan a devotional channel, a study loop or a local information channel. A file that plays correctly in VLC is not automatically suitable for a live ingest connection. You must check its codecs, audio, resolution, frame rate, bitrate and timing. A stream-copy command carries the existing streams onwards; it does not repair an unsuitable source.
You also need the right to stream the material. This includes music, recorded programmes, images and any third-party footage in the file. YouTube's copyright guidance for live streams is the appropriate place to check the current rules for your content and account.
If you are planning a long prerecorded broadcast rather than a single event, the practical choices are covered in how to stream a pre-recorded video as live on YouTube. This guide concentrates on the Raspberry Pi, external storage and FFmpeg path.
Connect and mount the external drive
Connect the hard drive, SSD or USB stick to the Raspberry Pi and allow it to appear in the operating system. A USB hard drive may draw more power than the Pi or its hub can comfortably provide, so treat intermittent disconnections as a power and hardware question rather than an FFmpeg question. No particular drive model is assumed here.
Raspberry Pi documentation explains that common filesystems, including FAT, NTFS and HFS+, may be mounted automatically by Raspberry Pi OS at a path such as:
/media/pi/<HARD-DRIVE-LABEL>
The label and path are examples, not fixed values. Raspberry Pi OS Lite does not implement the same desktop automount behaviour, so a headless installation may require you to mount the drive yourself. See the Raspberry Pi configuration documentation for the current storage and mounting guidance.
Start by checking what the Pi can see:
lsblk -f
This lists block devices, partitions and filesystem information. You can also inspect the mounted directories:
ls -la /media/pi
If the drive is already mounted, enter the displayed directory and list its contents. For example, if the label is CHANNEL_DRIVE:
ls -la "/media/pi/CHANNEL_DRIVE"
Do not replace CHANNEL_DRIVE with that literal text unless it is actually your drive label. Spaces and punctuation in a label or filename are another reason to quote paths in shell commands.
For an unattended setup, avoid relying on a path you have not verified after a restart. A desktop may mount a drive under its label, while a manually configured system may use a mount point such as /mnt/channel-drive. Whichever arrangement you use, test it after disconnecting and reconnecting the drive, and again after rebooting the Pi.
A missing mount creates a particularly confusing failure. FFmpeg may report that the input file does not exist even though the drive is physically connected. Confirm the directory and file path first, then investigate FFmpeg.
Find and inspect the video file
Locate the actual media file before writing the streaming command. A simple recursive search can help when the drive contains several folders:
find "/media/pi/CHANNEL_DRIVE" -type f \( -iname '*.mp4' -o -iname '*.mkv' -o -iname '*.mov' \)
Use the complete result as the input path. Do not assume the first file is the intended programme, and do not assume the extension tells you which codecs are inside it.
FFmpeg can inspect a file without streaming it:
ffprobe -hide_banner "/media/pi/CHANNEL_DRIVE/video.mp4"
Look for the video codec, audio codec, pixel dimensions, frame rate, bitrate and duration. You can request a more compact summary with:
ffprobe -v error \
-show_entries stream=index,codec_type,codec_name,width,height,avg_frame_rate,bit_rate \
-show_entries format=duration,bit_rate \
-of default=noprint_wrappers=1 \
"/media/pi/CHANNEL_DRIVE/video.mp4"
The output is evidence about that file, not a guarantee that YouTube will accept it. YouTube's current encoder guidance lists H.264, H.265/HEVC and AV1 for video, and AAC or MP3 for audio. It also recommends constant bitrate encoding and a keyframe interval around two seconds, with the interval not exceeding four seconds. Check the YouTube encoder settings before choosing stream copy.
As listed on YouTube's site in September 2026, its H.264 guidance includes these bitrate figures:
| Source target | Minimum bitrate | Recommended bitrate |
|---|---|---|
| 720p at 30 fps | 3 Mbps | 8 Mbps |
| 720p at 60 fps | 3 Mbps | 8 Mbps |
| 1080p at 30 fps | 5 Mbps | 14 Mbps |
| 1080p at 60 fps | 6 Mbps | 17 Mbps |
These figures describe YouTube's encoder guidance, not the speed available from your internet connection. Your upload connection needs enough sustained capacity for the chosen output, with room for ordinary network variation. YouTube recommends testing the connection and choosing a quality that it can carry reliably.
If the source already has suitable streams, -c:v copy -c:a copy may avoid re-encoding. That reduces the Pi's processing work, but it keeps the source's codec, dimensions, bitrate, frame rate and keyframe structure. It does not turn an arbitrary file into a YouTube-ready stream.
Choose real-time playback and optional looping
FFmpeg normally processes a local file as quickly as it can. That is not what you want for a live feed. The -re input option tells FFmpeg to read the file at approximately its native playback rate rather than sending it as fast as storage and the CPU allow.
For one pass through a file, the basic shape is:
ffmpeg -re \
-i "/media/pi/CHANNEL_DRIVE/video.mp4" \
-c:v copy -c:a copy \
-f flv "rtmps://a.rtmp.youtube.com/live2/STREAM_KEY"
The -f flv output format is used with the RTMP-family publishing workflow. The source path and destination are examples. Replace both with values you have checked.
To repeat the file indefinitely, add -stream_loop -1 before the input:
ffmpeg -re -stream_loop -1 \
-i "/media/pi/CHANNEL_DRIVE/video.mp4" \
-c:v copy -c:a copy \
-f flv "rtmps://a.rtmp.youtube.com/live2/STREAM_KEY"
FFmpeg documents -stream_loop -1 as infinite input looping. A loop is not a schedule, playlist or content transition system. When the file reaches its end, it starts again, which may produce a visible or audible join. Check the first and last seconds of the file before deciding that the repetition is acceptable.
Stream copying is the simplest starting point when the media is already suitable. If YouTube rejects the feed, the audio is absent, the timestamps are problematic or the source uses an unsuitable format, you may need to encode. Encoding uses more CPU than copying, and this guide does not claim that any particular Raspberry Pi model can sustain a chosen resolution or bitrate.
For a file with no audio, YouTube may receive video without an audio stream, or the output may not behave as intended depending on the command and source. A separate approach is described in how to add silence when a video has no audio in an FFmpeg YouTube stream. Test that variation with your own media rather than adding an audio filter without checking the result.
Configure the YouTube ingest destination
In YouTube Studio, create or open the live stream in the Live Control Room and select the encoder workflow. YouTube provides a stream URL and a stream key for the encoder. The key identifies where the feed should be accepted, so treat it like a secret: do not publish it in an article, paste it into a public repository or leave it in a screenshot.
YouTube's live streaming encoder setup guidance explains where to find the connection details. Copy the URL shown for the selected stream rather than assuming every account or workflow displays exactly the same destination.
The illustrative RTMPS destination in the earlier command combines the ingest URL and key in the format expected by many FFmpeg builds. Confirm the exact syntax for your selected YouTube endpoint and confirm that the installed FFmpeg build supports the secure protocol:
ffmpeg -protocols | grep -E 'rtmp|rtmps'
The output of that check depends on how FFmpeg was built on your Pi. The FFmpeg protocol documentation describes the RTMP family and its URL syntax, but your local binary is the one that must perform the connection.
Keep the key out of shell history where practical. If you put the command in a script, restrict the script's permissions and do not share it with the key embedded. If a key is exposed, replace or reset it in YouTube Studio before using the stream again.
A rejected publish attempt can result from an incorrect key, an incorrect destination, a disabled live feature, a protocol mismatch or media that YouTube cannot accept. The stream key and publish errors guide is useful when the command runs but YouTube does not accept the feed.
Start with a controlled test
Do not begin with an overnight broadcast. Start the command while you can watch both the Raspberry Pi terminal and YouTube Studio. Confirm that FFmpeg opens the file, advances through the timestamps and keeps the connection open.
You may see log messages about frame counts, speed, bitrate, timestamps or connection status. With -re, the reported speed should be near normal playback rather than many times faster than real time. A message about a missing file points back to the mount and path. A protocol or connection error points to the URL, key, network, DNS or local FFmpeg support. A media or muxing error points to the source streams or output format.
Use a short test file if you are still validating the command. A short file lets you observe the end-of-file behaviour, and a looped test shows whether the transition back to the beginning is acceptable. For a longer programme, test a section containing the same kind of movement and audio that viewers will receive.
YouTube recommends testing before starting a live stream. In the Live Control Room, watch the preview and the stream health messages rather than relying only on a clean FFmpeg terminal. Check for dropped frames, unstable connection warnings, missing audio, unexpected resolution and a delay between the Pi and the preview.
The upload connection matters continuously. A speed test taken at one moment does not prove that the connection will remain stable during a long broadcast, particularly on a busy home or shared mobile connection. Wired Ethernet may be easier to troubleshoot than a marginal wireless link, but it is not a guarantee of uninterrupted delivery.
Prepare the Pi for a longer run
Once the short test works, make the operating conditions repeatable. Secure the external drive, ensure its cable cannot be knocked loose, and check that the Pi has adequate ventilation. Watch storage errors and system logs if the drive disconnects or the process stops unexpectedly.
Confirm the mount after a reboot. Then run ffprobe against the exact file path again. This catches a common mistake where the desktop mounted the drive under one directory during testing but the unattended setup starts before the drive is mounted or uses a different mount point.
Decide what should happen when FFmpeg exits. A looped input prevents a normal end-of-file exit, but it does not protect against a drive disconnect, power loss, network failure or process crash. A supervisor can restart the process, but automatic restarting should be tested carefully so that it does not create multiple publishers using the same key.
Keep a written record of the working command without the real key. Store the key separately, and note the verified mount path, source filename, selected output settings and the date on which you checked YouTube's guidance. This makes later troubleshooting less dependent on memory.
There is also a maintenance trade-off. Running FFmpeg on your own Pi gives you direct control over the file, command and physical storage, but you remain responsible for power, internet, mounting, process recovery and monitoring. If the main requirement is to upload a file once and avoid leaving a computer or Pi running, StreamNeo removes that specific always-on machine and restart-monitoring task by taking the uploaded file and sending it to YouTube from its cloud service.
A practical pre-flight checklist
Before treating the channel as ready, check each part separately:
- The external drive appears after a reboot and its filesystem is readable.
- The exact media path works from the same user account that will run FFmpeg.
ffprobeshows the expected video and audio streams.- The chosen codecs and stream properties have been compared with YouTube's current encoder guidance.
- The installed FFmpeg build supports the protocol you intend to use.
- The command uses
-refor real-time pacing. -stream_loop -1is present only when repetition is intended.- The stream URL and key belong to the selected YouTube live event.
- The key is not exposed in a public script, screenshot or log.
- A test has confirmed picture, audio, pacing and loop behaviour.
- YouTube Studio shows acceptable stream health during the test.
- You have a plan for drive, power, network or process failure.
If you need a broader design rather than a single Pi command, compare the trade-offs in automating a 24/7 YouTube stream with FFmpeg in India. The reliable choice is the one whose storage, power, network and recovery arrangements you have actually tested.
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
Does this upload the file to YouTube as a normal video?
No. FFmpeg reads the local file and sends a live encoder feed to a YouTube live event. YouTube receives the programme as a broadcast, not as an ordinary video upload added to your library.
Can every external hard drive use the same path on Raspberry Pi?
No. The mount path depends on the operating system, filesystem, drive label and mount configuration. Check it with lsblk, inspect the mounted directories and verify the path again after a reboot.
Should I always use -c:v copy -c:a copy?
Only when the source streams are already suitable for the YouTube ingest settings and the chosen output format. Stream copy avoids re-encoding, but it cannot change codecs, repair timing, alter resolution or fix keyframe spacing. Inspect the file and test the feed before relying on it.
Will -stream_loop -1 guarantee a continuous YouTube broadcast?
No. It repeats the input while FFmpeg remains able to read the drive and publish to YouTube. Power loss, storage errors, network interruption, an unsupported source or a stopped process can still interrupt delivery, so monitor the live event and test any recovery arrangement.