Mediasoup RTP 流类型详解：从 Opus、RTX 到 Simulcast 配置实践-北京尧图网络

做 WebRTC 服务端的人迟早会和 Mediasoup 这个库打交道。前阵子帮某团队验证一个多房间音视频服务我翻着mediaCodecs配置时突然意识到一个问题大家都在说“Mediasoup 支持哪些 RTP 流类型”可 RTP 流类型到底是什么是一个音频流加一个视频流就完事了吗后来排查弱网丢包又把 RTX、RED、RTP 头扩展这些概念重新捋了一遍才算真正把这条链路看明白。如果你也准备用 Mediasoup 搭 SFU或者已经在用但总被参数绕晕这篇文章就是给你写的。我会把 audio、video、RTX、RED、RTP 头扩展、Simulcast、SVC 这些流类型掰开讲清楚并给出能直接抄的配置和验证方法。先说结论Mediasoup 支持的 RTP 流类型本质上是 WebRTC 世界里你能遇见的几乎所有常见 RTP 形态。它不像 MCU 那样会转码而是像一个聪明的快递分拣员把上游来的 RTP 包按需转发给下游。所以理解流类型就是理解哪些包能进来、哪些包能出去、以及怎么让它们不丢失、不乱序、不卡顿。1. 先从一条 RTP 流讲起1.1 什么是 RTP 流Mediasoup 里怎么抽象RTPReal-time Transport Protocol是音视频传输的底层协议。一次通话里的音频或视频实际上是一连串按时间顺序发送的 RTP 数据包。每个包都有自己的 SSRC同步源标识、Payload Type负载类型、序号和时间戳这四个信息共同构成了一条流的“身份证”。Mediasoup 的抽象方式很直接一个 Producer 对应一条上游 RTP 流一个 Consumer 对应一条下发到接收端的 RTP 流。发送端把 RTP 包推到 MediasoupMediasoup 解包、缓存、按需转发接收端再从 Consumer 拉取。整个过程里Mediasoup 不做编码转换默认情况下也不修改 RTP 包的内容所以它的“支持流类型”更多是指它能够识别、转发哪些 RTP 格式以及如何处理冗余和重传。这里有一个容易混淆的概念一条 Producer 不一定只承载一条 RTP 流。尤其是在 Simulcast 场景里一个视频 Producer 可以同时携带多路不同分辨率的 RTP 流每路流都有独立的 SSRC 和 rid。Mediasoup 里的encodings数组就是用来描述这种流组织方式的。1.2 实际会碰到的 RTP 流类型清单我按项目经验把 Mediasoup 相关配置里常出现的 RTP 流类型整理了一下你可以把它当成一个速查表类型承载内容典型用途常见编码音频流声音数据通话、会议、语音直播Opus、PCMU、PCMA、telephone-event视频流画面数据摄像头、屏幕共享、视频播放VP8、VP9、H264、H265/AV1视版本冗余流低优先级冗余副本弱网抗丢包audio/red重传流原始 RTP 包的重传副本NACK 丢包恢复RTX按主编码的 apt 关联前向纠错流FEC 冗余包网络抖动与突发丢包ulpfec、flexfecRTP 头扩展流内元数据拥塞控制、Simulcast 标识、音量探测abs-send-time、transport-cc、mid、rid 等注意RTX、RED、FEC 通常不是独立业务流而是和主音频流、主视频流绑定在一起。Mediasoup 在转发时会把它们当作同一会话的一部分但如果你没有在 RTP 参数里正确声明这些增强流就会被直接丢掉。2. 音频 RTP 流默认只有 Opus 是不够的2.1 一套能跑通的 Opus 配置Mediasoup 的 Router 在创建时需要声明自己支持哪些媒体能力。音频方面绝大多数项目默认只声明 Opus因为 WebRTC 浏览器都支持而且 Opus 的音质在低码率下依然能打。声明方式如下{ kind: audio, mimeType: audio/opus, clockRate: 48000, channels: 2, parameters: { useinbandfec: 1, usedtx: 1 } }这里的useinbandfec表示 Opus 支持带内前向纠错也就是把上一帧的一部分冗余信息塞进当前 RTP 包里丢包时解码器还能凑合还原一些声音。usedtx是静音检测说话间歇不传数据能省不少带宽。这两个参数不是 Mediasoup 的强制要求但我建议默认开上尤其是面向移动网络的场景。很多坑并不是出在 Opus 本身而是出在 payload type 上。Mediasoup 支持动态 payload type默认会自动分配。如果同一个 Router 里跑了多个房间或者你有多个 Worker最好手动固定preferredPayloadType比如音频用 111、视频用 96避免不同 Worker 返回不一致导致客户端不认识。2.2 除了 Opus还有 G.711 和 DTMF如果你的服务要对接 PSTN 网关、SIP 话机或者老式硬件终端只支持 Opus 是不够的。这些设备通常只支持 G.711 编码也就是 PCMU 和 PCMA也就是纯 PCM无压缩但在网络带宽足够时延迟极低。声明方式也很简单{ kind: audio, mimeType: audio/PCMU, clockRate: 8000, channels: 1 }另一个容易被忽略的是telephone-event也就是 DTMF 按键音。很多电话场景里用户按的数字键不是通过普通音频流传输的而是通过 RTP 的 telephone-event 包传输。如果你没有在 Router 的mediaCodecs里声明它线上电话的按键就会失灵而且从日志上几乎看不出问题。2.3 音频流容易忽略的细节音频流的 RTP 参数比视频简单但有两个细节值得注意。第一Opus 的channels必须和实际编码器一致。大多数 WebRTC 客户端用双声道模式但有些硬件终端只发单声道。如果你强制路由器只支持双声道单声道设备协商直接失败。我的习惯是 Router 层声明双声道但在客户端rtpParameters里以实际上报为准交给 Mediasoup 的校验逻辑去处理。第二RED 和 Opus 的配合。音频 RED 不是独立编码而是把一个主 Opus 包和一个冗余 Opus 包打包在同一个 RTP 时间戳里。这种方式在丢包严重的网络里比 usedtx 更可靠但因为多传了一份数据带宽占用会上升。我建议在普通 WiFi 场景先不开 RED等发现音频抖动明显再动态声明audio/red。3. 视频 RTP 流一堆参数背后是编码器的脾气3.1 视频编码能力怎么声明视频流的配置比音频复杂得多因为你不仅要声明编码格式还要声明打包方式、反馈机制、编码档位。最常见的视频流类型是 VP8 和 H264VP9 和 H265 通常用于高码率直播或特定终端。最小化配置如下{ kind: video, mimeType: video/VP8, clockRate: 90000, rtcpFeedback: [ { type: nack, parameter: }, { type: nack, parameter: pli }, { type: ccm, parameter: fir } ] }视频的时钟频率固定是 90000这个不要改。rtcpFeedback很关键它决定了接收端丢包时能不能通过 RTCP 消息告诉发送端“我丢了关键帧”。如果你去掉nack pli和ccm fir视频在丢包后很可能长时间黑屏因为解码器等不到关键帧就无法恢复画面。H264 的声明会再多两个参数{ kind: video, mimeType: video/H264, clockRate: 90000, parameters: { packetization-mode: 1, profile-level-id: 42e01f } }packetization-mode必须为 1表示使用非交错模式把 NAL 单元按顺序放入 RTP 包这是 WebRTC 的默认要求。profile-level-id代表编码档位和级别最常见的42e01f是 Constrained Baseline Profile Level 3.1兼容性最好。如果客户端上报的 H264 profile 和你的不一致协商会静默失败表现就是浏览器推流成功但别人看不到。3.2 视频流里的关键帧机制视频 RTP 流里有一个看不见但非常重要的角色关键帧也就是 I 帧。视频编码是帧与帧之间有依赖关系的P 帧必须依赖前面的关键帧或参考帧才能解出来。如果某个关键帧在网络上丢了接收端会一直花屏直到下一个关键帧到来。Mediasoup 本身不产生关键帧但它会转发 RTCP 反馈。当 Consumer 侧接收端丢了太多包时它可以通过nack pli或ccm fir请求上游重新发送一个关键帧。这就是为什么rtcpFeedback必须配置正确。很多只在小网段测试的人会忽略这个觉得画面正常一到公网就翻车。3.3 一条视频流还是多条视频流encodings 决定在 Mediasoup 里视频 Producer 的encodings数组直接决定是一条流还是多条流。单路模式只写一个 encodingencodings: [ { rid: r0, maxBitrate: 1500000 } ]如果你希望的是 Simulcast就写多个encodings: [ { rid: r0, maxBitrate: 300000, scaleResolutionDownBy: 4 }, { rid: r1, maxBitrate: 900000, scaleResolutionDownBy: 2 }, { rid: r2, maxBitrate: 2500000, scaleResolutionDownBy: 1 } ]每个 rid 对应一路独立 RTP 流。scaleResolutionDownBy表示把原始分辨率缩小多少倍比如 4 就是把 1280x720 缩到 320x180。maxBitrate的单位是 bps不是 kbps。我见过不少人把 300000 当 300kbps 用实际它只是 300kbps。如果你想让这一路跑 1Mbps就写 1000000。4. RTX、RED、RTP 头扩展容易被当空气却不能当空气4.1 RTX 重传流丢包时的后悔药视频 RTP 流在网络传输中会丢包。丢包后接收端可以在 RTCP 里发 NACK 请求重传但 RTP 原始序号已经不在发送缓存里了所以需要一条专门的重传流这就是 RTX。Mediasoup 的 RTX 配置挂在rtpParameters.encodings上{ rid: r1, ssrc: 111111, rtx: { ssrc: 222222, payloadType: 97 } }主流的 SSRC 是 111111RTX 流的 SSRC 是 222222。当接收端 NACK 某个序号时发送端会通过 RTX 流把原始 RTP 包重新发出去RTX 包里会带一个 OSN 字段用来告诉接收端“这个重传的包本来应该插在原始序号哪个位置”。在 Mediasoup 里你不需要自己解析 OSN它会维护主 SSRC 和 RTX SSRC 的映射。但你要确保客户端上报的rtx参数没有被丢掉。因为我见过一些第三方的 WebRTC SDK 默认关闭 RTX导致弱网下视频恢复速度极慢。没有 RTX视频卡顿后只能等下一个关键帧有了 RTX丢包后几百毫秒内就能补回来。视频场景我强烈建议保留 RTX。4.2 RED 与 FEC冗余不是越多越好RED 是音频专用的冗余容器它本身不编码而是把主编码数据和冗余数据打包在一起。比如你可以声明一个audio/redcodec它的 payload 里包含一个 Opus 主包和一个 Opus 冗余包。Mediasoup 遇到 RED 包时会把它当作普通 RTP 流转发并不会拆开重组。视频的 FEC 类似 ulpfec、flexfec。FEC 流的逻辑是把 n 个原始包编码成 nk 个包接收端只要收到足够多包就能解出全部原始数据。Mediasoup 本身不生成 FEC也不会强制协商 FEC但如果上游把 FEC 包发过来了并且协商通过它会按照 RTP 转发规则处理。我的建议是不要把 RED 和 FEC 当作默认选项。冗余流会占用大量额外带宽通常只有在网络丢包率超过 5% 时才划算。如果你的业务主要跑在办公网络单开 Opus 和 RTX 就够了。4.3 RTP 头扩展一条流里的元数据通道RTP 包头部除了固定字段还可以带一堆扩展字段。这些扩展不是媒体内容但它们是 Mediasoup 做拥塞控制和流识别的重要依据。实际项目里最常见的头扩展 URI 有URI 标识作用urn:ietf:params:rtp-hdrext:ssrc-audio-level音频音量级别用于语音活动检测http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time发送端绝对时间戳用于延迟估算http://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-02transport-cc用于带宽估计和拥塞控制urn:ietf:params:rtp-hdrext:sdes:midBundle 标识用于多路流复用urn:ietf:params:rtp-hdrext:sdes:rtp-stream-idrid用于 Simulcast 流识别Mediasoup 在创建 Transport 和 Router 时会根据端点上报的rtpCapabilities来决定启用哪些头扩展。大多数时候你不需要手动去改但如果你在做带宽自适应调优一定要保证transport-cc没有被客户端关掉。没有 transport-ccMediasoup 的拥塞控制算法基本就是瞎子。5. Simulcast 和 SVC多路流和分层流的选型5.1 Simulcast多路独立 RTP 流同时发Simulcast 的原理很简单发送端同时通过编码器生成多路不同分辨率和码率的 RTP 流每路流拥有独立的 SSRC 和 rid。比如一个 1080p 的摄像头流可以同时发三路180p、720p、1080p。SFU 收到三路流之后根据接收端网络情况决定转发哪一路。接收端网络差就切到低分辨率网络好就切到高分辨率切换过程几乎无感。Mediasoup 对 Simulcast 的支持非常成熟。你只需要在encodings里按顺序声明 rid客户端就会自动把对应的分辨率映射到 rid 上。Consumer 端切换层的代码是这样await consumer.setPreferredLayers({ spatialLayer: 1, temporalLayer: 0 });spatialLayer对应分辨率层temporalLayer对应帧率层。在多人会议里Simulcast 是保证每个参会者都能获得合适画质的基础。5.2 SVC一条流里的分层结构SVC 的思路不一样。它只有一条 RTP 流但是这个流内部的数据是分层的。比如 VP9 SVC 会把画面分成基础层和增强层接收端只看基础层能出低清画面再叠加增强层就能得到高清画面。Mediasoup 里声明 SVC 主要靠scalabilityModeencodings: [ { rid: r0, scalabilityMode: L1T3, maxBitrate: 2500000 } ]L1T3表示 1 个空间层、3 个时间层。空间层是分辨率维度时间层是帧率维度。Consumer 端同样可以用setPreferredLayers选择想收哪一层。SVC 的优点是节省整体带宽因为它不需要重复编码多路缺点是编码器复杂度高很多移动端设备硬件编码不支持。5.3 Simulcast 和 SVC 的对比与选型对比维度SimulcastSVC编码器开销多个分辨率同时编码CPU/GPU 高单流编码开销相对低带宽占用多路同时传输总量高分层传输基础层和增强层总量可控客户端兼容WebRTC 浏览器原生支持好VP9 SVC 兼容范围有限切换粒度按完整层切换清晰容易判断按子层切换更细腻Mediasoup 支持成熟稳定支持但对编码器有要求我的选型经验是面向通用 WebRTC 浏览器端默认 Simulcast 最稳如果你们是自研终端视频编码器也确认支持 SVC再考虑 SVC。不要因为 SVC 听起来更省带宽就直接换先做终端兼容性测试再说。6. 实操把 RTP 流类型配置落到实处6.1 最小可用的 Router 配置下面是我平时调试时的最小 Router 配置。先创建一个 Worker然后声明 Router 支持的 mediaCodecsimport { createWorker } from mediasoup; const worker await createWorker(); const mediaCodecs [ { kind: audio, mimeType: audio/opus, clockRate: 48000, channels: 2, parameters: { useinbandfec: 1, usedtx: 1 } }, { kind: video, mimeType: video/VP8, clockRate: 90000, rtcpFeedback: [ { type: nack, parameter: }, { type: nack, parameter: pli }, { type: ccm, parameter: fir } ] }, { kind: video, mimeType: video/H264, clockRate: 90000, parameters: { packetization-mode: 1, profile-level-id: 42e01f }, rtcpFeedback: [ { type: nack, parameter: }, { type: nack, parameter: pli }, { type: ccm, parameter: fir } ] } ]; const router await worker.createRouter({ mediaCodecs });这套配置覆盖了 90% 的浏览器推流场景。如果你要对接自家 App可以再追加 VP9。切记不要把所有支持的 codec 都堆上去因为每次协商都需要遍历能力集codec 越多、歧义越多。6.2 创建 Producer 并控制流形态WebRTC 客户端推流时会通过信令发给服务端一份rtpParameters。服务端校验通过后调用transport.produceconst producer await transport.produce({ kind: video, rtpParameters: { codecs: [ { mimeType: video/VP8, clockRate: 90000, payloadType: 96, rtcpFeedback: [ { type: nack, parameter: }, { type: nack, parameter: pli }, { type: ccm, parameter: fir } ] } ], encodings: [ { rid: r0, maxBitrate: 300000, scaleResolutionDownBy: 4 }, { rid: r1, maxBitrate: 900000, scaleResolutionDownBy: 2 }, { rid: r2, maxBitrate: 2500000, scaleResolutionDownBy: 1 } ] } });这里要注意codecs数组里的payloadType必须和实际协商值一致不能自己随便写一个客户端不支持的数字。encodings的顺序也重要Mediasoup 和浏览器约定 rid 从低到高对应低分辨率到高分辨率。如果你反过来写客户端可能直接拒绝推流。6.3 用 getStats 和抓包验证一条 RTP 流是否生效配置做完之后别急着乐先验证。Mediasoup 的 Producer 自带统计信息const stats await producer.getStats(); console.log(stats);你会看到类似bitrate、bytesReceived、packetsLost、ssrc这样的字段。重点关注ssrc是否和你预期的一致以及bytesReceived是否在持续增长。如果一个 Producer 建好了但bytesReceived永远是 0说明它的 RTP 流根本没进来。如果想看网络层细节用 Wireshark 抓包最直观。过滤条件可以写rtp ip.addr 服务器IP抓完看 payload type 和 SSRC。如果视频流一直是黑屏抓包里找 RTCP PLI 消息看看有没有周期性请求关键帧请求如果有请求但没有收到对应的大 I 帧问题大概率在上游编码器而不是 Mediasoup。7. 踩坑实录RTP 流类型相关的常见问题7.1 常见问题速查表现象可能原因解决办法客户端没有声音Router 没声明 Opus 或 payloadType 冲突检查mediaCodecs固定preferredPayloadType视频黑屏但流在走H264 profile-level-id 不匹配或没有 PLI/FIR 反馈统一用42e01f确保rtcpFeedback完整丢包后视频恢复极慢客户端没启用 RTX检查encodings里的rtx配置确认协商成功Simulcast 只有一层rid 顺序错误或接收端不支持按低到高排列 rid通过setPreferredLayers验证音频在弱网下断续严重没开 Opus inband FEC或没声明 RED开启useinbandfec按需声明audio/redWebRTC 协商失败router.rtpCapabilities与客户端能力不匹配确保服务端返回的rtpCapabilities是 Router 实例直接导出的7.2 排查思路与工具排查 RTP 流类型问题我一般按三层走。第一层是 Mediasoup 日志。启动服务时带上DEBUGmediasoup*能看到每个 Producer 和 Consumer 的事件。重点是看worker是否报告 RTP 流 SSRC 错误或者 payloadType 不支持。第二层是 Mediasoup 的内部转储。调用router.dump()可以看到路由下的所有 Transport、Producer、Consumer 状态。这个命令在生产环境慎用但调试阶段非常好用能直接确认哪条流没有进来。第三层是浏览器端。打开浏览器内置的webrtc-internals页面看 inbound-rtp 和 outbound-rtp 的字段。比如视频方向你能看到framesDecoded是否在增长。如果framesDecoded一直不变但bytesReceived在涨说明收到了 RTP 包但解码器没能解出帧大概率是 H264 的参数不对。7.3 经验只声明你真正用得到的 RTP 流类型最后分享一个重要经验不要为了“支持更多设备”就把所有 RTP 流类型全声明一遍。RTP 流类型的组合复杂度是乘积级别的。你多声明一个 H265就要多维护一组 profile 兼容表多声明一个 RED就要考虑客户端是否支持冗余解码多声明一个 FEC就要评估带宽增长是否值得。我现在的做法是每个项目先做一个 RTP 流类型核对表把“必须支持、可选支持、明确不支持”三类列清楚。默认只开 Opus VP8 H264 RTX遇到具体业务需求再加 VP9、RED、Simulcast。核对这些配置的过程看起来很琐碎但它能帮你省下大量线上问题排查时间。做 WebRTC 服务RTP 流类型不是理论概念是每天都在跟丢包和协商打交道的实际工程问题。

Mediasoup RTP 流类型详解：从 Opus、RTX 到 Simulcast 配置实践

相关推荐

EpiLang：专为批量书名生成而设计的极简领域特定语言

gcc/g++/cmake工具链安装、验证与排错全指南

AI智能体循环工程-第7章第6节-验证工程-失败信息工程报错就是给模型的提示词

更多资讯

开放式代码评审：从理念到落地的高效工程实践

SAP物料编号范围配置原理与实战避坑指南

diagram-design：从规范到组件，搭建统一图表设计体系

数码管识别为何不用OCR？OpenCV+轻量CNN实战方案

Docker入门实战：从镜像容器到Compose编排，解决环境一致性问题

DeskcommCRM实战：销售自动化配置、数据清洗与团队落地全记录

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？