• 后端
• 音视频

【免费下载链接】mediasoup

Cutting Edge WebRTC Video Conferencing

项目地址： https://gitcode.com/gh_mirrors/me/mediasoup

点击查看 免费下载

mediasoup 是一个面向服务器端的 WebRTC SFU（Selective Forwarding Unit，选择性转发单元）媒体服务器，同时以 Node.js 模块与 Rust crate 两种形态发布，其核心媒体引擎由基于 libuv 的 C++ 子进程（mediasoup-worker）承载。本文以仓库根目录 README.md 为主体脉络，结合 Node.js 模块入口、Rust 库入口、构建文档 与 worker 源码，完整梳理 mediasoup 的设计目标、分层架构、核心实体、应用场景与功能特性，帮助读者理解"如何用 mediasoup 搭建实时音视频转发服务"。

项目概览：一个只关心媒体层的 SFU

mediasoup（当前仓库 npm 包版本为 3.27.1，见 package.json）是一个服务端媒体服务器与客户端库的集合。它定位为 SFU（Selective Forwarding Unit）：不混合、不转码，而是将每个参与者的媒体流（Producer）选择性转发给其他参与者（Consumer），从而在多人视频会议场景中大幅降低服务端计算与带宽成本。

mediasoup 的核心特征可以概括为"服务器端是媒体转发引擎，API 极低层、信令无关"：

• 服务端形态为 Node.js 模块（ECMAScript 6 API）或 Rust crate（Idiomatic Rust API），二者共享同一个由 C++ 实现的媒体 worker；
• 客户端提供轻量级的 TypeScript 与 C++ 库；
• 只处理媒体层（media layer），不内置任何信令协议；
• 对外暴露超级低层的 API，把"如何做"的选择权完全交给业务开发者。

从 package.json 可以看到，Node.js 形态要求 Node.js 版本不低于 22（"engines": { "node": ">=22" }），包的主入口为 node/lib/index.js，并额外通过 exports 暴露了 ./types、./errors、./ortc、./extras 等子路径；依赖仅包含 debug、flatbuffers、h264-profile-level-id 等少量库，印证了"极简依赖"的设计取向。

设计目标：九条原则决定架构走向

README 明确列出了 mediasoup 及其客户端库的设计目标，这些原则直接决定了仓库的目录结构与代码组织：

1. Be a SFU (Selective Forwarding Unit)：服务端只做媒体选择性转发，不做混合（MCU）与转码，这是性能与架构的基石。
2. Support both WebRTC and plain RTP input and output：既支持完整 WebRTC 协议栈（ICE/DTLS/SRTP），也支持纯 RTP/RTCP 接入，以便对接 GStreamer、FFmpeg 等传统多媒体工具。
3. Be a Node.js module or Rust crate in server side：服务端提供 Node.js 与 Rust 两套 API，对应仓库中的 node/ 与 rust/ 两个目录。
4. Be a tiny TypeScript and C++ libraries in client side：客户端库保持轻量。
5. Be minimalist: just handle the media layer：严格限定在媒体处理领域，不越界。
6. Be signaling agnostic: do not mandate any signaling protocol：不强制任何信令协议，开发者可自由选择 WebSocket、Socket.IO 或自研信令。
7. Be super low level API：API 贴近底层能力，把最大灵活性交给上层业务。
8. Support all existing WebRTC endpoints：兼容主流浏览器与移动端 WebRTC 端点。
9. Enable integration with well known multimedia libraries/tools：便于与 FFmpeg、GStreamer 等生态集成（架构图中即有 GStreamer 推流与 FFmpeg 录制的场景）。

这些目标不是口号，而是直接映射到了代码结构：node/ 下是 Worker.ts、Router.ts、Transport.ts、Producer.ts、Consumer.ts 等 TypeScript 实体；worker/ 下则是对应的 C++ 实现，如 Worker.cpp、Router.cpp、WebRtcTransport.cpp 等。

架构：Node.js/Rust 进程 + C++ Worker 子进程

mediasoup 的架构分层清晰，README 中的架构图直观展示了其生产消费模型：

三层架构

从架构图（art/mediasoup-v3-architecture-02.png）与源码结构可以梳理出以下三层：

Host（主机）：运行 mediasoup 的服务器节点，一个主机内可以运行多个 mediasoup Worker 实例，用于利用多核 CPU 实现水平扩展。

Worker：mediasoup 的基本运行单元，是一个独立的 C++ 线程（在 Node.js 形态下为子进程），基于 libuv 事件循环实现。每个 Worker 在单核上运行，README 称之为"extremely powerful (media worker thread/subprocess coded in C++ on top of libuv)"。从 rust/src/lib.rs 的注释可以印证："Each worker is backed by single-core C++ worker thread"。

Router：Worker 内部的媒体路由核心。一个 Worker 内可创建多个 Router，每个 Router 独立负责媒体流的注入、选择与转发。Router 本身不跨 Worker 共享状态，因此天然具备隔离性；跨 Router 或跨 Worker 的媒体流转发则通过 PipeTransport 完成（见架构图中 Router 2 经 PipeTransport 向 Worker 2、Worker 3 转发视频的场景）。

Transport、Producer、Consumer：媒体流的三大实体

• Transport：连接外部端点与内部 Router 的通道，决定了对端通信所用的协议栈。mediasoup 提供多种 Transport：
  • WebRtcTransport：完整 WebRTC 协议栈（ICE、DTLS、SRTP），面向浏览器与移动端，图中所有 Participant 均经 SRTP 与其通信；
  • PlainTransport：纯 RTP/RTCP，无 WebRTC 协议栈，面向非 Web 端点，图中 GStreamer（mp4 broadcaster）与 FFmpeg（recording）即通过 RTP 接入/接出；
  • PipeTransport：用于同一主机内不同 Worker/Router 之间的媒体转发（图中 Worker 1 的 Router 2 将视频经两个 PipeTransport 分别转发至 Worker 2、Worker 3 的 Router，再经各自的 WebRtcTransport 分发给 viewer）。
• Producer：媒体生产者，将输入媒体流注入 Router（图中粉色背景的 Audio/Video Producer）。
• Consumer：媒体消费者，从 Router 订阅并输出媒体流（图中绿色背景的 Audio/Video Consumer）。

架构图同时揭示了多路复用能力：一个 WebRtcTransport 可以同时承载音频与视频 Producer/Consumer，这正是 README 特性中"multiple audio/video streams over a single ICE + DTLS transport"的直观体现。

Node.js 与 Rust 形态的入口与消息机制

• Node.js 形态：入口 node/src/index.ts 导出 version、全局 observer、workerBin（mediasoup-worker 二进制的绝对路径）以及 setLogEventListeners（可自定义接管 mediasoup 的 debug/warn/error 日志事件）。Node.js 侧通过 mediasoup.createWorker() 创建 Worker，Worker 以子进程方式启动 mediasoup-worker 二进制。
• Rust 形态：入口 rust/src/lib.rs 指出使用流程为 WorkerManager → Worker → Router → Transport → Producer/Consumer；与 TypeScript 版不同，Rust 版利用所有权系统，通过 Drop 实现自动优雅关闭，而非显式调用 close()。

Node.js 侧与 C++ worker 之间的进程间通信基于 FlatBuffers 二进制消息协议，schema 定义在 worker/fbs/ 目录（如 message.fbs、request.fbs、notification.fbs、response.fbs 以及各类实体 fbs 文件），这也解释了 package.json 中依赖 flatbuffers 的原因。

应用场景：低层 API 支撑的多种实时媒体业务

README 指出，由于 mediasoup 提供超级低层的 API、不设任何约束与假设，它能够支撑多样化的业务场景，典型包括：

• Group video chat applications（多人视频聊天）：每个参会者既是 Producer（发布音视频）又是 Consumer（订阅他人音视频），服务端在各 Router 内完成转发。
• One-to-many (or few-to-many) broadcasting applications in real-time（一对多/少对多实时广播）：少量推流端 + 大量观看端，架构图中的"1 个发布者 + 多个 viewer"即为典型拓扑。
• RTP streaming：通过 PlainTransport 直接接入/接出 RTP 流，对接 GStreamer、FFmpeg 等工具链。

仓库中的示例代码可以佐证这些场景：Rust 侧提供 echo.rs、videoroom.rs、svc-simulcast.rs、multiopus.rs 等服务端示例（rust/examples/readme.md），并配套 examples-frontend 下的 TypeScript 前端示例（echo、videoroom、svc-simulcast、multiopus 四个目录，含 webpack 构建配置）。

功能特性：从协议栈到带宽控制

README 列出的特性是理解 mediasoup 能力的核心清单，以下逐条展开并结合仓库证据说明。

低层 API

Node.js 侧为 ECMAScript 6 风格的低层 API，Rust 侧为 Idiomatic Rust 低层 API。Rust 版并非 TypeScript 版的逐字移植（见 rust/src/lib.rs：API 经过调整以利用 Rust 的类型系统与所有权系统，使 API 更健壮、更难误用），例如以 Drop 取代 close()。

多流复用（Multi-stream）

支持在单个 ICE + DTLS 传输上承载多条音频/视频流。架构图中一个 WebRtcTransport 同时承载 Audio Producer 与 Video Producer 即为此特性。从 worker 侧看，Producer.cpp 与 Consumer.cpp 通过 RtpStream、RtxStream 等抽象（RtpStream.hpp）管理同一条传输上的多路 RTP 流。

IPv6 与 UDP/TCP 双栈

mediasoup 支持 IPv6，并支持 ICE/DTLS/RTP/RTCP 同时运行于 UDP 与 TCP 之上。对应 worker 侧的网络实现见 UdpSocket.cpp、TcpServer.cpp、TcpConnection.cpp。

Simulcast 与 SVC

支持 Simulcast（多路空间分层同时发送）与 SVC（可伸缩视频编码）。worker 侧对应 SimulcastProducerStreamManager.cpp 与 SvcProducerStreamManager.cpp，Rust 侧示例 svc-simulcast.rs 演示了二者的实际用法。

拥塞控制与带宽估计

mediasoup 内置拥塞控制，并实现发送端与接收端带宽估计以及空间/时间层的分配算法。worker 侧有完整的 BWE（Bandwidth Estimation）模块：worker/src/RTC/BWE/ 下包含 AimdRateControl、DelayBasedBwe、LossBasedController、ProbeController、TrendlineEstimator、SendPacketHistory 等十余个实现文件，并通过 TransportCongestionControlClient.cpp / TransportCongestionControlServer.cpp 与 worker/deps/libwebrtc/ 下的 WebRTC 拥塞控制组件对接，可见其带宽控制能力直接复用了 WebRTC 生态的成熟算法。

数据通道（DataChannel）

支持三种数据消息交换途径：

1. WebRTC DataChannels（经 WebRtcTransport）；
2. SCTP over plain UDP（经 PlainTransport，对应 worker 侧 worker/src/SCTP/ 下自带的 SCTP 协议栈实现）；
3. 直接终止在 Node.js/Rust 进程内（对应 DataProducer/DataConsumer 实体，Node 侧见 DataProducer.ts、DataConsumer.ts）。

Node.js 侧还通过依赖 werift-sctp 提供 SCTP 相关能力（见 package.json 的 devDependencies 与 node/src/test/test-werift-sctp.ts）。

高性能 C++ 媒体引擎

媒体 worker 是运行在 libuv 之上的 C++ 线程/子进程，这一设计让媒体转发路径完全脱离 Node.js 事件循环的干扰，实现极致的媒体处理性能。构建与调试方式详见 doc/Building.md。

双语言形态：Node.js 模块与 Rust crate

mediasoup 的服务端 API 存在两种对等形态：

• Node.js 模块：源码位于 node/src/，TypeScript 编写，编译产物输出到 node/lib（对应 npm run typescript:build，见 doc/Building.md）。对外通过 exports 暴露主入口及 types、errors、ortc、extras 子路径。
• Rust crate：由三个 crate 组成（详见 doc/Rust-crates.md）：
  • mediasoup-sys：将 C++ worker 封装为 Rust 绑定；
  • mediasoup-types：定义并暴露 mediasoup 的 Rust 类型；
  • mediasoup：基于前两者提供 Idiomatic Rust 的用户 API。

当前仓库中 rust/Cargo.toml 表明 mediasoup crate 版本为 0.28.1，依赖 mediasoup-sys 0.18.1 与 mediasoup-types 0.5.0；Rust 形态还提供了 benchmarks（direct_data、producer 两个基准测试）与多个集成测试（rust/tests/integration/）。Rust crate 的发布流程（含依赖发布顺序、Cargo.lock 同步要求等）在 doc/Rust-crates.md 中有完整说明。

在线 Demo 与示例代码

README 提供了在线体验入口 v3demo.mediasoup.org（演示应用源码另行维护）。Demo 界面截图如下：

对于希望快速上手或深入理解 API 调用顺序的开发者，仓库本身就是最好的学习材料：

• Node.js 侧：集成测试覆盖了 Worker、Router、各 Transport、Producer/Consumer 与 RtpObserver 的全部核心功能，见 node/src/test/（如 test-Worker.ts、test-Router.ts、test-WebRtcTransport.ts）；
• Rust 侧：服务端示例见 rust/examples/，集成测试见 rust/tests/integration/。

项目信息：作者、协议与内部文档

• 作者：Iñaki Baz Castillo、José Luis Millán、Nazar Mokynskyi。
• 许可证：ISC，见仓库根目录 LICENSE。
• 版本记录：变更历史见 CHANGELOG.md（Node.js 模块）与 rust/CHANGELOG.md（Rust crate）。

针对 mediasoup 开发者的内部技术文档位于 doc/，包括：Building.md（构建与 npm/invoke 任务）、Rust-crates.md（Rust 三 crate 的发布机制）、Fuzzer.md（worker 模糊测试）、RTCP.md（RTCP 协议内部实现）、Closures.md 与 Charts.md。官方公开文档另行维护于 mediasoup.org，仓库内仅保留开发用内部文档。

小结

通过本文可以形成对 mediasoup 的完整认知：它是一个以 SFU 为核心、信令无关、API 低层的 WebRTC 媒体服务器，采用"Node.js/Rust 应用进程 + C++ worker 子进程"的分层架构，以 Worker/Router/Transport/Producer/Consumer 五类实体组织媒体转发逻辑，并原生支持多流复用、Simulcast/SVC、拥塞控制与带宽估计、DataChannel 数据交换等能力。无论选择 Node.js 还是 Rust 形态，其核心概念与调用流程一脉相承——以 rust/src/lib.rs 中的描述收尾最为贴切：先创建 WorkerManager 与 Worker，再在 Worker 上创建 Router，通过 Transport 注入（Producer）与提取（Consumer）媒体与数据流。

• 后端
• 音视频

【免费下载链接】mediasoup

Cutting Edge WebRTC Video Conferencing

项目地址： https://gitcode.com/gh_mirrors/me/mediasoup

点击查看 免费下载