FFmpeg merges WebRTC support

Original Article ↗ Hacker News Discussion ↗

What was added

  • FFmpeg’s libavformat now includes a WHIP muxer, enabling it (and apps using its libraries) to send media via WebRTC.
  • WHIP (WebRTC-HTTP Ingestion Protocol) = push media into a WHIP gateway that handles full WebRTC (ICE/STUN/SCTP, etc.) to endpoints.
  • It does not yet implement WHEP (the receiving/egress side) and does not expose the low-level SCTP datachannel parts of WebRTC.

Practical use cases and impact

  • Any FFmpeg-based tool (OBS, GStreamer, custom apps, Unreal streaming setups, etc.) can now ingest into WHIP-enabled services (e.g., some CDNs, Twitch, Cloudflare, LiveKit, Dolby).
  • Enables low-latency browser consumption of streams without users opening ports, e.g.:
    • Remote desktop / remote control, drones, robots.
    • Art installations / city “portals” with near real-time audio/video.
    • Recording or transcoding live WebRTC streams directly with FFmpeg CLI or libraries.
  • Seen as a major step toward a ubiquitous open broadcasting protocol across desktop, mobile, web, and embedded platforms; potentially lowers cost vs traditional transcoding-heavy setups, especially with simulcast and modern codecs.

Latency, protocols, and alternatives

  • WebRTC is praised for sub-second latency over the open internet, especially under loss, where UDP+FEC/NACK can outperform TCP.
  • Some point out that on clean LANs, very low latency is also possible with plain TCP streams; browsers’ HLS-centric ecosystem is the real barrier.
  • Discussion of HLS vs LL-HLS and why the industry ended up using complex WebRTC for low latency.
  • Comparisons with SRT; some users struggle to get SRT under ~1s, while WebRTC can reach ~100 ms on LAN.

Security and hardening

  • Concern that adding WebRTC increases FFmpeg’s attack surface, referencing many WebRTC-related CVEs in browsers.
  • Others argue most CVEs are implementation-specific (browsers, libvpx), not inherent to the protocol; FFmpeg’s WHIP piece is small and narrow.
  • General consensus: FFmpeg is already sensitive software; treat it as untrusted when handling user input:
    • Run in containers or VMs, use seccomp, minimize enabled muxers/decoders (e.g., --disable-muxer=whip if unused).

Implementation status and project process

  • Building requires --enable-muxer=whip and --enable-openssl; some got 500 errors with certain providers until they added an audio stream.
  • There is interest in future WHEP and possibly more complete peer-side functionality (ICE, SCTP, datachannels), but that’s not standardized or exposed yet.
  • Some FFmpeg developers criticize the merge process: a single large squashed commit, limited tests, and missing features like NACK support; concern about half-finished vendor-driven features entering tree before being production-ready.