A Raspberry Pi can send a prerecorded video to YouTube Live and repeat that file with FFmpeg. The basic chain is local video file, FFmpeg encoder, YouTube ingest URL and stream key, then YouTube Live Control Room.
Looping the file only controls what FFmpeg reads. It does not guarantee that the Pi, network connection, FFmpeg process or YouTube broadcast will remain connected, so test the complete chain before leaving it unattended.
What looping a video actually means
A normal FFmpeg file command reads from the beginning to the end of a video and then exits. The -stream_loop -1 input option tells FFmpeg to open the input again after it reaches the end. The -1 means that the input should be repeated indefinitely.
That loop happens before YouTube receives the stream. YouTube does not receive a playlist of separate videos in this arrangement. It receives one continuous encoder feed, and the repeated sections appear as part of that feed.
The distinction matters when troubleshooting. If the picture repeats but the broadcast stops, the loop is working and another part of the chain has failed. The Pi may have lost its network connection, the FFmpeg process may have exited, the source file may have caused a decoding error, or YouTube may no longer be receiving acceptable data.
The loop also does not remove transitions. If the final frame and first frame differ sharply, viewers will see that change every time the file restarts. For a devotional, ambience or study channel, check the join in advance. A short fade or a deliberately matching start and end can make the repeat less distracting.
If you are deciding whether a single repeating file is suitable for your channel, compare it with the workflow in how to set up a YouTube playlist loop. A playlist can offer more variety, while a local FFmpeg loop gives you direct control over one file and the encoder running on your own equipment.
Prepare the Raspberry Pi and source file
Use the Raspberry Pi model, operating system, FFmpeg build and network connection that you intend to use for the real broadcast. Do not test on a desktop computer and assume the Pi will behave identically. The Pi may have less processing headroom, different codec support and a different network path.
Install or confirm FFmpeg using the package method appropriate for your Raspberry Pi operating system. Then check the installed version:
ffmpeg -version
FFmpeg options and available encoders depend on the installed build. The FFmpeg documentation explains the distinction between input options, stream copying and encoding. Check the local help output as well as an online example if a command behaves differently from what you expect.
Keep the source file on local storage rather than relying on a mounted network folder during the first test. A file that pauses because the storage device or network share is slow can look like an internet streaming fault.
Before you stream, inspect the file. You need to know its duration, video codec, audio codec, frame rate, dimensions, audio channels and whether it contains more than one audio or video track. ffprobe, which is commonly distributed with FFmpeg, can show this information:
ffprobe -hide_banner "input.mp4"
A source that is already suitable for the intended output may be sent with stream copy. In that case FFmpeg copies the existing audio and video packets rather than decoding and encoding them again. This reduces CPU work, but it gives you less control over the output and only works when the streams are compatible with the selected output container and YouTube ingest requirements.
A source that needs a different codec, size, frame rate or bitrate must be re-encoded. Re-encoding can make the output more predictable, but it uses substantially more CPU than copying. On a Raspberry Pi, that difference can decide whether the test succeeds. Raspberry Pi documentation can help you understand the board and operating system, but it does not establish that every Pi model can encode every resolution and frame rate for a long-running FFmpeg stream. The Raspberry Pi documentation is useful background; your own board and file remain the test.
For a first attempt, choose a source with ordinary dimensions, a steady frame rate and a single intended audio track. Avoid adding scaling, filters and several audio transformations until the basic file loop is working. Every extra operation creates another possible failure point.
You should also check the upload connection from the location where the Pi will run. YouTube's encoder settings guidance provides current codec, bitrate and keyframe recommendations. Those recommendations describe the receiving platform, not the capacity of your particular broadband connection. Leave room between your measured upload capacity and the selected stream bitrate rather than treating the connection's headline speed as a guarantee.
Create the YouTube Live stream and protect its key
In YouTube Studio, open Create, choose Go Live, and create or select the stream. YouTube will provide an ingest server URL and a stream key for the encoder. The exact labels can change as YouTube updates Studio, so use the current YouTube Help instructions for going live when the screen differs from this description.
The server URL identifies where the encoder should send data. The stream key authorises that encoder to send data to the selected channel. Treat the key like a password. Do not place it in a public article, screenshot, video description, shared chat or public code repository.
Store it only where the FFmpeg process can use it. Be aware that a command containing the key may be visible in shell history or process listings, depending on how you start it and which tools you use. Restrict access to the Pi account, avoid copying the full command into a shared support forum, and replace the key in YouTube Studio if you believe it has been exposed.
YouTube's workflow may show a preview before you start the broadcast, particularly when you schedule an event or use the Live Control Room. Starting FFmpeg is not always the same as making the stream publicly visible. Confirm the state shown in Studio and follow the current workflow for the type of broadcast you created.
Write down the non-secret parts of your setup: the input filename, chosen resolution, target frame rate, bitrate, whether you are copying or encoding, and the date of the test. Keep the stream key out of that record. This makes a later recovery easier without turning your notes into another copy of the credential.
Connect FFmpeg to the YouTube ingest endpoint
The connection has four moving parts: read the file, pace it in real time, loop it, and publish the resulting stream to YouTube. A conceptual stream-copy command looks like this:
ffmpeg -re -stream_loop -1 -i "input.mp4" \
-c:v copy -c:a copy -f flv "<YouTube RTMPS ingest URL>/<STREAM_KEY>"
This is a shape to understand, not a universal command to paste unchanged. Replace the input filename and the endpoint details supplied by YouTube, and keep the key private. Confirm that the URL format shown in YouTube Studio matches the way your installed FFmpeg build accepts it.
-re asks FFmpeg to read the file at approximately its native media rate instead of sending the file as quickly as the Pi can read it. Without real-time pacing, a file can be consumed faster than it should be for a live encoder workflow. -stream_loop -1 belongs before the corresponding -i, because it is an input option.
-c:v copy and -c:a copy request stream copying. They do not convert an unsuitable source into a suitable one. A file with incompatible codecs, timestamps, audio layout or container assumptions may fail, produce an unsuitable output, or behave badly at the loop boundary.
If stream copy is not appropriate, use explicit video and audio encoding settings supported by the installed FFmpeg build and compatible with YouTube's current guidance. A transcoding command has to define more than a codec name in many real setups: output dimensions, frame rate, bitrate, keyframe behaviour, audio bitrate and handling for the source tracks may all matter.
YouTube currently lists H.264, H.265 and AV1 video for its RTMP and RTMPS ingest guidance, along with AAC or MP3 audio. Its H.264 recommendations include 5 Mbps minimum and 14 Mbps recommended for 1080p at 30 fps, 6 Mbps minimum and 17 Mbps recommended for 1080p at 60 fps, and 3 Mbps minimum and 8 Mbps recommended for 720p at 30 fps. These are platform recommendations, not a promise that a Raspberry Pi can encode the setting or that your connection can sustain it.
For stereo AAC or MP3 audio, YouTube lists 128 kbps in its encoder guidance. It also recommends constant bitrate encoding and a keyframe interval of two seconds, which should not exceed four seconds. If your file is being copied, you may not be able to change those properties without re-encoding. That is one reason to test the actual output rather than relying on the source file's extension.
RTMPS is the sensible default when YouTube provides it and your FFmpeg build supports it. YouTube describes RTMPS as the secure extension of RTMP. HLS ingest exists, but it involves segmented files and playlist rules and generally has higher latency, so it adds complexity to this basic Raspberry Pi workflow.
Configure the loop and test it first
Start with a private or otherwise controlled test rather than the broadcast that viewers depend on. The aim is to prove four separate things:
- FFmpeg can open and read the file.
- The selected copy or encoding mode works on this Pi.
- The Pi can upload the output at the chosen settings.
- YouTube receives both moving video and usable sound.
Watch the FFmpeg terminal output from the beginning. It should identify the input streams, the selected output mapping and any warnings. Do not ignore repeated decoding errors, timestamp warnings, buffer messages or an unexpectedly high processing load simply because a preview appears.
Open Live Control Room and check the preview and stream-health indicators. Play the stream as a viewer as well, preferably from another device or connection. A preview can look acceptable while the public playback has muted audio, repeated buffering or a delay that is not obvious from the encoder terminal.
Let the test run through the end of the source file and into the next pass. This is the part that a short launch test often misses. Watch for a frozen picture, a brief black frame, audio disappearing, an FFmpeg exit, a timestamp problem or a sudden rise in CPU use. The source may loop correctly but still create a problem at the boundary if its timestamps or streams are unusual.
Check the process load while the test is running. If you are re-encoding, observe CPU temperature, throttling and memory pressure as well as CPU percentage. A command that works for a few minutes can still be unsuitable if the board becomes hot or the operating system starts terminating processes under pressure.
Test the exact resolution, frame rate, audio layout and bitrate that you plan to use. Changing those after the test can alter both CPU demand and upload demand. If the source is already compatible, stream copy is a useful first comparison. If the output needs predictable properties, test a re-encoded version separately rather than mixing both approaches in one troubleshooting session.
For channels with a dark or static visual style, include representative movement and sound in the test. This is particularly important for devotional slides, nature ambience and local information loops, where a silent or nearly still opening can conceal a missing audio track or a stalled video stream.
The guide to making video files smaller for a YouTube 24/7 stream may help if your file is too demanding for the Pi or the available upload connection. Smaller output is not automatically better, but reducing unnecessary dimensions or bitrate can make the whole chain easier to sustain.
Check stream health and viewer playback
Use YouTube's health indicators as a second source of evidence, not as a replacement for watching the encoder. Look for warnings about the incoming bitrate, format, connection or missing audio. Compare the reported information with the settings you intended to send.
Then check playback at the loop boundary. Note the exact time at which the source restarts and watch for a discontinuity. If the stream stops at the same point every time, inspect the source file and FFmpeg output. If it stops at unpredictable times, investigate the network, power, storage and process supervision instead.
Audio deserves its own check. Confirm that the audio meter moves in Studio, that the viewer device is not muted, and that the source has the intended track selected. A video can appear healthy while sending no audio because the file has multiple tracks, an unsupported layout or an incorrect mapping.
YouTube archives streams under 12 hours automatically according to its current Help guidance. Do not assume that the same outcome applies to a longer broadcast. If an archive matters to your channel, check the current official guidance and plan the broadcast lifecycle accordingly.
A looped broadcast also does not solve content or channel policy questions. If you reuse music, devotional recordings, news footage or other material, check the rights and YouTube's current policy information for your situation. A working technical connection is not evidence that the material is cleared for every use.
If you are troubleshooting a visual interruption between files, the advice in how to prevent black screens between gaming videos is relevant to the same viewer-facing problem, even though this guide uses one local file rather than a playlist.
Plan for failures and recovery
A Raspberry Pi running FFmpeg is an encoder, not a complete reliability plan. The file loop can continue only while the process is alive, the storage is readable, the Pi has power and the network path can reach YouTube.
Create a simple recovery plan before the first unattended run. Decide who will receive an alert, how often the stream will be checked, where the Pi is located, and how you will reconnect after a power cut. A small uninterruptible power supply may help with brief interruptions, but it does not make a long outage harmless and should be selected for the actual equipment.
Use process supervision only after the foreground command is reliable. A service manager or restart policy can relaunch FFmpeg after a clean process exit, but it cannot repair a bad source file, an exposed key, a failed storage device or an internet connection that is unavailable. Automatic restart can also create repeated failed attempts, so keep logs and inspect the reason for each exit.
Do not let two encoder processes send to the same stream accidentally. During recovery, confirm which process is running before starting another one. If you change the stream key, update the stored configuration and test again. The recovery guide for a YouTube livestream after changing its stream key covers the credential-change situation in more detail.
Keep a second copy of the source file and a written record of the non-secret settings. If the Pi's storage fails, recovery is faster when you do not have to reconstruct the file, command and YouTube Studio configuration at the same time.
For an operation where you do not want a local computer to remain powered, StreamNeo removes the need to keep this FFmpeg process running on your Pi by taking an uploaded video and sending it to your YouTube channel from the cloud, with monitoring and automatic restart when the broadcast drops. It remains YouTube-only, and you should still test the file, channel and viewer experience before relying on the stream.
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 MP4 on YouTube Live with FFmpeg?
No. The .mp4 extension does not tell you whether the codecs, timestamps, audio tracks and output settings are suitable for YouTube ingest. Inspect the file and test stream copy first, then re-encode if the source needs different output properties.
What does -stream_loop -1 do?
It tells FFmpeg to repeat the input indefinitely. It affects the file-reading stage, not the internet connection or YouTube broadcast lifecycle. Place it before the related -i input and confirm the behaviour with the FFmpeg version installed on your Pi.
Is a Raspberry Pi enough for a 24/7 stream?
That depends on the model, source file, encoding method, resolution, frame rate, temperature, storage, power and upload connection. Stream copying may use less CPU than re-encoding, but it is less flexible. Test the exact setup through at least one complete file transition before making it an unattended broadcast.
Why did the video loop but the YouTube stream stop?
The local loop can continue while FFmpeg loses its connection, exits because of an input or encoding error, or is stopped by a power, heat or operating-system problem. Check the FFmpeg logs, YouTube stream health, Pi resource use and network connection separately. A restart policy may assist recovery, but it cannot correct the underlying fault.