To prepare and loop videos for an always-on YouTube stream on a Raspberry Pi, check the file first, choose an ingest profile YouTube accepts, then use FFmpeg to send it repeatedly at real-time speed. A live loop is an encoder transmitting to YouTube Live; it is not the same as uploading a finished video or simply playing a file on the Pi.
The practical question is: how do you prepare and loop videos for an always-on YouTube stream on a Raspberry Pi without assuming the board can handle every file or run indefinitely? The answer is to test the exact file, command and connection you intend to leave running.
Prepare the file for continuous playback
Start with the material, not the command. Confirm that you have permission to stream the video and audio, and that the file contains exactly what viewers should see. Play it from beginning to end on a normal player. Check picture, sound level, opening and ending, and any black frames or silence that would become conspicuous when the loop restarts. Rights questions depend on your circumstances; check them rather than treating a technical setup as permission.
Record the media’s resolution, frame rate, video and audio codecs, and duration. These details help you decide whether FFmpeg can pass the streams through unchanged or must convert them. For example, a prepared 720p file with a frame rate and codecs that suit your intended YouTube output may not need another video encode. Conversion adds work for the Pi and can introduce a failure point, so do not re-encode simply because a streaming tutorial contains an encoding command.
A file that plays well locally still needs a live-compatible output. Local playback means a player reads the file for a screen or speaker. Uploading a finished video sends a file to YouTube for on-demand playback. Live ingest means an encoder sends a timed stream to a YouTube server over RTMP or RTMPS. The distinction matters: an uploaded video does not become a live broadcast just because it repeats on your computer.
Look for an ending that can meet the beginning without an abrupt jump in image or sound. If the programme has a spoken introduction and a long devotional or ambience section, a cut at an unsuitable moment may sound worse after every repeat. A representative test should include the transition, not just a short middle section. For a scheduled playlist with multiple items, the workflow differs; see the Google Sheets and Apps Script playlist approach.
Check Raspberry Pi and FFmpeg capabilities
There is no safe universal claim that every Raspberry Pi can encode every resolution or sustain every workload around the clock. The result depends on the exact board, cooling and power conditions, FFmpeg build, source codecs, output settings and whether video is being re-encoded. First establish what is installed and what the file requires; then test under the same conditions you expect in operation.
Raspberry Pi’s camera documentation notes that Pi 5 uses software video encoders. It also describes a low-latency option for its camera utility, with a small coding-efficiency trade-off. That information is useful context about the platform, but it is not a benchmark for FFmpeg looping prerecorded files: rpicam-vid is a camera capture tool. You still need to test your own file and command on your own Pi. Read the Raspberry Pi camera documentation for its stated camera-encoding details.
Check which FFmpeg build you are using and whether it includes the encoders and muxers your intended output needs. A command that works on one installation may fail on another because the build options differ. If you are unfamiliar with your install, note the FFmpeg version and inspect its available encoders before planning a conversion. Do not infer hardware encoding support from the board name alone.
Consider two paths. If the file already has a suitable video and audio stream, stream-copying those streams may avoid the video encoding load; compatibility and container handling still need checking. If the file needs resizing, a frame-rate change, or codec conversion, choose settings deliberately and test whether that Pi can keep pace. The available official guidance does not establish model-by-model FFmpeg throughput for this task.
Choose a compatible YouTube Live output
YouTube’s current encoder guidance lists RTMP/RTMPS ingest and H.264, H.265 or AV1 video options, with AAC or MP3 audio. It calls for constant bitrate encoding and recommends a two-second keyframe interval, not exceeding four seconds. For a straightforward H.264 SDR profile, YouTube recommends 8 Mbps at 720p30 and 14 Mbps at 1080p30. These are YouTube’s recommended settings, not evidence that a particular Pi or internet connection can sustain them. Check the YouTube encoder settings and bitrate guidance.
| H.264 output choice | YouTube recommended video bitrate | What to weigh |
|---|---|---|
| 720p30 | 8 Mbps | Lower detail than 1080p, with a lower recommended video bitrate to test against your upload capacity. |
| 1080p30 | 14 Mbps | More picture detail, but a higher recommended bitrate and potentially more work if the Pi must encode. |
YouTube also recommends 128 Kbps stereo audio and a 44.1 kHz stereo sample rate in its advanced settings. Use these as a starting profile, not a promise of compatibility with every file or output path. If your file already has suitable audio, avoid unnecessary conversion until you have a reason to change it. If it does need conversion, make sure your FFmpeg build has the required encoder and include that conversion in the full test.
Your target must fit both ends of the connection: the Pi must produce it and the internet connection must upload it steadily. YouTube recommends checking upload capacity and testing with representative content. If your scene is mostly static, also include motion in the test; motion can make weaknesses less obvious when you watch a still frame. A 24/7 fireplace stream guide offers a different content example, but its settings should not be assumed to fit your file or board.
Loop the input file with FFmpeg
FFmpeg provides an input loop option. Its -stream_loop -1 setting requests an infinite loop for the input. Input-specific options belong before the corresponding input file argument, so the loop option goes before -i. This is important: placing an input option after the file can change how FFmpeg interprets the command.
A schematic command might begin like this:
ffmpeg -stream_loop -1 -re -i "/path/to/video.mp4" \
[video and audio handling options] \
-f flv "rtmps://[server-url]/[stream-key]"
This is a shape, not a universal copy-and-paste command. The bracketed options are deliberately placeholders: the correct mapping and encoding settings depend on the file, FFmpeg build and chosen output. The destination shown is also a placeholder. Obtain the actual server URL and stream key from YouTube Live Control Room, and never share the key in screenshots, public notes or a support post. FFmpeg documents both input looping and real-time input options.
If the file is suitable for direct stream copy, the eventual command may map and copy its existing streams; if it needs conversion, it must select compatible encoders and output parameters. Do not take a command written for a different codec or Pi as proof that your setup will work. Start with a short controlled test, inspect FFmpeg’s output for errors, and confirm that YouTube receives a usable preview.
YouTube’s setup flow is separate from FFmpeg. In Live Control Room, create or select the stream, then copy the server URL and stream key into your encoder configuration. Start FFmpeg and wait for YouTube’s preview before using the Live Control Room’s Go Live control in a scheduled workflow. See YouTube’s instructions for creating a live stream with an encoder. The encoder sending data and the broadcast being live to viewers are related steps, not the same action.
Pace playback at the file’s frame rate
A local file can be read as quickly as storage and decoding allow. For a live output, that is not normally what you want: FFmpeg could process a file faster than its intended duration. The -re option tells FFmpeg to read an input at its native frame rate, which is useful when sending a file as live output. Like the loop option, it belongs before the input it applies to: -re -i "video.mp4", not after the input argument.
Putting the two options together before -i means FFmpeg asks for the file to repeat and paces reads in real time. This does not magically make an overloaded encoder keep up. If the Pi cannot decode, convert and transmit the selected output on time, pacing can expose the problem rather than cure it. Watch for late frames, growing delay, or errors in FFmpeg’s progress output and YouTube’s health messages.
Avoid adding -re indiscriminately to every input. FFmpeg’s documentation cautions about use with actual live inputs; here the intended input is a prerecorded file. If your workflow combines multiple sources, understand which input each option governs. Read the option documentation and test a command that reflects your actual file arrangement, particularly when audio comes from a separate file.
For an always-on channel, keep the distinction between looping and pacing clear. Looping determines what FFmpeg reads after the file ends. Pacing determines how quickly it reads frames from the file. Neither guarantees that YouTube will retain one broadcast forever or that a network interruption will heal without intervention. For a broader preflight routine, use the 24/7 stream pre-flight checks.
Test the stream and monitor health
Do not leave the Pi unattended after only checking that FFmpeg started. Run a representative test with picture motion, audio, and at least one file loop transition. Confirm that the preview appears in Live Control Room, audio is present, the picture is stable, and the stream-health status does not report a problem. YouTube explicitly recommends testing before a live stream and monitoring stream health during it.
Test the intended output bitrate against the actual upload connection. A speed test is useful, but it does not replace a representative test stream: network conditions and the Pi’s encoding load can differ from a brief test. Keep other upload-heavy activity out of the test where practical, and observe whether the connection remains steady. If it does not, lower the target or reduce the workload, then repeat the test.
Watch both ends. On the Pi, look for FFmpeg errors, CPU pressure, throttling or a process that exits. In Live Control Room, check the preview, audio and health messages. The YouTube RTMP health warning guide can help interpret ingest symptoms, but start with the exact warning shown rather than guessing from a dropped frame.
Plan for the broadcast lifecycle as well as the file loop. YouTube states that streams under 12 hours are automatically archived; the cited guidance does not establish what happens to longer broadcasts. Do not promise yourself a single uninterrupted, endlessly archived live event. If archive behaviour matters, consult the current YouTube guidance and decide whether planned session restarts suit the channel. Continuous encoder transmission and YouTube’s broadcast lifecycle are separate concerns.
Troubleshoot playback and encoder limits
If the preview never appears, first check that the server URL and stream key belong to the selected YouTube stream, and that the key was copied accurately. Confirm the Pi has a network route to the ingest destination and that FFmpeg’s output format and codecs match the command you intended. Keep the key private while checking configuration; do not paste it into a public error report.
If the video plays too quickly, check that -re is before the file input. If it stops after one pass, confirm that -stream_loop -1 is also before that input and has not been placed after -i. If the loop stutters at the join, inspect the file’s start and end and consider editing a more natural join rather than expecting FFmpeg’s loop option to smooth a hard cut.
If the Pi falls behind during conversion, try the simplest relevant change first: test a lower output resolution or frame rate, or prepare a compatible file in advance so the Pi has less work to do. A pre-converted file is not automatically better; verify its playback, audio and output compatibility. If direct stream copy is possible, test it against the actual YouTube preview. There is no model-independent threshold that says a given Pi will sustain a given conversion workload.
If YouTube reports unstable stream health, check upload stability and the selected bitrate before changing several encoder settings at once. YouTube’s 720p30 and 1080p30 figures are recommended H.264 starting points, not minimums or a guarantee. Make one controlled adjustment, then repeat a test with motion and audio. This makes it easier to identify whether the limitation is encoding, media compatibility, network capacity or ingest configuration.
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
Is looping a video file the same as uploading it to YouTube?
No. An upload creates an on-demand video, while a live loop uses an encoder such as FFmpeg to send timed media to YouTube Live. Playing a file locally does neither by itself.
Where do -stream_loop and -re go?
For a file input, put both before that input’s -i argument, for example -stream_loop -1 -re -i "video.mp4". The loop option repeats the input; -re paces file reading at its native frame rate. Check FFmpeg’s documentation for details and test your full command.
Can a Raspberry Pi run any file as a 24/7 stream?
No general guarantee applies to every Pi model, file and FFmpeg build. Whether the setup can keep pace depends on the workload and connection, so test the intended media and output on the target board before relying on it.
Does one YouTube live broadcast run and archive forever?
Do not assume so. YouTube documents automatic archiving for streams under 12 hours, but the cited guidance does not explain the outcome for longer broadcasts. Check current YouTube instructions and plan your broadcast lifecycle accordingly.