For a 24/7 church worship stream on YouTube, start with progressive 1080p30 H.264, AAC stereo and a two-second keyframe interval, then choose the video bitrate your sustained upload can carry with headroom. A practical bandwidth-conscious starting point is 10 Mbps video; YouTube’s listed H.264 recommendation at this resolution is 14 Mbps, so use that only when the connection can sustain it.
These are general YouTube encoder settings, not India-specific tuning. Your location matters chiefly because the upload available at the actual streaming site can vary with the provider, time of day and other people sharing the connection. Test there rather than relying on a plan’s advertised speed.
A usable 1080p30 starting profile
For a fixed camera showing a church service, 1920×1080 at 30 frames per second is a reasonable first profile. Pair it with H.264 video and AAC-LC stereo audio. H.264 is a broadly supported encoder choice; YouTube also lists other codecs, but those are worth considering only if your FFmpeg build and complete workflow support them and YouTube accepts the incoming stream.
YouTube Help’s current encoder guidance, checked in 2026, lists a 5 Mbps minimum and 14 Mbps recommended video bitrate for H.264 at 1080p30. A 10 Mbps target is a practical compromise within that published range when bandwidth is a concern, but it is not YouTube’s recommended H.264 figure. If you want to match that recommendation, set 14 Mbps and first establish that your upload can carry it with room to spare.
| Profile | Video bitrate guidance | When it may fit |
|---|---|---|
| 1080p30 H.264 | 5 Mbps minimum; 14 Mbps recommended | A suitable choice when the measured upload has headroom for the target and other network use |
| 720p30 H.264 | 3 Mbps minimum; 8 Mbps recommended | A lower-resolution alternative when the connection cannot comfortably sustain the 1080p target |
The bitrate figures in the table are YouTube Help’s general guidance, checked in 2026, not a guarantee of quality or connection stability. The 10 Mbps starting point is an editorial choice, not an official recommendation. At a church with a mostly stationary shot, the difference between 10 and 14 Mbps may not justify the extra network demand; moving musicians, people walking through frame, or a detailed background can make compression more visible. Test with representative movement before choosing.
A file-based command template appears below. It assumes the input is suitable for 1080p30 and that your FFmpeg build includes libx264 and RTMPS support. The ingest address and stream key are placeholders; copy the current values from your channel’s Live Control Room, and do not expose the key in a public script or log.
ffmpeg -stream_loop -1 -re -i worship.mp4 \\
-map 0:v:0 -map 0:a:0 \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-b:v 10M -maxrate 10M -bufsize 20M \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
For YouTube’s recommended 1080p30 H.264 rate, change the three video rate values from 10M to 14M, and make sure the upload can sustain the higher target. This command is an illustrative template, not a tested configuration for every input file or FFmpeg build. Check your local encoder help and documentation if an option is unavailable or behaves differently.
Keep CBR and a two-second keyframe cadence
Use constant bitrate (CBR) as the starting rate-control mode for this live output, with the target and maximum rate aligned. In the example, -b:v sets the target, -maxrate caps the peak and -bufsize sets the rate-control buffer. FFmpeg’s exact behaviour can vary by encoder and build, so check ffmpeg -h encoder=libx264 and local documentation before treating a command copied from another machine as authoritative.
YouTube recommends a keyframe every two seconds and says not to exceed four seconds. At 30 frames per second, -g 60 requests a 60-frame group of pictures, or two seconds. -keyint_min 60 and -sc_threshold 0 in the example aim for a fixed interval rather than extra scene-cut keyframes. A fixed cadence can make stream behaviour easier to reason about, but test the result in YouTube’s preview and health information rather than assuming the encoder has accepted every setting.
A keyframe interval is not the same as the video bitrate. Changing the GOP does not make a weak upload strong, and increasing bitrate does not compensate for a long interval. Keep the interval aligned with YouTube’s guidance, then size bitrate according to the actual connection. For a related explanation of settings that can prevent a stream from being accepted, see the guide to fixing an encoder resolution mismatch.
Set AAC stereo for speech and music
The example encodes AAC stereo at 128 kbps and 44.1 kHz. YouTube’s current encoder guidance lists those figures for stereo audio. The audio settings are appropriate as a starting point for a mixed service containing speech, singing and accompaniment, but they cannot repair a poor feed from the sound desk.
Take a clean stereo output from the church’s mixer or audio interface where possible. Listen for clipping, hum and an imbalance between spoken words and music. Check the whole programme, including quieter prayer or reading sections: a feed that sounds present during a song can appear to disappear when the mix falls near silence. Make a short private or unlisted test and listen back on ordinary phone speakers as well as headphones.
In FFmpeg, -c:a aac selects the AAC encoder, -b:a 128k sets the audio bitrate, -ar 44100 sets the sample rate and -ac 2 requests two channels. The example maps the first audio stream with -map 0:a:0. If the source has no audio track or the wanted mixer feed is a separate input, that mapping needs to change; do not assume the first audio stream is the one you intend to broadcast.
Keep an eye on continuity as well as sound quality. An input cable that is loose, a muted mixer bus or a file with an audio gap can create silence even when FFmpeg reports that it is encoding. A church’s full mix should also be checked for levels and permission to use the material; platform encoder settings do not settle rights questions.
Use progressive SDR and Rec. 709
For standard dynamic range (SDR), use progressive video, square pixels, 8-bit colour and Rec. 709. The example’s -pix_fmt yuv420p selects a widely compatible pixel format, while -r 30 requests 30 frames per second. Confirm that the source and output aspect ratio match. A typical 16:9 camera feed should not be stretched to fill the frame if the source is a different shape; use deliberate cropping or accept appropriate bars instead.
Progressive means each frame represents a complete picture rather than alternating interlaced fields. If the camera file is interlaced, inspect it and decide how to deinterlace it before streaming. Merely labelling interlaced material as progressive can leave comb-like edges around moving hands or people. Likewise, converting a low-resolution or poorly lit source to 1080p does not restore details that were not captured.
Colour handling deserves a test on the actual file. A source recorded with unusual tags or in HDR may not look correct when treated as ordinary SDR. The profile here is for SDR Rec. 709 material; if your source is HDR or uses a different colour space, verify a proper conversion rather than relying on an output flag alone. YouTube’s live encoder settings guidance is the primary reference for its general video and audio recommendations.
Measure sustained upload and keep headroom
Measure outbound capacity at the place and time the stream will run. The number shown on a broadband or mobile plan is not a measurement of what the encoder can use continuously. Wi-Fi contention, a busy mobile cell, other users uploading video, cloud backups and a second stream can all reduce the available capacity. A short speed test can help identify an obvious constraint, but observe the connection over a representative period and repeat at busy times.
YouTube advises leaving 20% upload bandwidth headroom. Its network guidance also says to account for the combined bitrate of primary and backup streams, where used, plus that margin. In practical terms, do not treat a link that briefly reaches the video bitrate as suitable. Leave capacity for audio, protocol overhead, normal variation and unrelated traffic, and consider whether someone in the building will start a large upload during the service.
YouTube’s network and streaming guidance warns that network disruption can interrupt a stream. This is why a private test should include the actual camera movement and worship audio, rather than a static desktop or test clip. Watch for dropped frames, warnings and changes in stream health while other normal users are on the connection.
For a 1080p30 H.264 stream, begin with the 10 Mbps compromise only if the measured sustained upload leaves sensible headroom above it. If you want to use YouTube’s 14 Mbps H.264 recommendation, test for that target instead. Neither 10 Mbps nor 14 Mbps is guaranteed to work on a particular connection, including one located in India. When the upload is shared or variable, a lower profile that remains stable is more useful than a higher one that repeatedly loses its connection.
If the channel’s main concern is reliability rather than maximising resolution, it helps to separate encoder load from network limits. A local machine can struggle to encode while the internet link remains healthy; conversely, a capable computer cannot prevent a congested upload. The practical troubleshooting path is to check both the encoder’s output and YouTube’s stream health. For a continuous channel, the 24/7 devotional FFmpeg walkthrough is a relevant companion for the looping side of the workflow.
Step down to 720p30 when needed
Choose 720p30 when a measured connection cannot comfortably hold the 1080p target with headroom, or when the site’s upload varies enough that the higher profile produces repeated warnings or interruptions. YouTube Help’s current H.264 guidance, checked in 2026, lists 3 Mbps minimum and 8 Mbps recommended for 720p30. The 8 Mbps figure is a recommendation in YouTube’s general table, not a promise that every link capable of that speed will carry a live stream reliably.
For a bandwidth-limited connection, select a rate within YouTube’s range that the sustained upload can support; do not simply set 8 Mbps because it appears in the table. Adjust -b:v and -maxrate together, and set a proportionate -bufsize. You will also need to produce or scale the video to 1280×720, not just lower the bitrate while still sending 1080p. For a straightforward source conversion, test appropriate scaling in your FFmpeg build and inspect the result for aspect ratio and sharpness.
A 720p image can be a sound trade-off for a fixed camera in a modest room, particularly if the most important things to see are the speaker and congregation rather than fine detail. It may be less suitable if text on a projection screen needs to remain readable or the camera covers a wide sanctuary. Compare the same representative scene in a private test; watch faces, on-screen words and movement, not just the resolution label.
Changing resolution also changes the amount of detail the encoder must represent, but it does not cure every cause of failure. If the encoder is overloaded, reducing resolution may help; if the problem is a fluctuating connection, the lower bitrate target may help; if power fails, neither setting will help. The guide on reducing resolution or bitrate after encoder overload can help distinguish those cases.
Send over RTMPS and verify the live setup
Use the current RTMPS ingest address and stream key displayed in the church channel’s YouTube Live Control Room. YouTube recommends RTMPS for ingestion, and FFmpeg documents RTMPS as RTMP carried over a secure SSL connection. The exact address and key are channel-specific, so do not reuse an old value from a note or someone else’s tutorial. Treat the key as a password, limit who can access it and replace it if it is exposed.
The command ends in -f flv because this is the container format commonly used for RTMP-family live output. The RTMPS URL goes in place of rtmps://INGEST_URL/STREAM_KEY. Keep the final URL out of screenshots, shared configuration examples and public logs. You can consult the FFmpeg protocol documentation for protocol details, but your channel’s Live Control Room remains the source for its current ingest information.
Before making a service public, confirm the channel is eligible to stream, create or select the event in YouTube Studio, then run a private or unlisted test. YouTube’s getting started with live streaming page describes current prerequisites; check the current official page because channel conditions can change. In the test, verify preview, stream health, audio continuity, aspect ratio and the intended stream options in the Live Control Room.
For a 24/7 operation, decide who will notice a drop and what they will do about it. Keep a recovery procedure for power, internet and encoder failure, and test that procedure rather than assuming a single FFmpeg process will reconnect indefinitely. YouTube’s guidance cautions that network disruption can break a stream. If a complete archive matters, make a separate local recording where possible; do not assume an indefinitely long live broadcast will leave the archive you need.
If running the encoder on a church computer, that machine needs to stay powered, connected and available for the full broadcast. If the practical problem is that no one can leave a computer running overnight, StreamNeo removes that specific burden: you upload the video, provide the channel’s stream key, and the broadcast can continue with your computer switched off. It is YouTube-only, so this does not change the encoder profile or replace testing the channel and connection.
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 10 Mbps the recommended YouTube bitrate for 1080p30 H.264?
No. YouTube Help’s current guidance, checked in 2026, lists 5 Mbps minimum and 14 Mbps recommended for H.264 at 1080p30. The 10 Mbps value here is a practical starting compromise, not YouTube’s H.264 recommendation, and it is not guaranteed to work on any particular connection.
Are these settings tuned specifically for India?
No. YouTube publishes general encoder guidance by codec, resolution and frame rate, not a separate India profile. Measure the sustained upload at the actual church location and leave headroom, since local network conditions determine which profile is practical.
Should I use 1080p30 or 720p30 for a church service?
Use 1080p30 if your source is suitable and the upload sustains the bitrate you choose with room for variation and other traffic. Step down to 720p30 when the 1080p target cannot be held reliably; check whether text and faces remain clear in a real test.
Does this FFmpeg command guarantee an uninterrupted 24/7 broadcast?
No. A command can encode and send the file, but it cannot guarantee power, internet or platform continuity. Monitor stream health, test recovery steps and keep a separate recording if you need a complete copy.