SRT vs RTMP vs WHIP: which ingest should you use?

RTMP and RTMPS: the default that is usually right

RTMP has been the standard contribution protocol for well over a decade, which means every encoder, every appliance and every phone app speaks it. It runs over TCP, so lost packets are retransmitted by the operating system, and on a stable wired connection that is entirely sufficient.

Its weakness is how it behaves when the path degrades. TCP recovery was designed for file transfer rather than for a live picture, so a congested route produces growing delay and then a stall, instead of a brief recoverable blemish. On a good circuit you will never see this. On a bad one you will see nothing else.

Prefer RTMPS, the TLS-wrapped variant, whenever it is offered. There is no reason to publish a stream key in the clear.

SRT: built for a path you do not control

SRT sends over UDP and does its own selective retransmission inside a time budget you set. Instead of the all-or-nothing behaviour of a TCP stall, it recovers what it can within the buffer window and delivers the rest on time. A lossy route degrades gracefully rather than falling over.

Two values control that behaviour, and both are per-stream and adjustable while the stream is running. Receiver latency is how long the buffer will wait for a retransmission before giving up on a packet — a longer window survives a worse route at the cost of more delay. Reorder tolerance governs how far out of sequence packets may arrive before they are treated as lost.

Being able to widen the buffer live is the part that matters operationally. If a route deteriorates partway through a long event, you widen the window and carry on; nothing has to be torn down and rebuilt.

The practical rule: cellular, bonded modems, hotel connections, public venue circuits and anything crossing a long distance want SRT. A wired drop in your own building does not need it.

WHIP: publishing straight from a browser

WHIP is WebRTC contribution, and its distinguishing feature is that the sender needs no software. A browser tab is the encoder. That is what makes guest links and phone contribution work for people who will never install anything, and it is the lowest-friction way to get a human on screen.

The trade is control. A browser gives you far fewer knobs than a hardware encoder, and quality tracks whatever the sender’s device and connection happen to be doing. For a remote guest that is the right trade every time. For your main camera it usually is not.

A quick way to choose

If a person is joining your show, use a link and let them publish from the browser. If a machine is sending your main programme over a connection you own and trust, RTMPS is simple and fine. If a machine is sending over a connection you do not control, use SRT and set the receiver latency for the route rather than for the ideal case.