Update RTMP positioning — WHIP now recommended for ingest

[alexbj75]

Summary

RTMP is currently presented as an ingest protocol without clearly communicating its limitations and that newer alternatives have replaced it for most use cases. The current framing is misleading for newcomers building streaming stacks in 2026.

What needs to change

Position RTMP as legacy

RTMP's limitations:

• No support for modern codecs (H.265, AV1, Opus audio)
• No built-in encryption (security risk without RTMPS)
• Single TCP connection — latency sensitive, NAT traversal issues
• No standardized way to handle frame metadata

Despite these limitations, RTMP remains widely deployed for compatibility with legacy encoders and platforms. The framing should be: "RTMP is widely supported but is legacy. For new deployments, prefer WHIP or SRT."

Add a protocol selection guide for ingest

Protocol	Best for	Notes
WHIP (RFC 9725)	Sub-second WebRTC ingest, interactive streaming	OBS native support, modern CDN support
SRT	Contribution over unreliable networks	ARQ error correction, AES-256 encryption built-in, broadcast standard
RTMP	Legacy encoder compatibility	Widely supported but no modern codec support

Related issues

• Add section: WHIP/WHEP — new standard for live ingest (RFC 9725) #12 (Add WHIP/WHEP section) — the positive counterpart to this update
• The RTMP update and WHIP addition work best done together

References

• RFC 9725 (WHIP): https://datatracker.ietf.org/doc/rfc9725/
• SRT Alliance: https://www.srtalliance.org/
• OBS WHIP support: https://obsproject.com/wiki/WHIP-and-WHEP