To loop church sermons on YouTube Live with FFmpeg on a Raspberry Pi 5, use the sermon file as FFmpeg’s input, tell FFmpeg to repeat that input, and send the resulting encoded feed to a scheduled YouTube Live broadcast. The command is only one part of the setup: you also need a secure stream key, a suitable output configuration and a rehearsal using the church’s actual media and network.
This is not the same as replaying an old broadcast from your channel. In a loop-to-live setup, the Pi sends a continuing encoder feed to YouTube; YouTube receives it as a live event. Raspberry Pi’s published H.264 performance information describes an encoding path, but does not validate a particular resolution, frame rate, cooling arrangement or all-day runtime for your church’s setup.
What looping a sermon to YouTube Live means
The basic path is straightforward: a video file is read by FFmpeg, FFmpeg repeats it and sends an output stream to YouTube Live. Viewers see the live broadcast, even though its picture and sound originate from a recording. The event is live in the platform sense; it is not a new live camera or microphone feed from the church.
That distinction matters when planning the service. Repeating a sermon file can keep a channel playing when nobody is available to operate a camera, but it will repeat any silence, title card, mistake or abrupt ending in the source. Check the whole recording, including the beginning and end, and decide whether repeating it without a pause is acceptable. If the loop is intended to run through the night, ask whether viewers should hear the same introduction and closing each time.
A past broadcast replay is different. That means making an earlier YouTube video available again, for example by sharing its watch-page link or using a platform feature where available. It does not mean that FFmpeg is sending a new, continuous encoder feed. With FFmpeg, the media file is the input and the encoder connection is the output; the YouTube event you configure receives that connection.
If you are weighing a sermon video loop against an audio-only programme, the workflow in this guide is closer to configuring FFmpeg to loop an audio playlist for YouTube Live, but video adds encode load and picture checks. For a channel with several recordings, you will also need to decide whether to repeat one complete file or build and test a sequence before sending it.
Prepare the Pi 5 and sermon files
Start with a clean, representative copy of the media you intend to broadcast. Confirm that the file plays from beginning to end on another device, and listen for clipped speech, long pauses, uneven volume and audio that drifts out of sync. Check the picture for blank sections, unexpected aspect ratio changes and captions or slides that may be difficult to read on a phone. FFmpeg can repeat a faulty file just as faithfully as a good one.
Keep the source file in a known directory on the Raspberry Pi 5 and use a simple filename without shell-special characters. A path such as /home/pi/sermons/sunday-service.mp4 is easier to quote correctly than a filename with spaces and punctuation. Make sure the Pi can read the entire file before relying on it for a service. If you move or replace the media later, run the same test again; a new file may have different streams, dimensions, audio channels or timing.
Install FFmpeg using the package method appropriate to the Pi’s operating system, then check that the command is available and consult the documentation for the installed version. FFmpeg’s official documentation describes its options and formats, but options and behaviour can differ by version and input. Do not paste a command from an old forum post without checking what each option does on your installation.
Also decide where the Pi will sit and how you will reach it if the stream stops. The board, power, storage, network connection and operating conditions are part of the real test environment, not details that can be assumed from a published encoding example. Raspberry Pi’s H.264 encoding performance paper discusses software encoding on Raspberry Pi 5-series computers. It is useful background, not proof that your chosen output settings, cooling arrangement or uninterrupted operating period will work.
Create the YouTube Live broadcast
In YouTube Studio, create or schedule the live event and select the encoder workflow. The exact controls can change, so follow the current Studio prompts and current YouTube encoder settings guidance. The broadcast event is where you set details such as title, visibility and audience options; the encoder sends the audio and video. Creating the event does not by itself start the feed from FFmpeg.
Use a test event or an appropriately controlled scheduled event while setting up. Check the intended visibility before sending a test to viewers. Once the event and encoder settings are ready, YouTube Studio will provide the connection details, including the stream key. Treat those details as credentials. Do not include the key in a screenshot, public chat, shared notes or a command copied into a public forum.
Make a note of the event’s status and how you will tell whether YouTube is receiving a healthy feed. YouTube Studio’s stream health and warning messages matter alongside FFmpeg’s local output. A process that continues running on the Pi does not necessarily mean viewers are receiving a usable stream: the network could be interrupted, the output could be rejected, or the picture or sound could be wrong.
If you have not used YouTube’s encoder workflow before, use the platform’s current instructions rather than relying on a remembered sequence of buttons. You can separately review YouTube Creator resources for channel-side learning, but keep the technical connection details grounded in the live event and official encoder documentation.
Configure FFmpeg to repeat media and send the feed
The key idea is to apply an input repetition option to the file before describing the output. FFmpeg’s -stream_loop -1 is commonly used to repeat an input indefinitely. In a simplified command, the structure is:
ffmpeg -stream_loop -1 -re -i /home/pi/sermons/sunday-service.mp4 \
-c:v libx264 -b:v 3M -maxrate 3M -bufsize 6M \
-g 60 -c:a aac -b:a 128k \
-f flv "rtmps://YOUR_INGEST_ADDRESS/YOUR_STREAM_KEY"
Treat this as a structural example, not a universal command to paste into production. The sample video and audio rates, GOP value, codec availability, timing and RTMPS address must be checked against YouTube’s current settings, the actual source and the installed FFmpeg build. In particular, the example’s keyframe value assumes a particular frame rate; a keyframe interval is time-based in YouTube’s guidance, so derive the corresponding encoder setting from the output you choose rather than copying -g 60 blindly. If FFmpeg reports that an encoder or option is unavailable, stop and resolve that before a live service.
The -stream_loop -1 option tells FFmpeg to keep reading the input again after it reaches the end. The -re option paces file reading closer to real time, which is generally important when a file is being used as a simulated live source; verify its use against the installed version and your workflow. Input options need to appear in the right place relative to the input they affect. The official FFmpeg documentation is the reference for syntax and option scope.
Choose the output based on the actual video and the connection you can sustain. YouTube’s encoder guidance lists H.264, H.265/HEVC and AV1 video support, as well as AAC or MP3 audio, and recommends constant bitrate. For H.264 it gives 5 Mbps for 1080p30 and 3 Mbps for 720p30. These are recommendations for those output profiles, not evidence that a Raspberry Pi 5 in your building can encode them continuously or that your internet connection can deliver them reliably.
| H.264 output example | YouTube recommended video bitrate | What to verify locally |
|---|---|---|
| 1080p30 | 5 Mbps | Whether the Pi sustains the selected encode and the upload has dependable headroom |
| 720p30 | 3 Mbps | Whether this output suits the source and remains stable on the church connection |
For either profile, YouTube recommends a two-second keyframe interval and says it should not exceed four seconds. Align the output’s frame rate and keyframe configuration with the current official encoder guidance. Do not infer from the table that one setting is automatically better: a lower output may suit an older or lower-resolution source, while a larger output requires the Pi to encode and the network to carry more data. Your representative test should decide, not a generic command.
The output destination combines the ingest address and the event’s stream key. Keep placeholders in any saved example and insert the actual details only in a private, controlled setting. If your source file already uses a suitable codec and format, it may be possible to avoid some re-encoding, but that depends on the media and YouTube’s accepted input. Confirm the result in a test rather than assuming that copying streams is appropriate.
Use RTMPS and protect the stream key
YouTube recommends RTMPS for secure delivery. The protocol encrypts the connection between encoder and YouTube; it does not make a leaked stream key harmless. Google’s YouTube Live ingestion protocol comparison and RTMPS delivery guide explain the supported ingestion choices. Use the current connection details supplied for your event and follow YouTube’s current instructions.
A stream key is effectively a credential for sending to the event. Avoid placing it in a command that you later share, in a public script repository or in a screenshot of your terminal. Consider who can read the account or device used to run FFmpeg, and avoid leaving the key in a broadly accessible file. If you think it has been exposed, replace or reset it through YouTube Studio and update the local configuration.
The sample command above deliberately uses placeholders. A private command line may still be visible in shell history or process listings depending on how you launch and manage it. Plan how you will store and enter the key before the event, and test the exact private method with a non-public rehearsal. Do not trade away key protection to make the command shorter.
Test output, heat and stability with your media
A brief test that shows a picture is not enough. Use the same sermon recording, Pi, power arrangement, network location and output profile planned for the service. YouTube advises testing with audio and movement similar to the intended stream and monitoring stream health; a static slide or silent clip will not reveal the same problems as a sermon with speech, transitions and moving images.
Listen across a loop boundary. Does the sound cut off, pause, jump in loudness or restart in an awkward place? Watch the last frames and the first frames after the file repeats. If the video ends with a long black screen or a final prayer followed by an abrupt opening title, decide whether to edit the source or accept that transition. Check the stream from a separate viewer connection as well as the Pi’s local output. A correct preview on the encoding device is not the same as a reliable viewer experience.
Observe the Pi while it performs the chosen encode. Check for encoder warnings, missed output, unexpected throttling or signs that the system is struggling, and note the conditions under which they appear. The Raspberry Pi performance paper cannot certify your resolution, frame rate, cooling or all-day runtime. The church’s own media and installation determine what is dependable. If the device becomes unstable, change one variable at a time, such as output profile or source format, and repeat the test so you know what helped.
Test the actual upload path at the church, not only on a faster connection elsewhere. Leave enough upload capacity for a stable feed rather than choosing a video bitrate that consumes all available upstream bandwidth. Other people and devices may use the connection during a service, so test under realistic conditions where practical. YouTube Studio’s stream health messages can help identify connection or encoder issues; keep a record of warnings and when they occurred.
A rehearsal should run long enough to expose the risks you care about. If the service depends on the stream continuing for many hours, test for a comparable operating period before depending on it, without treating that rehearsal as a guarantee of future performance. A test cannot prove every day will be the same: network conditions, temperature, source files and power can change. For a broader view of connection failures and diagnosis, see why a 24/7 YouTube Live stream may disconnect.
Plan monitoring and recovery
Decide who will notice a problem and what they can do. During a service, assign someone to check YouTube Studio’s stream health and the viewer-facing output at intervals that make sense for the event. Keep the Pi reachable, and write down the steps for checking the FFmpeg process, confirming the network and restarting the encoder if needed. A running terminal is not a monitoring plan if nobody knows where it is or what an error means.
If the connection drops, first distinguish an encoder failure from an internet or YouTube event issue. Read FFmpeg’s error output, check the network and review Studio’s status messages. Restarting blindly can hide a recurring cause or create a new event instead of reconnecting to the intended one. Rehearse the recovery steps while the stream is not serving a congregation, and confirm how YouTube handles a reconnect for the event you created.
Keep a fallback that fits the church’s circumstances. That might mean a person ready to communicate that the online service is unavailable, a separate recording to share later or an alternative programme, but make sure the fallback does not expose account credentials or confuse viewers with an unintended duplicate event. If uninterrupted operation without someone beside the Pi is more important than running FFmpeg locally, compare that requirement with a cloud-based workflow: StreamNeo removes the need to keep the church’s computer running by letting you upload a video and connect it to your YouTube channel for an ongoing broadcast.
Finally, document the working media version, FFmpeg command structure without the secret key, chosen output settings, test observations and recovery procedure. Re-test after changing the sermon file, software, network or output configuration. For a channel with regional programming and scheduled changes, the planning questions in scheduling regional music for a 24/7 YouTube radio stream in India can help you think through what should play and when, though a sermon loop still needs its own file and service checks.
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 -stream_loop -1 replay my previous YouTube broadcast?
No. It repeats the input file being read by FFmpeg, then sends that repeated media as an encoder feed to a YouTube Live event. Replaying a past broadcast on your channel is a separate action and does not require this looped encoder workflow.
Can I use the sample command unchanged?
No. It illustrates the parts of the workflow, but the bitrate, keyframe interval, codecs, source path and ingest details need to match your file, FFmpeg build and chosen YouTube output. Confirm settings on YouTube’s current encoder page and test the complete setup before a service.
Is the Raspberry Pi 5 proven to run my sermon stream all day?
The cited Raspberry Pi paper discusses H.264 software encoding performance, but it does not establish that your specific resolution, frame rate, cooling arrangement or all-day workload will succeed. Run a representative rehearsal with the actual media and installation, monitor the device and YouTube stream health, and plan a recovery route.
What should I check if viewers report a problem?
Compare what viewers see and hear with FFmpeg output and YouTube Studio’s stream health messages. Check for an upload interruption, an encoder warning, an audio problem or an awkward repeat boundary, then change one factor and test again. Keep the stream key private while investigating.