FFmpeg推流至Mediasoup全流程指南

要利用 FFmpeg 以非 WebRTC 协议（如 RTMP、RTP、SRT 等）将流推送到 MediaSoup，并实现稳定、低延迟的传输，需要从架构设计、流程梳理、技术选型和部署运维等多个层面进行系统性规划。本文将为你提供一份从设计到部署的完整指南。

一、 整体架构设计

核心思想是利用一个 "协议转换网关" ，将 FFmpeg 输出的流（非 WebRTC）转换为 MediaSoup 能够直接消费的 RTP 流。MediaSoup 本质上是一个 SFU（Selective Forwarding Unit），其内部传输基于 RTP/RTCP，因此关键是将任意输入流"翻译"成标准的 RTP 包。

推荐的主流架构如下：

组件	角色	推荐技术/工具	备注
流来源	视频/音频生产者	FFmpeg	负责采集、编码、封装和推送原始流。
协议转换网关	协议与格式转换	GStreamer 、Janus Gateway 的 Streaming 插件、自定义 Node.js 服务 （使用 mediasoup 库）	这是核心枢纽，接收 FFmpeg 流，解码/解封装，再通过 mediasoup 库以 Producer 身份注入房间。
SFU 服务器	流路由与转发	MediaSoup	核心 SFU，负责接收来自网关的 RTP 流，并转发给房间内的其他 Consumer（如浏览器）。
信令服务器	业务逻辑与状态管理	Node.js + Socket.IO (官方Demo架构)	处理房间创建、用户加入、Transport 和 Producer/Consumer 的创建等信令交互。
客户端	流的消费者	Web 浏览器 (WebRTC) 、移动端 SDK 、其他 FFmpeg	通过 WebRTC 或 Plain RTP 从 MediaSoup 拉流。

为什么需要网关？

因为 MediaSoup 的 Node.js 库 (mediasoup) 设计用于在 Node.js 进程中直接处理 RTP 包。FFmpeg 推来的 RTMP/RTSP/SRT 流是封装好的传输流，需要先解封装、解码（可选）、再重新编码或直接转发为 RTP。这个过程在 Node.js 中直接实现较为复杂，而 GStreamer 或 Janus 对此有成熟支持。

二、 详细工作流程梳理

以下以 FFmpeg -> GStreamer -> MediaSoup 这条技术路径为例，详细说明流程。

阶段 1：准备与推送源流

1. 源流准备：使用 FFmpeg 从文件、设备或屏幕捕获音视频。

2. 推流到网关 ：FFmpeg 将编码后的流（如 H.264/AAC）以某种协议（如 RTMP、RTP）推送到 协议转换网关 的指定入口。

   示例 FFmpeg 命令（推 RTMP 到网关）：

   # 假设网关在 192.168.1.100 监听 RTMP
   ffmpeg -re -i input.mp4 \
          -c:v libx264 -preset veryfast -tune zerolatency \
          -c:a aac -b:a 128k \
          -f flv rtmp://192.168.1.100:1935/live/stream_key

   注释：-re 表示按输入文件速率读取，模拟直播；-tune zerolatency 针对低延迟场景优化。

阶段 2：协议转换与 RTP 注入

这是最关键的步骤。网关需要完成：

1. 接收流 ：GStreamer 使用 rtspsrc, rtmpsrc, srtclientsrc 等元素接收 FFmpeg 推送的流。

2. 解码与处理 （可选）：如果需要转码或过滤，使用 decodebin, videoconvert, audioresample 等元素。

3. 编码（可选）：如果源流编码格式不是 MediaSoup 支持的（如 VP8, VP9, H.264, Opus），需要重新编码。

4. 封装为 RTP ：使用 rtp...pay 元素（如 rtph264pay, rtpopuspay）将编码后的数据打包成 RTP。

5. 发送至 MediaSoup ：通过 udpsink 将 RTP/RTCP 包发送到 MediaSoup Worker 创建的 PlainTransport 或 WebRtcTransport 的 IP 和端口。更优雅的方式是，在运行网关的机器上，直接调用 MediaSoup 的 Node.js API 创建一个 Producer。

   更推荐的方案：在 Node.js 网关服务中直接使用 mediasoup 库

   可以编写一个 Node.js 服务，它同时具备两种能力：

   • 作为 "FFmpeg 流接收器" ：使用 child_process 启动 FFmpeg 进程，让其将流输出到本服务的管道（pipe:1）或 UDP 端口。
   • 作为 "MediaSoup Producer" ：使用 mediasoup 库连接到 MediaSoup 路由器，创建 Transport 和 Producer，将从 FFmpeg 接收到的 RTP 包直接通过 producer.send(rtpPacket) 方法发送出去。

   示例 Node.js 网关服务核心代码片段：

   const { spawn } = require('child_process');
   const mediasoup = require('mediasoup');
   
   // 1. 创建 MediaSoup Router (通常从信令服务器获取 routerCapabilities)
   // 假设已有 mediasoupWorker 和 router
   // 2. 创建用于接收 FFmpeg RTP 的 PlainTransport
   const transport = await router.createPlainTransport({
     listenIp: { ip: '127.0.0.1', announcedIp: 'YOUR_SERVER_IP' },
     rtcpMux: false,
     comedia: false, // FFmpeg 需要主动连接过来
   });
   
   // 3. 创建 Producer
   const producer = await transport.produce({
     kind: 'video',
     rtpParameters: {
       codecs: [/* 匹配 FFmpeg 输出的编码格式，如 H.264 */],
       encodings: [/* 编码参数 */],
       // ... 其他 RTP 参数
     }
   });
   
   // 4. 启动 FFmpeg，让其将 RTP 流发送到 transport 的 tuple
   const ffmpeg = spawn('ffmpeg', [
     '-i', 'input_source',
     '-an', // 如果先处理视频，忽略音频
     '-c:v', 'copy', // 或指定编码器
     '-f', 'rtp',
     `rtp://127.0.0.1:${transport.tuple.localPort}?rtcpport=${transport.rtcpTuple?.localPort}`
   ]);
   
   // 5. （可选）监听 transport 的 'rtp' 事件，手动处理包，或由 mediasoup 自动处理
   transport.on('rtp', (rtpPacket) => {
     // 如果 FFmpeg 是推流到另一个端口，可以在这里将包转发给 producer.send(rtpPacket)
   });
   
   // 对于音频流，重复步骤 2-4，创建另一个 transport 和 producer。

   注释：此代码展示了核心逻辑，实际需要处理错误、日志、SDP 协商（生成 SDP 文件给 FFmpeg）等。

阶段 3：MediaSoup 路由与分发

1. 信令交互：网关服务（作为"虚拟用户"）通过信令服务器加入到指定房间。
2. 创建 Transport 与 Producer ：如上代码所示，网关在 MediaSoup 中创建 PlainTransport 和 Producer，将外部流"注册"到 SFU。
3. 流发布 ：一旦 Producer 创建成功，该流就进入了 MediaSoup 的房间。信令服务器会通知房间内的其他客户端有新的流可用。
4. 客户端消费 ：其他客户端（如浏览器）可以通过信令服务器创建 Consumer，订阅这个 Producer 的流，通过 WebRTC 传输到浏览器端播放。

三、 关键注意事项

1. 时间戳与同步 ：FFmpeg 输出的 RTP 包必须包含正确、连续递增的 RTP 时间戳和序列号。如果是从文件循环推流，需要注意时间戳重置问题，否则会导致 MediaSoup 或客户端播放异常。建议使用 -re 并确保源是实时的。
2. 编码格式兼容性 ：
   • 视频 ：MediaSoup 默认支持 VP8/VP9/H.264。确保 FFmpeg 输出的是这些格式之一。如果使用 H.264，注意 profile-level-id 和 packetization-mode 等参数在 rtpParameters 中的正确设置。
   • 音频 ：优先使用 Opus 。如果使用 AAC，需要确保 MediaSoup 版本和客户端支持。在 rtpParameters 中正确设置 clockRate 和 channels。
3. SDP 文件：如果采用"FFmpeg -> SDP -> MediaSoup"的直接 RTP 拉流模式（如参考资料中消费流的例子），需要为 FFmpeg 生成正确的 SDP 文件。这个 SDP 描述了流的编码格式、目标 IP 和端口。在推流场景下，网关服务需要动态生成这个 SDP 供 FFmpeg 使用。
4. 网络与防火墙：确保 FFmpeg、网关、MediaSoup Worker 之间的网络是连通的，特别是 UDP 端口（用于 RTP/RTCP）需要开放。如果部署在公有云，注意安全组和防火墙规则。
5. 错误处理与重连：实现完善的日志和监控。网络波动或进程重启时，需要有机制让 FFmpeg 和网关自动重连，并重新向 MediaSoup 注册 Producer。
6. 性能与资源 ：
   • 转码开销：如果网关需要进行视频转码（如 H.265 转 H.264），CPU 开销会非常大。考虑使用硬件加速（如 GPU、Intel QSV）。
   • 内存与带宽：高并发下，SFU 会复制多份流，带宽消耗大。合理规划服务器带宽和内存。
   • 延迟累积 ：每个处理环节（编码、网络传输、缓冲、解码）都会引入延迟。优化 FFmpeg 参数（如降低 GOP、使用低延迟编码预设）、调整 MediaSoup PlainTransport 的缓冲区大小，以在延迟和流畅度间取得平衡。

四、 部署方案

1. 一体化部署：将所有服务（FFmpeg 进程、Node.js 网关、MediaSoup Worker、信令服务器）部署在同一台高性能服务器上。优势是网络延迟极低，部署简单；缺点是资源竞争，扩展性差。适合小规模或测试环境。
2. 分布式部署 ：
   • 采集层：FFmpeg 运行在靠近视频源的机器上。
   • 网关层：部署一组专用的协议转换网关服务器，负责接收 FFmpeg 流并转换为 RTP。
   • SFU 层：部署 MediaSoup Worker 集群，网关通过内网将 RTP 流推送到 Worker。
   • 信令与业务层 ：部署信令服务器集群，并配备负载均衡。
     这种部署需要服务发现机制，让网关知道该连接到哪个 MediaSoup Worker 和房间。

总结 ：利用 FFmpeg 非 WebRTC 协议推流到 MediaSoup 的核心在于构建一个稳定、高效的协议转换网关。推荐采用 Node.js 服务直接集成 mediasoup 库 的方案，它提供了最大的灵活性和控制力。在整个流程中，要特别注意编码格式、RTP 参数、网络和时间戳的匹配，并在部署时根据性能、延迟和扩展性需求选择合适的架构。

---

参考来源

• ffmpeg录制转发mediasoup的音视频流
• JITSI开源视频直播
• 视频教程-FFmpeg音视频开发实战6 iOS/Android/windows/Linux-其他
• Vue前端中展示监控摄像头视频流
• 浏览器无插件播放海康RTSP流？这3种低延迟方案实测对比（VLC/猿大师/WebRTC）
• JITSI开源视频直播