OBS says WHIP now, what’s that?
Almost every architecture on this blog starts with an RTMP arrow: broadcaster pushes RTMP to a server, server does its thing, viewers get HLS or DASH or WebRTC out the other end. That arrow has been the one constant — even the encryption starts with an unencrypted RTMP push.
Maybe it doesn’t have to be. WHIP recently became an IETF standard, and the major open source broadcasters already support it. On the server side, the picture is less clear. YouTube and Facebook don’t accept it, and the self-hosted media servers are well ahead of the big platforms.
But…
RTMP is elegantly simple for what it does: one TCP connection, one port, audio and video and metadata multiplexed over it. It’s been the universal ingest protocol for over two decades and it earned that position. It’s also a proprietary spec built for a world that no longer exists, with limited codec support, latency measured in seconds, and encryption bolted on as an afterthought.
Then again, it’s not standing still. Enhanced RTMP brings modern codec signaling and multitrack capabilities, so the old codec argument is no longer a blanket reason to switch. The real question is still operational: what your endpoints support, what your users can run comfortably, and whether switching buys a concrete win.
See for yourself: fancy connectivity tester
One thing RTMP has going for it is predictability: if TCP port 1935 is open, it works. WHIP inherits WebRTC’s full connectivity stack (ICE, STUN, TURN, UDP candidate gathering), which is more capable but also more dependent on what the network allows. WebRTC prefers UDP for the media path, but can fall back to TCP candidates or TURN over TCP/TLS when the network is restrictive. That helps it work in places where raw UDP is blocked, but usually with worse latency, more jitter sensitivity, and TCP head-of-line blocking. Whether WHIP will work from a given network isn’t always obvious.
The tester probes your network and reports what WHIP has to work with: direct UDP, TURN relay, or nothing usable. This only tests your browser and connection — someone else’s setup may give different results.
So should I switch already?
What do you know, it depends 🙂
What you’d gain
- Latency: Sub-second glass-to-glass instead of the 2-8 seconds you tolerate with RTMP.
- Security: DTLS/SRTP by default. No RTMPS configuration, no certificate juggling.
- Codecs: AV1, VP9, H.265, Opus — whatever client and server negotiate via SDP.
- Signaling: Plain HTTP. Sits behind load balancers and CDNs without custom plumbing.
- Standardization: One spec for WebRTC ingest instead of each server inventing its own signaling.
What you’d lose
- Quality control: WebRTC adapts aggressively. Bitrate drops, resolution scales down, frames skip. Right for calls, wrong for a polished stream. If you need both low latency and quality control, SRT is worth a look.
- Simple firewalls: RTMP is one TCP port. WHIP needs ICE, STUN, TURN, and a UDP range. Expect real time on connectivity debugging.
- Platform compatibility: YouTube, Twitch, Facebook all take RTMP. WHIP limits your options unless you control the server.
When it’s worth it
- Self-hosted ingest: You control the media server (Janus, MediaMTX, Pion, Cloudflare) and don’t depend on platform support.
- Real-time interaction: Auctions, sports betting overlays, live commerce. Sub-second matters more than visual consistency.
- WebRTC end-to-end: Already running WebRTC on playback. Adding WHIP eliminates the RTMP-to-WebRTC transcoding hop.
When it isn’t
- Platform lock-in: YouTube, Twitch, Facebook are RTMP-only.
- Non-interactive streams: “Go live and walk away.” No latency pressure, no reason to switch.
- Quality expectations: Audience expects consistent 1080p60. Adaptive dips are a dealbreaker.
- Restrictive networks: UDP blocked, TURN relay costs eat your budget. RTMP’s single TCP port wins.
Ok, I want to try it without wasting a whole day
Here. Under 20 minutes.