在 mediasoup 的架构中媒体流评分机制通过实时处理 RTCP 报文来动态评估传输通道的质量其核心在于对接收端反馈的统计数据进行周期性的聚合与分析。该机制主要依据 RTCP 接收者报告Receiver Report, RR和发送者报告Sender Report, SR中携带的丢包率、延迟抖动、累计丢包数等关键指标通过加权算法计算出代表当前流传输质量的 score 值。该评分体系被设计为一种归一化的评估模型其数值范围通常设定在 0 至 10 之间其中较高的分数表征更优的传输性能。RTCP 报文在 mediasoup 中的处理流程始于WebRtcTransport::OnPacketReceived方法该方法对传入的数据包进行协议类型鉴别。当识别出 RTCP 报文后会将其路由至专门的 RTCP 处理器。RTCP 报文解析后其内部的有效载荷数据会被提取并传递至评分计算模块。具体而言mediasoup 会从 RTCP RR 报文中提取以下字段用于评分计算丢包率Fraction Lost反映短期内的数据包丢失比例是评估网络拥塞状况的直接指标。累计丢包数Cumulative Number of Packets Lost提供自会话开始以来的总体丢包情况用于评估长期传输稳定性。扩展的最高序列号Extended Highest Sequence Number Received用于推导实际接收到的数据包数量结合累计丢包数可计算总体丢包率。抖动Interarrival Jitter表示数据包到达时间的偏差是衡量网络延迟波动的重要参数。最后发送者报告时间戳Last SR Timestamp, LSR与延迟自最后发送者报告Delay Since Last SR, DLSR这两个字段用于计算往返时间RTT但需注意RTT 的计算需要发送端配合并非所有实现都直接用于基础评分。mediasoup 的评分算法并非简单的线性映射而是基于上述多个维度构建的一个复合函数。其设计原则是对网络损伤敏感即当丢包率或抖动增加时score 应显著下降同时算法需具备一定的惯性避免因瞬时波动导致评分剧烈震荡通常采用滑动窗口或指数加权移动平均EWMA对原始指标进行平滑处理。一个简化的、用于说明核心逻辑的评分计算伪代码如下所示实际 mediasoup 实现更为复杂且权重参数可能因版本或配置而异// 伪代码演示基于RTCP RR的评分计算核心逻辑 float calculateScoreFromRtcpReport(const RtcpReceiverReport report) { // 1. 提取关键指标 float fractionLost report.fractionLost / 256.0f; // 转换为比例范围[0,1] uint32_t cumulativeLost report.cumulativeLost; uint32_t extendedHighSeq report.extendedHighSeqNum; uint32_t jitter report.jitter; // 以时间戳单位表示 // 2. 计算衍生指标示例 float packetLossRate fractionLost; // 短期丢包率 // 注意实际长期丢包率可能由 cumulativeLost 和 extendedHighSeq 推导 float normalizedJitter static_castfloat(jitter) / kNormalizationFactor; // 归一化抖动 // 3. 应用权重计算基础分数权重值W为示例 const float W_LOSS 0.6f; const float W_JITTER 0.3f; const float W_OTHER 0.1f; // 可能包含其他指标如RTT float baseScore 10.0f; // 起始满分 baseScore - (packetLossRate * 10.0f * W_LOSS); // 丢包惩罚 baseScore - (normalizedJitter * 10.0f * W_JITTER); // 抖动惩罚 // 其他指标惩罚... // 4. 边界处理与平滑 baseScore std::max(0.0f, std::min(10.0f, baseScore)); // 钳制在[0,10] // 实际实现中此处会与历史score进行平滑如EWMA // currentSmoothedScore alpha * baseScore (1 - alpha) * previousSmoothedScore; return baseScore; }评分更新的触发时机与 RTCP 报文的接收频率直接相关。根据 RFC 3550RTCP 报文的发送间隔应自适应地控制在会话带宽的 5% 左右这意味着在稳定的视频会议中评分会以大约每秒数次的频率进行更新。每次接收到有效的 RTCP RR 报文便会触发一次评分重计算。更新后的 score 值会即时反馈给 mediasoup 的上层逻辑用于决策例如传输优化当某条流的 score 持续低于阈值时可能触发传输策略调整如切换 ICE 候选对、调整 DSCP 标记或通知发送端调整编码比特率。流切换在 simulcast 或 SVC 场景中接收端可能会基于各层/各流的 score 选择订阅质量最优的流。质量监控与告警服务端可聚合所有参与者的 score形成全局视图用于监控房间整体通话质量。该评分机制是 mediasoup 实现智能传输控制的关键环节它将低层次的网络统计信息转化为高层次的、可操作的质量度量使得系统能够自适应网络变化优化用户体验。参考来源流媒体服务器20—— mediasoup 之媒体流score评分计算一
mediasoup如何基于RTCP更新媒体流score
发布时间：2026/6/1 7:41:08
在 mediasoup 的架构中媒体流评分机制通过实时处理 RTCP 报文来动态评估传输通道的质量其核心在于对接收端反馈的统计数据进行周期性的聚合与分析。该机制主要依据 RTCP 接收者报告Receiver Report, RR和发送者报告Sender Report, SR中携带的丢包率、延迟抖动、累计丢包数等关键指标通过加权算法计算出代表当前流传输质量的 score 值。该评分体系被设计为一种归一化的评估模型其数值范围通常设定在 0 至 10 之间其中较高的分数表征更优的传输性能。RTCP 报文在 mediasoup 中的处理流程始于WebRtcTransport::OnPacketReceived方法该方法对传入的数据包进行协议类型鉴别。当识别出 RTCP 报文后会将其路由至专门的 RTCP 处理器。RTCP 报文解析后其内部的有效载荷数据会被提取并传递至评分计算模块。具体而言mediasoup 会从 RTCP RR 报文中提取以下字段用于评分计算丢包率Fraction Lost反映短期内的数据包丢失比例是评估网络拥塞状况的直接指标。累计丢包数Cumulative Number of Packets Lost提供自会话开始以来的总体丢包情况用于评估长期传输稳定性。扩展的最高序列号Extended Highest Sequence Number Received用于推导实际接收到的数据包数量结合累计丢包数可计算总体丢包率。抖动Interarrival Jitter表示数据包到达时间的偏差是衡量网络延迟波动的重要参数。最后发送者报告时间戳Last SR Timestamp, LSR与延迟自最后发送者报告Delay Since Last SR, DLSR这两个字段用于计算往返时间RTT但需注意RTT 的计算需要发送端配合并非所有实现都直接用于基础评分。mediasoup 的评分算法并非简单的线性映射而是基于上述多个维度构建的一个复合函数。其设计原则是对网络损伤敏感即当丢包率或抖动增加时score 应显著下降同时算法需具备一定的惯性避免因瞬时波动导致评分剧烈震荡通常采用滑动窗口或指数加权移动平均EWMA对原始指标进行平滑处理。一个简化的、用于说明核心逻辑的评分计算伪代码如下所示实际 mediasoup 实现更为复杂且权重参数可能因版本或配置而异// 伪代码演示基于RTCP RR的评分计算核心逻辑 float calculateScoreFromRtcpReport(const RtcpReceiverReport report) { // 1. 提取关键指标 float fractionLost report.fractionLost / 256.0f; // 转换为比例范围[0,1] uint32_t cumulativeLost report.cumulativeLost; uint32_t extendedHighSeq report.extendedHighSeqNum; uint32_t jitter report.jitter; // 以时间戳单位表示 // 2. 计算衍生指标示例 float packetLossRate fractionLost; // 短期丢包率 // 注意实际长期丢包率可能由 cumulativeLost 和 extendedHighSeq 推导 float normalizedJitter static_castfloat(jitter) / kNormalizationFactor; // 归一化抖动 // 3. 应用权重计算基础分数权重值W为示例 const float W_LOSS 0.6f; const float W_JITTER 0.3f; const float W_OTHER 0.1f; // 可能包含其他指标如RTT float baseScore 10.0f; // 起始满分 baseScore - (packetLossRate * 10.0f * W_LOSS); // 丢包惩罚 baseScore - (normalizedJitter * 10.0f * W_JITTER); // 抖动惩罚 // 其他指标惩罚... // 4. 边界处理与平滑 baseScore std::max(0.0f, std::min(10.0f, baseScore)); // 钳制在[0,10] // 实际实现中此处会与历史score进行平滑如EWMA // currentSmoothedScore alpha * baseScore (1 - alpha) * previousSmoothedScore; return baseScore; }评分更新的触发时机与 RTCP 报文的接收频率直接相关。根据 RFC 3550RTCP 报文的发送间隔应自适应地控制在会话带宽的 5% 左右这意味着在稳定的视频会议中评分会以大约每秒数次的频率进行更新。每次接收到有效的 RTCP RR 报文便会触发一次评分重计算。更新后的 score 值会即时反馈给 mediasoup 的上层逻辑用于决策例如传输优化当某条流的 score 持续低于阈值时可能触发传输策略调整如切换 ICE 候选对、调整 DSCP 标记或通知发送端调整编码比特率。流切换在 simulcast 或 SVC 场景中接收端可能会基于各层/各流的 score 选择订阅质量最优的流。质量监控与告警服务端可聚合所有参与者的 score形成全局视图用于监控房间整体通话质量。该评分机制是 mediasoup 实现智能传输控制的关键环节它将低层次的网络统计信息转化为高层次的、可操作的质量度量使得系统能够自适应网络变化优化用户体验。参考来源流媒体服务器20—— mediasoup 之媒体流score评分计算一
