For a pre-recorded church service on YouTube Live, start with H.264 video, constant bitrate (CBR), a two-second keyframe interval and AAC stereo audio. For a 1080p30 source, YouTube recommends 14 Mbps; for 720p30, it recommends 8 Mbps. These are live-ingest recommendations, not settings for encoding the file you upload.
The word “loop” describes what your playback or encoder workflow does with the file. YouTube’s encoder guidance covers what the stream sends to YouTube and how to check it; it does not define a universal loop control. You still need to test the complete playback cycle, including the end-to-start transition, before relying on it for a service.
A practical baseline for a prerecorded service
Treat these values as a starting point, not a mandatory church preset. Match the encoder to the media you actually have and to a sustained upload connection that can carry the stream with room to spare. A mostly static view of a pulpit does not require a different YouTube specification from another live stream; the service’s slides, faces, movement and audio simply affect what viewers need to see and hear clearly.
| Setting | Starting point | What to check |
|---|---|---|
| Ingest protocol | RTMPS, where supported | Use the secure extension YouTube recommends and enter the stream URL and key only in the chosen encoder. |
| Video codec | H.264 | Use the codec-specific live bitrate guidance below. YouTube also lists H.265/HEVC and AV1. |
| Rate control | CBR | Keep the outgoing live video rate steady rather than relying on variable peaks. |
| Video target | 1080p30 at 14 Mbps, or 720p30 at 8 Mbps | Choose based on source detail and stable upload capacity, not by upscaling a smaller file. |
| Frame rate | Match the source, up to 60 fps | Do not convert a 25 or 30 fps source to a higher rate without a reason. |
| Keyframes | Every 2 seconds | YouTube recommends this interval and says not to exceed 4 seconds. |
| Audio | AAC stereo, 44.1 kHz, 128 kbps | Listen to speech, music and transitions in the test stream. |
| SDR picture | Progressive, square pixels, Rec. 709, 8-bit | These are YouTube’s advanced recommendations for SDR. |
The full live-ingest specification is in YouTube’s live encoder settings. The table is about the signal sent during a live broadcast. The file’s upload export is a separate decision, so do not copy an upload-encoding recommendation into the live encoder without checking which workflow it describes.
If your service uses a single camera shot and occasional slides, H.264 at 1080p30 is a straightforward baseline when the source and connection support it. If the file is 720p or the connection cannot sustain 1080p reliably, 720p30 is a sensible fallback. The goal is a stable, legible service, not the largest resolution number in the settings panel.
Choose resolution and bitrate for source and connection
YouTube’s H.264 live recommendations vary with resolution and frame rate. Values below are Mbps; they describe the outgoing live stream, not the uploaded file.
| Resolution and frame rate | H.264 recommended bitrate | AV1 or H.265 recommended bitrate |
|---|---|---|
| 1080p60 | 17 | 12 |
| 1080p30 | 14 | 10 |
| 720p60 | 8 | 6 |
| 720p30 | 8 | 6 |
| 480p30 | 4 | 3 |
| 360p30 | 4 | 3 |
Source: YouTube’s live encoder guidance. Codec availability and support in your specific playback and encoding workflow matter too; the lower bitrate in a codec column is not by itself a reason to switch codecs.
A useful comparison is the detail your congregation needs against the source and upload path you can maintain. At 1080p, faces and lyric text can be easier to read than at 720p, but a 1080p stream is not automatically better if the original recording is 720p or the connection struggles at the higher target. Upscaling cannot restore detail that was not in the source. For a service with small on-screen lyrics or scripture references, inspect the actual frame on a phone as well as a larger screen.
YouTube recommends leaving 20% upload-bandwidth headroom. As a simple calculation, 14 Mbps video plus 128 kbps audio, with that headroom, calls for roughly 17.7 Mbps of stable capacity for the stream alone. That figure is arithmetic from YouTube’s recommended bitrate and headroom, not a separate published threshold. Other people or devices using the same connection need additional room. A speed-test peak is not proof that the connection will sustain the same throughput throughout a service.
If you repeatedly see dropped frames or stream-health warnings at 1080p, do not keep the resolution just because the source is full HD. Test at 720p30 and check whether the stream becomes stable while remaining readable. Conversely, if the network can sustain the recommended 1080p target and the source contains useful detail, there is little reason to lower it pre-emptively. Keep notes on the settings that worked in a test under realistic network use.
Set RTMPS, H.264, CBR and keyframes
Select RTMPS if your encoder offers it for YouTube. It is YouTube’s recommended secure extension to RTMP. The encoder also needs the correct YouTube stream URL and stream key. Keep the key private: anyone with access to it may be able to send a broadcast to the event. YouTube explains stream setup and key handling in its live stream settings guide.
For the baseline here, select H.264 and constant bitrate control. CBR is useful because it gives the live encoder a target rate to hold rather than allowing bitrate to swing with each scene. It does not compensate for a weak upload connection, a busy local network or a playback process that has stopped. If the source file itself is encoded at a different rate, that does not change the live output target you set in the encoder.
Set the keyframe interval to two seconds. YouTube’s guidance recommends two seconds and says not to go beyond four seconds. If the encoder expresses the interval in frames rather than seconds, use the frame-rate setting to convert it correctly; for example, the frame count for a two-second interval differs at 30 fps and 60 fps. Check the encoder’s own field label before entering a value, as some interfaces ask for seconds and others for frames.
Use the source frame rate where possible. If your recording is 30 fps, a 30 fps live output avoids creating extra frames without adding captured motion. YouTube allows up to 60 fps, but that does not mean every service should use 60 fps. A sermon recording or static sanctuary view may not benefit enough to justify the higher bitrate requirement shown in the table.
The loop is a separate layer from these ingest parameters. The player or encoder must be configured to replay the media; YouTube’s live encoder page does not explain how any particular software repeats a file. If your workflow changes files or inserts a slate between services, read the specific playback tool’s documentation and test that behaviour instead of assuming a YouTube setting will handle it.
Configure AAC stereo audio
Set the live audio output to AAC stereo at 44.1 kHz and 128 kbps, YouTube’s listed starting point. Stereo is suitable for a typical service mix with speech, music and room sound. Check the result with headphones and on a phone speaker: a mix that sounds balanced in the control room can make spoken words hard to follow on a small device.
Listen to the start, middle and end of the source and to the transition back to its beginning. Confirm that the pastor’s voice is clear over music, that no channel is missing, and that the first seconds after the loop restarts do not begin abruptly or at an unexpectedly different level. If the recording contains silence, a fade or a music bed at its end, decide whether that is intentional for the service rather than discovering it during the event.
YouTube also lists MP3 as an audio option, but AAC is the recommended baseline here. Its documentation notes that for RTMP/RTMPS, 5.1 audio is supported only with AAC. Unless the service has a deliberate multichannel production and a tested playback path, stereo is simpler to verify and more likely to translate predictably across ordinary devices.
These are live stream audio settings, distinct from the export settings used to prepare the original recording. If audio sounds distorted or clipped in the source file, changing the live bitrate will not repair it. Correct the source mix if needed, then test the actual stream output. For a deeper comparison of live audio decisions, see this guide to YouTube live audio bitrate for a continuous stream.
Test the complete loop and its transition
A test that plays only the first minute can miss the failure that matters most: playback reaching the end and not returning to the beginning. Run the media through a complete cycle using the actual playback and encoder workflow you intend to use. Watch or listen through the end, the transition, and the first moments after restart. Check for a frozen frame, a pause, black video, duplicated audio, silence, a sudden volume jump or an encoder that stops when the file ends.
YouTube recommends testing before starting a live stream. The full-cycle check is additional workflow advice: the platform’s encoder specification does not prescribe a universal method for looping recorded media. If your selected software offers a repeat or playlist option, test that exact option. If it relies on an external playback device, test that device and the handoff it makes to the encoder. This is why a file suitability check for a continuous YouTube stream can be useful before you schedule a service.
Make the test representative. Use the full-resolution file, the intended audio mix, any opening or closing slate, and the same network path. A short sample may be useful for checking basic picture and sound, but it cannot establish that the end-to-start handoff works. Where the service recording is long, at minimum let the playback reach its actual end once before relying on an unattended run.
Check that the loop is appropriate for the event as well as technically functional. A repeated closing prayer or announcement may feel accidental; a transition that cuts in the middle of a sentence may confuse viewers. Decide whether the service should replay immediately, include a short holding slide, or move to another prepared item. That choice belongs to your content and playback workflow, not to YouTube’s ingest settings.
If you use OBS or another encoder for scene changes, overlays or transitions, practise those separately from the file-repeat behaviour. One useful reference is this guide to soft transitions between videos in an OBS live stream. Do not assume a scene transition also tells the media player to restart a file; verify each part of the chain.
Preview and verify access before the event
Set up the event and encoder well before the scheduled service. YouTube recommends having the encoder ready at least two hours ahead and starting it at least 15 minutes before the scheduled event. That window gives you time to notice a key mismatch, correct a resolution choice or resolve an access problem without making the congregation wait while you troubleshoot.
Start the encoder and check the event in Live Control Room. Wait for the preview to appear, then inspect picture, audio and any stream-health warnings. The preview confirms that YouTube is receiving a signal; it does not alone confirm that a viewer can find or open the event. Check the channel or watch page where people will actually arrive, and open it on a mobile device using the intended account or an ordinary viewer account as appropriate.
Verify the event’s visibility and access settings before sharing the link. Check that the correct event is scheduled, that the title and thumbnail are recognisable, and that the audience can reach the watch page. If the page is unlisted, for example, a viewer generally needs the direct link rather than relying on the channel page. Do not infer public access from the fact that you can see the event while signed in as its owner.
A mobile check catches practical problems that a desktop preview may not: a title cut off on a small screen, tiny lyrics, an unexpected sign-in prompt, or audio that is too quiet through a phone speaker. If you have someone helping, ask them to open the link independently and report what they can actually see. This is a test of the viewer route, not a promise about how YouTube will distribute or recommend the event.
Keep the stream key out of public notes, screenshots and shared messages. If you think it has been exposed, replace it in YouTube Studio and update the encoder before the service. YouTube’s live setup instructions cover creating and managing a live stream. Follow the current official instructions because YouTube’s interface and available event options can change.
Monitor stream health, picture and sound
During the service, watch Live Control Room for stream-health changes and warnings. Also check the actual programme periodically: a green status indicator cannot tell you whether a hymn has become inaudible, a slide is unreadable or the file has reached an unexpected section. If someone can monitor the viewer page on another device, they can catch issues that are hard to hear or see from the encoder position.
If the stream reports dropped frames or instability, first check whether another device or task is using upload capacity. YouTube recommends leaving 20% headroom; do not use a momentary speed-test result as a guarantee of sustained bandwidth. If needed, lower the live output to a bitrate and resolution your connection can maintain, then verify that the picture is still legible. Avoid changing several encoder controls at once, because it becomes harder to identify which change helped.
If the stream is healthy but viewers report missing sound, check both the encoder’s audio meters and the playback source. Confirm the intended audio device and AAC output are selected, and listen again to the affected section. If only a particular part of the recording is silent, the defect may be in the source rather than in the live connection. Keep an eye on the transition too: it can expose a playback failure even while the ingest connection remains healthy.
For an unattended channel, monitoring also means knowing what to do if the stream drops. Keep the event, encoder and stream key details available to the person responsible, and decide in advance whether they should restart the encoder, switch to a prepared fallback, or end the event. A watchdog or restart mechanism can help with some failure modes, but it cannot judge whether the right service file is playing. The practical distinction is covered in monitoring FFmpeg stream progress with a watchdog script.
Latency is the delay between capture or encoding and viewer playback. For a prerecorded service loop, immediate back-and-forth with viewers is usually less important than stable playback, so do not choose a lower-latency mode without considering its buffering trade-off. YouTube notes that lower latency may increase buffering. If viewers need to pause and rewind, review DVR behaviour and the current event settings before the service rather than assuming every latency choice behaves the same way.
A cloud-based workflow can remove the need to keep a local computer running through an extended broadcast; StreamNeo addresses that specific operational burden by turning an uploaded video into a YouTube live stream that continues with your computer switched off. It does not change the need to prepare the file, check the loop behaviour and verify the event on YouTube before relying on it.
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
What bitrate should I use for a 1080p church livestream?
For H.264 at 1080p30, YouTube recommends 14 Mbps for live ingest. Your upload connection must sustain that rate with headroom, and the source should genuinely be 1080p; otherwise test 720p30 at the recommended 8 Mbps instead.
Does YouTube loop a prerecorded service file automatically?
YouTube’s encoder guidance specifies how to send a live stream, not a universal way to repeat a file. Looping depends on the playback or encoder tool you choose, so test the complete cycle and its transition using that tool before the event.
Should I use 1080p60 for a church service?
Only if the source is 60 fps, the added motion detail is useful, and the connection can sustain the corresponding bitrate. For a mostly static service recording, matching a 30 fps source at 1080p30 or 720p30 is often a more practical test target.
What should I check just before the service starts?
Confirm the Live Control Room preview, stream-health status, audio and the full-loop transition. Then open the channel or watch page and verify access on a mobile device; YouTube recommends starting the encoder at least 15 minutes before the scheduled event.