WebRTC ingest takes the same WebRTC stack that powers Google Meet and Zoom and points it at a live ingest server. The browser (or a native WebRTC app, or OBS with the WHIP plugin) opens a PeerConnection to the ingest, negotiates SDP, and starts sending RTP packets carrying H.264, VP8, VP9 or AV1 video and Opus audio. The ingest demultiplexes, decodes if needed for transcoding, and feeds the rest of the pipeline.
The advantage is latency. Where RTMP adds 2–5 seconds, WebRTC ingest adds 100–500 ms. For interactive streaming — auctions, betting, video conferencing, classroom — that gap matters. The other advantage is browser-native: WebRTC works in every modern browser without a plugin, so any web app can be a contribution source without installing software. That powers screen-share-and-stream apps, browser-based esports tools, and remote-production workflows.
The disadvantage is operational complexity. WebRTC needs STUN and TURN servers, ICE negotiation, congestion-controlled RTP, NACK and PLI handling — a much heavier stack than RTMP's TCP socket. Cloud services (Cloudflare Stream, Mux, Dolby.io, AWS) hide this complexity behind a WHIP URL. Self-hosting is doable with mediasoup, Pion or Janus, but requires significantly more infrastructure than running an nginx-rtmp endpoint.
