Livestream Bitrate Chart

Seven profiles covering everything a church would reasonably stream. The upload column already includes the two times headroom multiple, so it is the number to compare against a measured speed test.

Multi-streaming from the building multiplies the upload requirement by the number of destinations, because each one receives its own copy. This is where most church connections actually run out.

Relevant for churches on metered connections, rural fixed wireless, or a cellular backup link. Figures assume two services of 90 minutes plus an hour of rehearsal each week.

Almost nobody watches a church stream on a screen where 4K is visible. The realistic audience is on a phone, a tablet or a laptop, frequently with the video in a small window inside a social feed. At those sizes 1080p is indistinguishable from 4K, and on a phone even 720p is often enough. Meanwhile 4K at 30 fps needs more than three times the upload and more than three times the data.

Bitrate matters more than resolution anyway. A 1080p stream at 4,500 kbps looks considerably better than a 4K stream squeezed into the same bandwidth, because the encoder has enough bits to handle motion without blocking. If your stream looks soft or breaks up during fast movement, the answer is more bitrate at the current resolution, not more pixels.

The things that actually improve a church stream are cheap. In rough order: better audio, better lighting on the platform, a stable camera position, and a clean feed from the console rather than a camera microphone. Audio is the one people notice first and the one churches under-invest in most. A dedicated audio feed through an interface such as the Scarlett 2i2 or a capture path through the Cam Link 4K costs a fraction of a camera upgrade and improves the stream far more.

Lighting beats camera specification. A modest camera in a well lit room produces a better image than an expensive camera in a dim one, because every camera raises gain in low light and gain is noise. Before upgrading a PTZ camera to a 4K model, light the platform properly.

Upload is not download, and the advertised figure is not the measured one. Every number here is compared against a measured upload speed, taken on a wired connection, at the time of day the service actually runs. A church testing on a Tuesday morning over Wi-Fi and reading the download figure has learned nothing useful.

Consistency matters more than peak speed. A connection that averages 50 Mbps but drops to 2 Mbps for ten seconds during a service produces a visible stall, while a rock steady 15 Mbps does not. Cable and fixed wireless connections in particular vary with neighbourhood load, which peaks at exactly the times churches meet.

It says nothing about the local network. Plenty of streams fail inside the building rather than at the internet connection, because the encoder is on congested Wi-Fi, or sharing a switch with the office, or competing with a hundred phones joining the guest network. Put the streaming machine on a wired connection and, ideally, on its own network segment.

Platform limits override these numbers. Streaming services publish their own maximum ingest bitrates and re-encode anything above them, so sending more than a platform accepts wastes upload for no quality gain. Check the current guidance for each destination.

Latency is a separate problem. None of these figures address the delay between the room and the viewer, which is typically 10 to 30 seconds and matters if a church runs interactive elements. Lower latency modes exist and generally cost some quality or stability.