音视频练习实现基于mediasoup的sfu多人通话优化监控思路和断线问题

基于mediasoup已经实现了一个支持多人语音通话的sfu项目,再次回顾,对已知的几个问题进行优化:

1.考虑收集客户端网络和系统相关状态。

2.考虑观察服务端网络相关状态。

3.基本的防护考虑,在ice断开的情况下,在客户端切换网络的场景下业务的处理。

====》借助ai做项目实践,这里的内容也略感空泛,但总归是自己梳理思路处理的过程,做笔记进行备份。

1.总结

本来考虑的是基于已有的sfu功能,如何统计网络状态,再探索到网络断开问题,尝试基于已有的项目进行优化的问题。

不关注内部详细细节,以自己宏观的角度上分析一下该项目交互流。

2.实践回顾

1.客户端监控信息统计功能

这里实际上是由本地发送端链路和用于接收远端流的接收链路,分别统计其信息,定时器按需进行显示和打印:

核心需要统计的信息如下:

复制代码
发送质量(我的推流状况)
  qualityLimit  → 我的编码器是否被限制
  RTT           → 我到服务器的延迟
  send.jitter   → 我发出去的抖动
  retransmitted → 我重传了多少包

接收质量(我收到的每一路流)
  lossRate      → 每路流各自的丢包率
  jitterBuf     → 每路流各自的缓冲延迟
  fps           → 每路流各自的帧率
  nackCount     → 每路流触发了多少次重传请求
  pliCount      → 每路流触发了多少次关键帧请求

2.服务端的信息监控统计

提供专门的http服务入口,用于支持获取服务端本地必要的一些监控信息。

比如:通过url获取到服务器的一些必要监控信息:http://XXX.XXX.XXX.XXX:8445/health (代码中提供了接口),可以用其他接口获取房间信息等自己期望的信息,这里可以考虑扩展为一个监控系统。

复制代码
{
  "status": "ok",
  "timestamp": "2026-03-06T15:09:44.130Z",
  "workers": [
    {
      "pid": 2102963,
      "cpuMs": 0,
      "memMB": 13
    },
    {
      "pid": 2102965,
      "cpuMs": 0,
      "memMB": 10
    }
  ],
  "totals": {
    "rooms": 1,
    "peers": 2,
    "producers": 2,
    "consumers": 2
  }
}

3.房间断线重连机制

服务端提供了一个wss入口,供客户端主动连接,是所有开始的入口。

基于该wss入口,客户端通过协议控制实现加入房间,媒体协商,以及ice协商,创建发送链路和接收链路(流媒体交互链路,基于ice,一个链路发送多个流,SSRC识别)。

所以这里的断线有两种:

​ 第一:网络原因,流媒体交互链路异常,需要ice重新建链。

​ 第二:客户端切换网络,直接和服务器wss的链路断开。

====》虽然网络断开,但是可以根据服务端wss信息以及本地内存已经保存的信息进行恢复,全是代码控制细节逻辑,不涉及技术。

====》切换网络,涉及本地和服务端房间管理资源的清理和重置逻辑稍多。

复制代码
断线期间不能丢的状态:

myPeerId    → 我是谁,rejoin 用
myRoomId    → 我在哪个房间,rejoin 用
device      → 编解码能力,已经协商好,可以复用
camStream   → 摄像头的 MediaStream,track 还活着
micStream   → 麦克风的 MediaStream,track 还活着
camOn       → 摄像头是否开启的状态
micOn       → 麦克风是否开启的状态
muted       → 是否静音
remotePeers → 断线前房间里有哪些人(rejoin 后会用服务端数据更新)

断线时主动清理的状态(无法复用):

sendTransport   → IP 变了,必须重建
recvTransport   → IP 变了,必须重建
camProducer     → Transport 销毁后自动失效
micProducer     → Transport 销毁后自动失效
consumers       → Transport 销毁后自动失效
pendingReqs     → WSS 断了,所有等待中的请求全部 reject
4:简单运行效果

测试观察过监控效果,以及断线重连等问题,都已经正常。

目标关注问题相关测试代码问题已经修改,测试已经通过:demo

相关推荐
日光明媚21 小时前
深度解析 SGLang 框架 Wan2.1 视频生成加速技术:从 49 分钟到 1 分钟的极致优化
人工智能·计算机视觉·aigc·音视频·sglang
小猿君21 小时前
谷歌I/O前夜Veo 4遭泄露,AI视频底层逻辑浮出水面
人工智能·音视频
南山有乔木78921 小时前
音频怎么转换MP3格式?M4A、WAV、FLAC转mp3实测有效的格式转换方法
音视频
不昀21 小时前
音频变压器Bourns SM-LP-5001国产替代选型指南
网络·音视频·以太网·网络通信·电子元器件
REDcker21 小时前
RGB与YUV像素格式详解
音视频·实时音视频·视频编解码·yuv·rgb
水上冰石21 小时前
v1-5-pruned-emaonly.safetensors 搭配mm_sd_v15_v2.ckpt 生成视频,具体操作步骤
stable diffusion·音视频·文生视频
searchforAI21 小时前
我用这款本土NotebookLM平替重构了知识库
人工智能·笔记·gpt·ai·音视频·知识图谱
美狐美颜SDK开放平台1 天前
美颜SDK开发详解:如何优化美颜SDK在低端安卓机上的性能?
android·ios·音视频·直播美颜sdk·视频美颜sdk
wj3055853781 天前
课程 6:图生视频首次运行流程
人工智能·音视频
runafterhit1 天前
显示调研专题-OLED 终端市场分析报告
音视频