Choose RTMP (Real-Time Messaging Protocol) when a platform or content delivery network ingests RTMP and your uplink is stable. Choose SRT (Secure Reliable Transport) when a hardware encoder must cross a lossy public network. Choose WHIP (WebRTC-HTTP Ingestion Protocol) when a browser or OBS Studio feeds a WebRTC session. Put a gateway between them when sources differ.
RTMP vs SRT frames the first-mile question: which protocol carries a live stream from the encoder to the server that receives it. WHIP now belongs in the same comparison, because it lets a browser or OBS Studio push WebRTC (Web Real-Time Communication) media with one HTTP request. This guide, for developers choosing what an ingest endpoint accepts or an encoder sends, compares the three against their defining documents and ends with a decision rule. It covers ingest only; delivery to viewers, for example over HLS (HTTP Live Streaming), is a separate choice.
RTMP vs SRT vs WHIP at a glance
The table compares RTMP vs SRT vs WHIP as each ingest protocol's defining document describes it.
| Attribute | RTMP | SRT | WHIP |
|---|---|---|---|
| Defining document | Adobe memo (December 2012) plus Enhanced RTMP v2 (January 2026 revision) | Expired individual IETF (Internet Engineering Task Force) Internet-Draft, never an RFC | RFC 9725, IETF Standards Track, March 2025 |
| Transport | TCP | UDP (User Datagram Protocol) | HTTP for setup, then ICE and DTLS-SRTP for media |
| Loss handling | TCP retransmits; later data waits | Retransmits within a latency window, drops late packets | Left to the WebRTC media stack |
| Encryption | RTMPS (RTMP over TLS) where the server offers it | Passphrase-based, off unless a passphrase is set | Always on (DTLS-SRTP) |
| Sender examples | OBS Studio, FFmpeg | OBS Studio 25.0 and later, FFmpeg with libsrt | Browsers, OBS Studio 30.0 and later, FFmpeg 8.0 and later |
The reading that matters: only WHIP has a finished IETF standard and a browser path, and SRT is built around a retransmission window you configure. RTMP's advantage sits outside the table: platforms already accept it.
Where RTMP ingest still wins, and where it stops
RTMP ingest wins on reach. Adobe's RTMP specification defines an application-level protocol that multiplexes audio, video and data over a reliable transport such as TCP (Transmission Control Protocol), and the IANA (Internet Assigned Numbers Authority) port registry lists port 1935 as macromedia-fcs. YouTube's help centre accepts RTMPS, which it describes as RTMP over a TLS (Transport Layer Security) connection.
RTMP ingest stops at packet loss. RFC 9293 defines TCP as a reliable, in-order byte stream, so one lost segment holds back every byte behind it until the retransmission arrives.
The codec limit is changing. The Enhanced RTMP v2 specification says legacy RTMP and FLV (Flash Video) lack VP8, VP9, HEVC (High Efficiency Video Coding), VVC (Versatile Video Coding), AV1, Opus and FLAC, and adds them plus multitrack streams. The client declares its codecs in the connect command, so HEVC or AV1 over RTMP works only when the server supports Enhanced RTMP too. See what the RTMP protocol is and how its handshake works and the developer hub's RTMP guides.
How does the SRT protocol for streaming recover lost packets?
The SRT protocol for streaming recovers lost packets by retransmitting them inside a fixed latency window and dropping any packet that still cannot arrive in time. The SRT Internet-Draft describes the loop: the receiver sends a NAK (negative acknowledgement) when it sees a gap in sequence numbers, the sender puts the retransmission ahead of new packets, and the receiver releases each packet only after the configured latency has passed. Too-Late Packet Drop discards what misses its play time, keeping delay fixed at the cost of a glitch. The draft also allows FEC (forward error correction) alongside ARQ (automatic repeat request).
In libsrt, the reference implementation, the SRTO LATENCY socket option defaults to 120 ms in live mode. A retransmission needs at least one round trip, so a longer or more jittery path needs a larger window; set it from the link's measured round-trip time.
SRT connects as caller, listener or rendezvous, and encrypts with AES (Advanced Encryption Standard) keys derived from a shared passphrase. The IETF datatracker lists its specification as an expired individual draft with no formal standing. The developer hub has a Node.js RTMP server and an FFmpeg relay from RTMP to SRT.
How WHIP turns WebRTC into an ingest protocol
WHIP ingest sets up a WebRTC session with one HTTP exchange. In RFC 9725, the client POSTs an SDP (Session Description Protocol) offer, the server replies 201 Created with its SDP answer and a Location header naming the session, and the client completes ICE (Interactive Connectivity Establishment) and DTLS (Datagram Transport Layer Security) before sending media over SRTP (Secure Real-time Transport Protocol). An HTTP DELETE ends the session. PATCH carries trickle ICE candidates.
Encryption is mandatory. A browser can publish through the built-in RTCPeerConnection API. And the destination must be a WebRTC media server, so WHIP suits streams that join a real-time room. For how SRT and WebRTC compare once the stream reaches viewers, see that comparison.
Authentication is where interoperability breaks. RFC 9725 section 4.7.1 has clients send a bearer token as defined in RFC 6750. OBS Studio, which added WHIP output in version 30.0 on 12 November 2023, and FFmpeg both send the literal prefix "Bearer". An endpoint that expects a raw token rejects them, so check what your endpoint accepts before choosing an encoder.
Which ingest protocol should you choose?
Choose the ingest protocol by the source you must support and the network it crosses, not by a latency figure: none of the three specifications states one.
| Source | Network | Send | Why |
|---|---|---|---|
| Browser (webcam or screen) | Any | WHIP | The only one of the three a browser sends natively |
| OBS Studio to a social platform | Stable wired uplink | RTMP or RTMPS | Platforms document RTMP ingest; RTMPS adds TLS |
| OBS Studio into a WebRTC room | Any | WHIP (OBS 30.0 and later) | Lands in the room with no conversion |
| Hardware or field encoder | Lossy public internet or cellular | SRT | A retransmission window tuned to the path |
| IP camera | Local network | RTSP, pulled by a gateway | The gateway re-sends it as WHIP, RTMP or SRT |
The reading: if one row covers all your sources, accept one protocol. If your sources span rows, accept the protocol your destination speaks and convert the rest at a gateway.
Bridging RTMP, SRT and RTSP sources into a WebRTC room
A protocol gateway receives RTMP, SRT or RTSP (Real-Time Streaming Protocol) and republishes each stream to a WebRTC room's WHIP endpoint, transcoding only when the codec does not fit WebRTC. IP cameras are one reason to run a gateway, because they serve RTSP streams from the camera.
A browser reaches the room over WHIP directly; RTMP, SRT and RTSP sources reach it through an ingest server or gateway that re-sends them as WHIP.
FFmpeg can be that gateway. Its whip muxer, added in FFmpeg 8.0 on 22 August 2025, is marked experimental, expects H.264 without B-frames and Opus audio, and sends its optional authorization value as a Bearer token. A gateway built on it re-encodes the input to fit those limits and writes the whip format to the room's endpoint URL.
How VideoSDK handles ingest and output
In a WebRTC-based live platform, the room is the hub: streams arrive over WebRTC, and larger audiences get HLS or an RTMP restream. VideoSDK documents WHIP ingest and RTMP output, and does not document RTMP or SRT ingest. The WHIP/WHEP guide says a stream sent to the WHIP endpoint appears as a participant in the room, and the Create WHIP Session API returns the SDP answer with a Location header. That reference asks for the token without a prefix, while OBS and FFmpeg send "Bearer".
For output, startLivestream() pushes the room to RTMP destinations such as YouTube, Twitch and Facebook, taking an array of URL and stream key pairs, per the RTMP livestream guide. The room can also reach viewers as HLS; see how HLS packages the stream for viewers and the difference between RTMP in and RTMP out. Until the docs say otherwise, an RTMP or SRT source reaches a VideoSDK room through a gateway that republishes it over WHIP.
Scale and cost of live ingest
Ingest cost grows with the number of streams arriving at once, because each protocol keeps state for every stream: each RTMP publisher holds a TCP connection (RFC 9293), an SRT receiver buffers every stream for its latency window, which libsrt sets to 120 ms by default in live mode, and a WHIP endpoint keeps ICE and DTLS state for each session (RFC 9725).
A gateway adds compute for every stream it converts. FFmpeg's whip muxer expects H.264 without B-frames and Opus audio, so a source in any other codec has to be re-encoded before it can be sent over WHIP.
On VideoSDK, as of 6 October 2026, the pricing FAQ charges RTMP Out at $0.03 per re-streamed minute and bills each RTMP output stream separately. The pricing page lists WHIP and WHEP among the live streaming features without a separate rate, and caps simultaneous RTMP out streams per plan, with packs of 10 more streams for $20 a month.
Worked example, with hypothetical inputs: restreaming a 2-hour event to YouTube and Twitch is two RTMP output streams of 120 minutes each, so 2 × 120 × $0.03 = $7.20 at that rate. Hosts and viewers in the room are billed separately as speaker and viewer minutes, and the pricing FAQ works through an example of those.
Glossary
RTMPS (RTMP over TLS): RTMP carried inside a TLS connection, so the stream key and media are encrypted in transit.
Enhanced RTMP (E-RTMP): An extension of RTMP and FLV, maintained by the Veovera Software Organization, that adds modern codec signalling and multitrack media.
ARQ (automatic repeat request): Loss recovery by asking the sender to retransmit missing packets. SRT triggers it with NAK reports.
SDP offer and answer: The text descriptions of codecs, transports and connection details that two WebRTC endpoints exchange.
WHEP (WebRTC-HTTP Egress Protocol): The playback counterpart of WHIP, which lets a player pull WebRTC media with the same HTTP pattern. The IETF datatracker lists it as a working-group draft.
Key takeaways
- RTMP vs SRT is a choice between reach and resilience: RTMP reaches platforms that document RTMP ingest, and SRT recovers loss over UDP inside a latency window you set.
- WHIP, published as RFC 9725 in March 2025, is the only IETF standard of the three and the only one a browser sends without a plugin.
- Decide by source and network: browsers and WebRTC rooms take WHIP, social platforms take RTMP or RTMPS, and field encoders on lossy links send SRT.
- RTMP carries HEVC or AV1 only when both ends support Enhanced RTMP.
- Ingest cost grows with simultaneous streams; on VideoSDK, RTMP Out costs $0.03 per re-streamed minute for each destination, as of 6 October 2026.
If your sources span rows of the decision table, put a gateway in front of your destination. To see a WHIP stream join a room as a participant, work through the VideoSDK WHIP/WHEP guide for interactive live streaming; a new account includes a $20 credit.
Frequently asked questions
What is the RTMP full form?
RTMP stands for Real-Time Messaging Protocol; Adobe's specification spells it without the hyphen. According to the Enhanced RTMP specification, RTMP and the FLV file format were introduced in 2002, and Adobe published the protocol as a memo in December 2012.
How do you use the SRT protocol in OBS?
OBS Studio sends SRT from version 25.0, according to the OBS wiki page on SRT streaming. You enter an srt:// URL as the stream server, with options such as latency and passphrase that must match the receiver. The same page, last edited in July 2023, says the main streaming services did not accept SRT ingest.
Is SRT encrypted by default?
No. SRT supports AES encryption with 128, 192 or 256-bit keys, but it switches on only when a passphrase is set. In libsrt, SRTO_PASSPHRASE defaults to an empty string, which disables encryption. A passphrase must be 10 to 80 characters, and a peer with a different passphrase is rejected unless enforced encryption is turned off.
Is WHIP an IETF standard or still a draft?
WHIP is a published IETF standard: RFC 9725, issued in March 2025 on the Standards Track, updating RFCs 8840 and 8842. The RFC requires WHIP clients to implement bearer token authentication, though an endpoint may choose not to require a token.