Streaming

Stream quality: bitrate, bandwidth, buffering and delay

Stream quality comes down to a small number of settings and one honest measurement. Most churches push more than their connection can carry, which produces exactly the stuttering, buffering experience they were trying to avoid.

The one rule

A clean 720p beats a stuttering 1080p, every week.

Viewers barely register resolution — most are watching on a phone — but everyone notices freezing, skipping and buffering. Almost every stream that looks bad is attempting more than its connection can sustain.

Measure your upload honestly

Bitrate is the amount of data per second you send. Your upload speed is what the building can actually carry. Everything else follows from the gap between them.

Test at service time. A Tuesday-afternoon speed test tells you very little: the building is emptiest and the wifi quietest. Test on a Sunday, mid-service, from the machine that streams.

Aim to use about half. If your tested upload is 10 Mbps, stream at around 5,000 kbps. That headroom absorbs the dips — and connections dip, particularly on shared or rural lines.

TargetBitrateUpload needed
720p302,500 – 4,000 kbps~6–8 Mbps
1080p304,000 – 6,000 kbps~10–12 Mbps
1080p606,000 – 9,000 kbps~15 Mbps+

Wired Ethernet for the streaming machine, always. Wifi in a full building competes with two hundred phones, and it is the single most common cause of a stream that was fine in rehearsal.

ImageScreenshot: a speed test run from the streaming computer during a service, showing the upload figure
The number that matters is the one measured while the building is full.

Encoder settings

Use hardware encoding if you have it. NVENC on an NVIDIA card, Quick Sync on Intel graphics, or the AMD equivalent. It moves the work off the processor, which matters because that processor is also running the service.

Keyframe interval of 2 seconds, which is what every platform expects.

Do not chase presets. The difference between encoder quality presets is small compared with getting the bitrate right, and slower presets cost processor time you need elsewhere.

Streaming on a slow connection

Plenty of churches have poor upload and stream anyway. What actually helps:

  • Drop to 720p, or 480p if you must. A watchable low-resolution stream serves people; an unwatchable high-resolution one does not.
  • 30fps, not 60. Halving the frame rate is a large saving for content that is mostly a person talking.
  • Reserve the connection. Ask people not to use the church wifi during the service, or put the streaming machine on its own connection where the router supports it.
  • Consider streaming audio-only as a fallback if video genuinely will not hold. For a sermon, audio that works beats video that does not.
  • Upload the recording afterwards if live is hopeless. Many congregations watch later anyway.

Fixing buffering

Buffering at the viewer's end nearly always starts at yours.

  1. Check dropped framesOBS and vMix both report dropped frames. Any significant number means the connection cannot carry what you are sending.
  2. Lower the bitrateDrop by a third and watch again. This resolves most cases immediately.
  3. Go wiredIf the streaming machine is on wifi, that is very likely the whole problem.
  4. Look for competitionSomeone backing up files, a large download, or the guest network saturating the line during the service.

If dropped frames are zero and viewers still buffer, the problem is at their end or the platform's, and there is little you can do beyond offering a lower quality option — which YouTube does automatically.

Delay, and why you mostly cannot fix it

Streams run 10 to 30 seconds behind the room. That is the platform buffering so playback stays smooth for viewers on imperfect connections.

Low-latency modes exist on most platforms and cut the delay to a few seconds. They trade stability for it: viewers on weaker connections buffer more. For a church service, that is usually a poor trade.

If the delay matters — someone in the room watching the stream to cue something — solve it in the room instead, with a direct feed rather than the public stream. Do not degrade the experience for everyone watching to fix a problem for one person on the platform.

ImageScreenshot: OBS statistics panel showing dropped frames at zero and a stable bitrate during a service
Zero dropped frames is the target, not a high bitrate.

A quality checklist

  • Upload tested during a service, from the streaming machine.
  • Bitrate at roughly half the tested upload.
  • Wired Ethernet, not wifi.
  • Hardware encoding on if available; keyframe interval 2 seconds.
  • Dropped frames checked at the end of every service.

The takeaway

  • Send less than your connection can carry, and it will look better, not worse.
  • Test at service time — the quiet-weekday number is a fiction.
  • Buffering is nearly always your upload; delay is nearly always the platform, and rarely worth fighting.

Add scripture to your stream without adding load to the encoder. Free.

Download TajiCast, free

Related: How to live stream a church service · Troubleshooting livestream problems

Frequently asked questions

What bitrate should a church stream at?
Around 4,000 to 6,000 kbps for 1080p30, and 2,500 to 4,000 for 720p30. Whatever you choose, it should sit at roughly half your tested upload speed so there is headroom for the moments the connection dips.
How much upload speed does a church need to stream?
Roughly double your streaming bitrate. For a 720p stream at 3,000 kbps that means about 6 Mbps of reliable upload; for 1080p at 5,000 kbps, about 10 Mbps. Test it during a service, when the building's wifi is busiest.
Should we stream in 1080p or 720p?
720p if there is any doubt about your connection. Viewers notice stuttering and dropped frames far more than they notice resolution, and most watch on phones where the difference between 720p and 1080p is slight.
Why does our stream keep buffering for viewers?
Usually the upload from the church cannot sustain the bitrate being sent. Lower the bitrate, move the streaming machine to wired Ethernet, and check nothing else in the building is using the connection during the service.
How do we reduce the delay on our stream?
Only a little. Most of the delay is the platform buffering for reliable playback, and low-latency modes trade stability for a few seconds. If the delay matters for something in the room, do not solve it by degrading the stream for everyone watching.

Keep reading