WHIP is a finished standard. Twitch still wants RTMP.
The replacement for RTMP got its RFC in March 2025, and encoders followed within the year. The platforms most creators stream to have not moved, and that gap decides how much any of this matters to you today.
RTMP shipped with Flash in 2002. Adobe killed Flash in 2020. RTMP is still here. It still carries most of the live video going into most platforms. Nothing replaced it at the point where your encoder meets a server, so it stayed.
WHIP replaces it. The IETF made it a real standard in March 2025, RFC 9725. That matters for one reason. Vendors now build it the same way. WHIP does one job: a sender POSTs an SDP offer to an HTTP endpoint, gets an answer back, and media flows over WebRTC. The mental model matches RTMP. A URL and a stream key. The difference is underneath, where the media lands in about half a second instead of two to five.
WHEP covers the other direction, playback. It is still an Internet-Draft as of mid-2026 and has not reached RFC. Implementations talk to each other anyway.
What already speaks it
OBS Studio shipped native WHIP output in version 30. FFmpeg carries a whip muxer in the 7.x branch, and GStreamer covers it through webrtcsink and whipclientsink. On the hardware side AJA, Magewell, Blackmagic and Teradek have pushed firmware with WHIP support.
Ingest endpoints exist at Cloudflare, AWS IVS, Dolby OptiView, Red5, Ant Media and Eyevinn.
The encoder half of the problem is solved. Point OBS at a WHIP endpoint and you have sub-second contribution today, on hardware you own.
What has not moved
Twitch and YouTube still take RTMP from general creators. That one fact decides how much this changes your day. Push sub-second video into a platform that hands it out on multi-second HLS and you get a faster first leg. Your audience waits as long as it always did.
Latency at ingest and latency at the viewer are different numbers. Cutting the first one does nothing for the second unless the platform's delivery side also changes. Most of them have not.
Where it lands for bonded and IRL setups
WHIP does not bond links. WebRTC brings its own congestion control and retransmission. That handles a lossy connection better than raw RTMP over TCP. It does not aggregate four modems on a moving scooter. That job sits below the ingest protocol, and SRTLA and bonding routers still own it. WHIP rides on top of whatever single logical link they hand up.
SRT keeps its place for the same reason. It was built for bad networks. You set a latency budget and trade delay for resilience on a weak link. WHIP arriving does not remove that.
| Protocol | Status | Best at | Ingest latency |
|---|---|---|---|
| RTMP | Universal, 2002-era | Being accepted everywhere | 2–5s |
| SRT | In broad use | Lossy links, tunable budget | Configurable |
| SRTLA | Niche, IRL-specific | Bonding several modems | Follows SRT |
| WHIP | RFC 9725, March 2025 | Sub-second into WebRTC infrastructure | Under 500ms |
The read
WHIP won the standards argument. It has the encoder support to back it. What happens next sits with the two platforms holding the most creators, and neither has said anything. Stream to Twitch or YouTube and this is a protocol to understand, not one to switch to.
The people who benefit today run their own infrastructure. Control the receiving end and you can act now. Cloudflare, a self-hosted Ant Media box, anything exposing a WHIP endpoint. You can cut a couple of seconds out of your pipeline this week with software you already own.
Sources
- IETF WISH working group, WHIP
- Dolby OptiView, WHIP explained
- Dacast, WebRTC WHIP ingest
- Medialooks, WHIP and WHEP in broadcast workflows
The Rig Wire reports on streaming technology from public documentation and vendor releases. We did not bench-test the protocols described here, and we say so when we have.