Is SRT better than RTMP for church live streaming?

For reliability, yes, and it is not close. RTMP runs on TCP, so a lost packet stalls everything behind it — that is the freezing and buffering churches see on a congested uplink. SRT re-requests only what went missing and hides the repair inside a buffer you control. Both look identical to your viewers when the network is good; SRT is what keeps them identical when it is not. RTMP is still a perfectly reasonable choice on a solid wired connection.

Is SRT really limited to 8 seconds of protection?

Partly. We tested this rather than argue about it. The protocol’s real ceiling is 65,535 ms — about 65 seconds — because the SRT handshake carries the buffer size in a 16-bit millisecond field, and that is the largest number it can hold. But the 8-second figure in comparison charts is fair for hardware: a Magewell Ultra Encode tops out at exactly 8,000 ms, and an ATEM or an AJA HELO Plus has no latency setting at all. If you stream from OBS you can set 60 seconds; if you stream from a box, 8 seconds or the default is what you get, and both still recover packet loss that RTMP cannot.

What SRT latency should a church use?

In OBS, 60 seconds — written on the URL as latency=60000000, because OBS counts in microseconds. On a Magewell, 8000 ms, the top of its dropdown. On an ATEM or an AJA HELO Plus there is no setting to change. Do not enter 90 seconds anywhere: we measured that request being negotiated down to 24.5 seconds, because anything above 65,535 ms wraps around silently. A worship service loses nothing by running a minute behind real time, so where you can buy protection with delay, buy it.

Does a bigger buffer make my stream worse for viewers?

No. It means the stream runs slightly further behind real time. That matters for a two-way interview or an auction; it does not matter for a service. PealCast deliberately does not chase low latency for exactly this reason — we would rather spend a delay nobody notices to buy a stream that never freezes.

Does a big SRT buffer protect us if the internet drops completely?

No, and this surprises people. We tested it by killing the uplink mid-stream: with a 60-second buffer negotiated, a 4-second blackout was ridden out perfectly and a 7-second one ended the session. That is SRT’s peer-idle timeout — about five seconds of complete silence and the connection is declared dead, whatever the buffer says. The buffer protects against loss and congestion on a line that is still passing traffic. For a line that stops entirely, what saves your service is the encoder reconnecting automatically — or a store-and-forward system like Resi’s, which is genuinely built for that case.

Is Resi RSP better than SRT?

For one specific failure it genuinely is. RSP stores the service on the encoder and can hold up to 30 minutes, so a complete internet outage is caught up afterwards rather than ending the broadcast. An SRT buffer cannot do that — it protects for as long as the buffer and no further. For the far more common problems, congestion and packet loss, a well-configured SRT stream and RSP both simply work, and one of them is free and open.

Can I use BoxCast Flow or Resi RSP with another platform?

No. Both are proprietary protocols that exist between that company’s own encoders and that company’s cloud. That is not a criticism — it is how they can guarantee behaviour end to end — but it does mean the reliability you paid for does not travel with you. SRT and RTMP do, because anyone can implement them.

Does PealCast support SRT?

Yes, and it is what we recommend. Every PealCast channel gets both an SRT address and an RTMPS address, so any encoder works — OBS, a Blackmagic ATEM, a Magewell or AJA box, or a simulcast destination from BoxCast, Resi or Restream. We give you the SRT string with the stream ID and passphrase already in it, and our setup guide tells you exactly which buffer to set.

What is the single best change if our stream keeps freezing?

Switch from RTMP to SRT if you have not already — that is the big one. Then turn on auto-reconnect with the shortest retry delay and unlimited retries, and raise the SRT buffer if your encoder exposes it. If it still freezes, lower the bitrate — never the resolution — until it holds, and check whether the stream is sharing the building’s Wi-Fi with everyone’s phones. Note that the buffer only hides loss on a line that is still up: a line that goes fully dead ends the SRT session after about five seconds regardless, which is why the reconnect settings matter as much as the buffer.

Streaming protocol comparison

SRT vs RTMP vs
BoxCast Flow vs Resi RSP

Four ways to get video out of your building, compared honestly — and the free setting that fixes most of the freezing churches put up with.

See the head-to-head Get the most out of SRT →

The short answer

Use SRT if your encoder has it. It repairs the packet loss that makes a service freeze on a busy church network, it costs nothing, and it works on hardware you already own. If your encoder lets you raise the buffer, raise it — 60 seconds in OBS, 8,000 ms on a Magewell. Many hardware encoders have no such setting, and they are still fine.

RTMP is fine on a good wired line and works everywhere — it just has nothing to fall back on when the network stumbles. BoxCast Flow and Resi RSP are both good, and both are proprietary: they exist only between that company’s encoder and that company’s cloud. Flow is broadly the same family of ideas as SRT with the buffer turned up. RSP is the genuinely different one — it stores your service on the encoder, so a complete internet outage is caught up afterwards instead of ending the broadcast.

So the real question is not which protocol is best. It is whether your building loses the internet entirely (buy Resi) or merely gets congested like everyone else’s (raise your SRT buffer and keep your money).

The head-to-head

Every cell is what that option actually does, including where it beats the one we recommend.

	RTMP / RTMPS The universal default	SRT Open · what we recommend	BoxCast Flow Proprietary	Resi RSP Proprietary
What it is	The Flash-era protocol from 2002. Everything speaks it, which is the entire reason it is still here.	Secure Reliable Transport — built by Haivision, open-sourced in 2017, now maintained by the SRT Alliance. Free for anyone to implement.	BoxCast’s patented transport, engineered into their own encoders and app.	Resi’s patented Resilient Streaming Protocol, engineered into their own hardware.
Who can use it	Everyone. Every encoder, every platform.	Everyone. Every modern encoder and a growing list of platforms, including PealCast.	BoxCast customers, using the BoxCaster, Spark, Pro or their Broadcaster app.	Resi customers, using Resi’s Mini or server-grade encoders, or ProPresenter Stream.
How it moves the video	TCP — one ordered pipe.	UDP, with the protocol re-requesting only the packets that go missing (ARQ).	Both at once: UDP for flow, TCP to re-send what is missing, plus forward error correction.	Store-and-forward: the encoder writes the service to local storage first, then uploads it.
What happens when packets drop	TCP stops the line to re-send. On a congested church uplink that is exactly what you see as freezing, buffering, or a dropped stream.	Lost packets are re-requested and slotted back in, invisibly — as long as they arrive inside the buffer you set.	Missing data is re-sent over TCP while the stream keeps flowing over UDP; error correction repairs some loss with no round-trip at all.	Nothing is lost, because it was already written to disk. When the connection returns, the encoder sends what it held and the cloud picks up exactly where it stopped.
Protection window	0 seconds. There is no buffer to fall back on.	Up to 65,535 ms — about 65 seconds — and that is a hard protocol ceiling, not a vendor limit. We measured it. Most hardware encoders expose far less, or nothing at all.	About 2 seconds by default; BoxCast documents raising it to 15 seconds, or as far as 90.	Up to 30 minutes of cached service.
Survives a dead line for	Not at all.	About 5 seconds, whatever the buffer says — an SRT session ends after that much silence. Then your encoder has to redial.	Not published. Flow keeps a buffer the same way SRT does, so expect the same kind of limit.	Up to 30 minutes. It is not buffering the line, it is recording to disk and uploading late.
Survives a total internet outage	No. The stream ends.	Only for as long as your buffer — 60 seconds covers the blips, not a cut line.	For as long as the buffer you configured.	Yes, and this is the honest reason churches buy Resi. A long outage catches up afterwards instead of ending the service.
The trade-off	None to configure, and nothing to fall back on.	Your stream runs a little behind real time. For worship that costs nothing.	Same trade: more buffer, more delay.	Your broadcast runs behind real time and, after an outage, keeps running behind. Everything arrives; it arrives later.
Encryption	Only as RTMPS, wrapped in TLS.	AES-128/256 built into the protocol itself, plus a passphrase on the stream.	BoxCast describes built-in obfuscation on the wire.	Encrypted upload into Resi’s cloud.
Ties you to a vendor	No.	No. It is an open protocol — your encoder can point at anyone who accepts it.	Yes. Flow only exists between BoxCast’s encoders and BoxCast. (BoxCast does accept third-party encoders over RTMP and SRT.)	Yes. RSP only exists between Resi’s hardware and Resi.
What it costs	Free.	Free. It is already in OBS and in every hardware encoder we recommend.	Included with a BoxCast plan and their hardware.	Included with a Resi plan and their hardware — the highest entry cost of the four.

Compiled from each vendor’s own published documentation and the protocol specifications, August 2026. Vendors change their products — check the current details with them directly.

How each one survives a bad Sunday

RTMP

No protection

RTMP rides on TCP, which guarantees every packet arrives in order. That sounds like reliability and is the opposite of it for live video: when one packet goes missing, everything behind it waits. A moment of Wi-Fi congestion becomes a visible stall, and a longer one ends the stream. RTMP is not a bad protocol — it is a 2002 protocol doing a job nobody designed it for.

SRT

What we recommend

SRT sends over UDP and keeps a buffer at the receiving end. If a packet goes missing it is re-requested and dropped back into place before the viewer ever reaches it. How much trouble that hides depends on the size of the buffer, which on some encoders is a number you set and on many is simply the 120 ms default. Haivision’s rule of thumb is at least four times your round-trip time — a fraction of a second for a church — so even the default has room to work, and the ceiling if you can reach it is 65,535 ms.

BoxCast Flow

Proprietary

Flow uses two transports at once — UDP to keep moving and TCP to re-send what went missing — with forward error correction repairing some loss without asking for anything back, and adaptive bitrate dropping quality rather than the stream when the uplink narrows. It is a genuinely good design, and it is the same family of ideas as SRT with the buffer turned up. The catch is that it only exists between BoxCast’s encoders and BoxCast.

Resi RSP

The strongest protection

RSP is the different one. Instead of protecting packets in flight, it writes the service to storage in the room and uploads from there, holding as much as 30 minutes. If the internet disappears entirely, the encoder keeps recording and sends the backlog when the line returns. Nothing else here can do that, and if your building genuinely loses connectivity mid-service, that is worth paying for.

Getting the most out of SRT

Comparison charts — including Resi’s own — list SRT’s protection at 8 seconds against RSP’s 30 minutes. We went and measured it rather than argue about it, streaming into our own platform at every setting from 2 seconds upward and reading back what the protocol actually agreed to. Three things came out of it, and one of them corrected our own advice.

The real ceiling is 65,535 ms — about 65 seconds. Not a vendor limit: the SRT handshake carries this number in a 16-bit millisecond field, so that is simply the largest value it can express. Every SRT encoder and every SRT destination on earth shares it.

Above that, it wraps silently. We asked for 90 seconds and the connection came back holding 24.5 seconds — the request minus 65,536, with nothing reported anywhere. This page used to recommend 90 seconds, and that was wrong: it bought less protection than asking for 60. We now say 60 seconds, and the same test ran identically against a plain local SRT listener with no Cloudflare involved, so this is the protocol, not our platform.

And 8 seconds is a fair number for hardware. A Magewell Ultra Encode tops out at exactly 8,000 ms; an ATEM and an AJA HELO Plus have no latency field at all and run the 120 ms default. So if your encoder is a box rather than a computer, the chart is not far off — which is worth saying plainly, because it is the chart of a company we compete with.

0 seconds: RTMP. Any packet loss is visible immediately.
120 ms: SRT’s default, and what most hardware encoders run because they expose no setting. Still enough to repair ordinary packet loss — this is why SRT beats RTMP even untouched.
8,000 ms: The most a Magewell Ultra Encode will offer, and the number Resi’s comparison chart uses for SRT. Fair for hardware; it is not the protocol’s limit.
60 seconds: What we now ask for in OBS (latency=60000000). Comfortably inside the ceiling, and it covers sustained congestion on a stretched church uplink.
65,535 ms: ⛔ The hard ceiling for every SRT encoder and every destination. The handshake carries this number in a 16-bit millisecond field, so 65,535 is as high as it can be expressed.
90 seconds: ⚠️ Does not exist. Ask for it and the value wraps: we measured a 90-second request being negotiated down to 24.5 seconds, with nothing warning you. It is worse than asking for 60.
30 minutes: Resi RSP’s cache — a different mechanism entirely, and the one thing on this page no SRT buffer can match.

Turn your buffer up in four steps

Check whether your encoder has the setting at all

OBS puts it on the SRT URL. A Magewell Ultra Encode has a dropdown. An ATEM or an AJA HELO Plus has no latency field — nothing to change, and nothing wrong with that.

In OBS, add latency=60000000 to your PealCast SRT URL

That is 60 seconds, written in microseconds, which is the unit OBS expects. Never enter 90000000: values above 65,535 ms wrap around, and you end up with about 24 seconds.

On hardware, pick the highest number the box offers

On a Magewell that is 8000 ms, from a fixed list that defaults to 120. If your encoder has no such field, skip this step.

Then set auto-reconnect — this is the one that saves a service

Shortest retry delay, unlimited retries. A buffer hides packet loss, but a line that goes fully dead ends the SRT session in about five seconds no matter what you set, and only redialling brings it back.

All encoder settings OBS step-by-step

Where each one genuinely wins

Buy Resi if your internet actually fails

Not "is slow" or "gets congested" — fails. If your building drops offline mid-service, or you are pushing services out to several campuses, RSP’s store-and-forward does something no buffer can, and Resi has built a serious business on doing it well.

Flow is a fine reason to stay on BoxCast

If you already own a BoxCaster, Flow is doing real work for you and there is nothing to fix. Worth knowing: BoxCast also accepts third-party encoders over RTMP and SRT, so you are not locked to their hardware to use their platform.

SRT is the right answer for most churches

It is free, it is already in your encoder, it recovers from the loss and congestion that cause almost every church stream problem, and it points anywhere you like. Where you can raise the buffer, you have bought most of what the paid protocols sell, for nothing — and where you cannot, the default still beats RTMP comfortably.

RTMP is still fine on a good wired line

On a solid, wired connection with headroom, RTMP works perfectly well and is the simplest thing to set up. We accept RTMPS on every channel and your viewers cannot tell the difference. If it has never let you down, it may never need to.

The question none of these protocols answer

Pick any of the four and Sunday ends the same way. The stream held, the dashboard says a few hundred people watched, and you cannot name one of them. That is not a flaw in a transport protocol — moving video is all any of them claims to do.

PealCast takes your feed over SRT or RTMPS, from the encoder you already own — including a simulcast out of BoxCast or Resi while you try us. Then it does the part the protocol never could: each person watching connects once with a verified mobile number, and every week your team gets two short lists — who is new, and who has quietly stopped watching. Names and numbers, not a viewer count.

Start free See the weekly report

Keep reading

Stream setup guide Best encoders BoxCast vs Resi BoxCast alternative Resi alternative

Protocol questions churches ask

Any protocol. Any encoder. Finally, a name for every viewer.

Start free, point your SRT or RTMP feed at PealCast, and get your first weekly follow-up list.

Start free Talk to us

30 days free · no card · cancel anytime.

SRT vs RTMP vs BoxCast Flow vs Resi RSP