Try it free

← BlogProtocols8 min read

SRT vs RTMP vs WHIP: choosing a live ingest protocol in 2026

Before anyone can watch, the picture has to reach your server. The protocol for that first mile, the ingest, decides how much delay you start with and what happens when the network has a bad second.

RTMP: old, everywhere, and built on TCP

RTMP came from Flash, and outlived it because every encoder, phone app and platform accepts it. It runs over TCP, which guarantees delivery in order. That guarantee is also its weakness on a poor link: one lost packet holds up everything behind it (head-of-line blocking) until it is resent, and the sender's buffer grows. On a long, lossy path, an RTMP stream stalls rather than degrades.

Classic RTMP carries H.264 and AAC only. The Enhanced RTMP extension adds HEVC and AV1, but support across encoders and servers is still uneven.

SRT: UDP with a deadline

Secure Reliable Transport was designed for contribution over the open internet. It runs over UDP and recovers losses itself, with a twist: every packet has a deadline. The receiver holds a fixed latency window; a lost packet is asked for again (ARQ) and resent as long as it can still arrive in time. If it cannot, SRT drops it and moves on, so delay never grows.

How SRT recovers a lost packet inside its latency window The sender transmits packets 1 to 6. Packet 3 is lost. The receiver notices the gap when packet 4 arrives and sends a NAK. The sender retransmits packet 3, which arrives before its play-out deadline, so the receiver releases packets 1 to 6 in order after the fixed latency window. Sender Receiver ✕ 3 lost 1 2 3 4 5 6 NAK 3 3 again latency window (e.g. 4 × round-trip time) released in order: 1 2 3 4 5 6
SRT trades a fixed, known delay for reliability: a lost packet gets as many second chances as fit inside the window, and no more.

The rule of thumb from the SRT community is a latency of three to four times the round-trip time, more on very lossy links. SRT also encrypts with AES, carries any codec in an MPEG transport stream, and can connect in either direction (caller, listener or rendezvous), which helps when the camera sits behind NAT.

WHIP: WebRTC for ingest

WHIP (explained here) sends media as WebRTC. Loss recovery uses NACKs plus the encoder's ability to adapt its bitrate in real time, aimed at the lowest delay of the three. Its killer feature is reach: any browser can publish over WHIP, so a guest, a phone or a laptop needs no software at all.

Side by side

RTMP SRT WHIP
Transport TCP UDP + ARQ UDP (WebRTC)
Added delay Grows on loss Fixed, set by you Lowest
Lossy, long links Poor Excellent Good
Encryption Only as RTMPS AES built in Always (DTLS-SRTP)
Codecs H.264/AAC (more with Enhanced RTMP) Any in MPEG-TS Browser codecs: H.264, VP8/VP9, AV1; Opus
From a browser No No Yes
Encoder support Universal Broadcast hardware, OBS, FFmpeg OBS 30+, FFmpeg 8, browsers

Which one to use

Choosing an ingest protocol If the source is a browser or phone with no app, use WHIP. Otherwise, if the link is long or lossy, such as remote contribution over the internet or cellular, use SRT. Otherwise, if the encoder only offers RTMP, use RTMP. Otherwise prefer SRT for resilience or WHIP for the lowest delay. Source is a browser or phone with no app? Long or lossy link? internet, cellular, abroad Encoder offers only RTMP? WHIP SRT RTMP No → SRT for resilience, WHIP for lowest delay Yes Yes Yes No No
A starting point, not a law: many productions use two, for instance SRT from the venue and WHIP for remote guests.

The good news is that you rarely have to choose only one. A server that accepts all three lets each source use what suits it, and converts them to the same outputs for viewers.

In creekX: a stream can come in over RTMP, SRT, RTSP or WHIP. See OBS and phone apps, encoders over SRT, RTSP and UDP and the browser.

Frequently asked questions

Is SRT better than RTMP?

Over long or lossy internet links, usually yes: SRT runs over UDP and resends lost packets within a fixed latency window, while RTMP over TCP stalls and builds delay. On a clean local network both work well, and RTMP has wider encoder support.

What latency should I set for SRT?

A common rule of thumb is three to four times the round-trip time between encoder and server, more on very lossy links.

Does OBS support WHIP?

Yes, OBS Studio has published over WHIP since version 30.