FFmpeg杀入WebRTC直播战局

FFmpeg支持WebRTC了：这意味着使用FFmpeg库（具体看起来像libavformat）的程序可以使用webRTC流

WHIP多路复用器与FFmpeg合并，实现亚秒级延迟流传输！一个大项目一夜之间被合并到FFmpeg中，为亚秒延迟流提供WHIP复用器。

 WHIP 是什么 & FFmpeg 怎么用它

1. WHIP 是啥？
WHIP（WebRTC-HTTP Ingestion Protocol）就是一个“低延迟直播快递员”，专门用 WebRTC 送视频流，但比传统直播（比如 RTMP）快得多，延迟可以低到 1 秒内（像视频通话一样快）。
它的工作流程：

1. 先走 HTTP 打招呼（交换 SDP 信息，商量怎么传数据）
2. 然后用 STUN/UDP 建立连接（找到最快的“送货路线”）
3. 最后用 RTP 打包音视频（把视频切成小块，加密后发出去）

因为基于 WebRTC，加密是强制的（DTLS-SRTP），所以安全性比传统直播协议（如 RTMP）强很多。

2. WHIP 适合谁用？

• 直播平台（想搞超低延迟互动的，比如直播带货、游戏直播）
• 监控/无人机（需要实时回传画面的）
• 视频会议（但不是 Zoom/Teams 那种，而是自己搭建的）

它是 IETF 标准（不是野路子协议），所以大厂都在跟进，比如 Millicast 就用 WHIP 做超低延迟直播。

3. FFmpeg 现在支持 WHIP 了！
最近 FFmpeg 合并了一个近 3000 行代码的大更新，让 FFmpeg 能直接当 WHIP 推流客户端。
这意味着啥？

• 你可以用 ffmpeg 命令直接推 WHIP 流，不用额外写代码！
• 比如：

  ffmpeg -i input.mp4 -c:v libx264 -f whip https://whip-server.example.com/stream
  就能把视频低延迟推出去。

4. Millicast 的 WHIP 演示（W3C 资料）
Millicast（一家搞低延迟直播的公司）在 W3C 做了个分享，详细讲了 WHIP 怎么用。
重点总结：

• WHIP 比 WebSocket+RTMP 快得多，适合实时互动场景。
• 它依赖 WebRTC 底层（ICE/STUN/SDP/RTP），但不用你自己折腾，WHIP 网关全包了。
• 浏览器可以直接用 MediaStream 推 WHIP 流（适合网页直播）。

终极结论：WHIP = 低延迟直播的“傻瓜相机”

• 以前：想搞低延迟直播？自己写 WebRTC 代码，调 STUN/TURN，搞 SDP 协商…头都大了！
• 现在：用 WHIP，就像用“外卖 App”点餐——你只管送视频，复杂的协议全交给 WHIP 网关处理。

网友热评1
对WebRTC广播感到非常兴奋。我在Broadcast Box[0] README和OBS PR [1]中写下了一些原因

现在GStreamer、OBS和FFmpeg都支持WHIP，我们终于有了一个适用于所有平台（移动的）的视频广播无处不在的协议、Web、嵌入式、广播软件等..）

我一直致力于开源+ WebRTC广播多年。这是一个巨大的里程碑：）
[0] https：//github.com/Glimesh/broadcast-box？tab= readme-over-file#.
[1] https：//github.com/obsproject/obs-studio/pull/7926

网友热评2
WebRTC通常用于双向用例，如带有文本选项的视频聊天，所以我不认为VLC完全支持它很奇怪。VLC也不支持拨号到Asterisk服务器。
[1] https：//gstreamer.freedesktop.org/documentation/rswebrtc/web.

网友热评3
注意啦！这玩意儿根本不是SCTP的零部件！它现在装的是"WHIP协议"这个新引擎——就像外卖小哥专用的电动车，专门用来和快递站（网关）快速打电话。真正的WebRTC送货员（对等端）其实骑着SCTP协议的摩托车送货呢！

要我说啊，早晚该把SCTP这辆老摩托换成QUIC快递车！你们想啊，QUIC直接用现成的UDP马路就能跑，哪像SCTP还得自己修专用车道。现在有个叫MoQ的候选方案（可以理解为"QUIC特快专递"），可惜浏览器厂商们都在睡大觉，开发进度还停留在三年前...[附两个快递公司官网]

重点就是：现在这套系统就像用电动车接单+摩托车送货，将来最好全换成QUIC新能源车！

网友热评4
解释 WebRTC 的复杂性和 WHIP/WHEP 的作用
WebRTC 真的超级复杂！就像你要自己造一辆能飞能跑还能潜水的车，得搞定一堆乱七八糟的零件（ICE、SDP、DTLS、SRTP、SCTP…）。

WHIP（WebRTC-HTTP Ingestion Protocol）就像是“外卖接单系统”——你只管把视频流（外卖）交给 WHIP 网关（外卖平台），它负责处理所有复杂的 WebRTC 细节（怎么送、走哪条路、怎么打包）。这样，你（开发者）就不用自己折腾所有底层协议，省了一大堆麻烦。

但问题来了：WHIP 依赖外部网关（比如云服务），就像外卖平台得靠骑手送餐，你自己没法直接送。
ffmpeg 能自己当“独立外卖员”吗？

理论上可以！ffmpeg 可以：

1. 当 ICE 服务器（自己找路）
2. 用 WHEP（WebRTC HTTP Egress Protocol）协商 SDP（和对方商量怎么送）
3. 用 SCTP 传流（实际送货）

这样，ffmpeg 就能绕过 WHIP 网关，直接和对等端（Peer）通信，相当于“自己开店自己送外卖”。

但为啥大家（OBS、gstreamer）还是用 WHIP？
因为 WHIP 把复杂决策都外包了，比如：

• 用什么传输协议？（SCTP？QUIC？）
• 怎么处理 NAT 穿透？（STUN/TURN？）
• 怎么加密？（DTLS-SRTP？）

这些决策在 WHIP 网关里都定好了，你不用操心。如果你自己搞，就得做一堆选择，而这些选择可能和别人的 WebRTC 实现不兼容。

WHEP 是“反向 WHIP”

• WHIP = 发送流（Ingest） → 适合推流（比如直播）
• WHEP = 接收流（Egress） → 适合拉流（比如播放）

WHEP 现在挺流行，但依然依赖网关。

结论：别想着面面俱到，该脱钩就脱钩
WebRTC 的“层蛋糕”太复杂（ICE+SDP+DTLS+SRTP+SCTP…），WHIP/WHEP 的价值就是让你不用全搞懂，直接用一个标准化的方式收发流。

如果你想完全自己控制（比如用 ffmpeg 当独立对等体），那就要面对所有复杂细节。但大多数时候，用 WHIP 网关更省事，就像点外卖比自己种菜做饭快多了！

（当然，未来如果 QUIC/WebTransport 普及，可能 WebRTC 会变简单，但现在嘛…先凑合用吧！）