大规模SFU音频会议多路音频流处理与NACK机制优化问询

核心判定逻辑优化方案 #

• 最直接的落地方式是服务端显式同步选流状态，从根源上消除歧义：
  • 媒体服务器为每路转发给客户端的音频流单独维护一套连续的转发序列号，和参会者上行的原始序列号做映射绑定，不要直接用上行原始序列号给客户端做连续性校验——毕竟选流阶段丢弃的音频包本来就不会下发，原始序列号必然存在跳变。
  • 选流结果变更时，通过自定义RTP扩展头或者轻量RTCP包，给客户端同步当前正在转发的参会者SSRC列表：客户端校验序列号时，仅对当前在转发列表内的流做连续性检查，出现跳变才判定为真实丢包，正常发送NACK；不在转发列表内的流直接跳过序列号校验，不触发重传请求，也不预留等待缓存。
• 大会议场景下可以用单流状态标记降低信令开销：
  • 不需要每次变更都发全量转发列表，某路流被挤出Top N选流范围时，服务端给对应客户端发一个1字节的轻量暂停转发标记；某路流重新进入选流范围时，发恢复转发标记即可。客户端收到暂停标记后，直接暂停对应流的丢包检测，直到收到恢复标记再重启校验，带宽开销比全量列表同步低90%以上，适合50人以上的大型会议。
• 加一层客户端兜底逻辑覆盖信令偶发丢失的极端情况：
  • NACK触发加双重判断阈值：不仅检测序列号跳变，还要确认跳变后连续200ms没有收到该流的任何媒体包、也没有收到服务端的状态标记，才真正发送重传请求。正常选流切换时，服务端要么提前发状态标记，要么切换后很快会下发新的媒体包，不会触发这个兜底阈值，完全可以覆盖信令丢包导致的状态不同步问题。

选流、混音参数优化建议 #

• 选流路数不要用固定值，按会议规模动态适配：
  • 10人以下小型会议：选流路数放开到8路，小会场景下终端混音算力足够，不会出现音量偏低的发言者被误切的问题。
  • 10-30人中型会议：维持4-6路的默认选流额度，优先保障音量最高的主流发言者。
  • 30人以上大型会议：基础选流额度降到3-4路，额外预留1个活跃用户兜底位——最近10秒内有过发言的用户，哪怕瞬时音量稍低，也优先保留10s的转发资格，避免刚开口音量还没抬升的用户被直接过滤。
• 选流判定不要只依赖瞬时音量，加滑动窗口做平滑：
  • 用300ms的滑动窗口计算每路流的平均音量再做排序，避免环境杂音、呼吸音导致的选流结果频繁跳变，减少客户端侧的声音切换卡顿。
• 混音阶段加平滑过渡避免听感突兀：
  • 新进入选流范围的音频流前100ms做淡入处理，被挤出选流范围的流做100ms淡出，不要硬切；同时给每路流做-3dB到0dB的自适应增益调整，避免不同发言者音量差过大导致的听感不适。

内容的提问来源于stack exchange，提问作者Nafiul Alam Fuji