canvas视频流与getUserMedia音频流合并对方无声(Kurento/WebRTC)

前端侧优先验证的常见坑 #

• 合流时的轨道顺序问题：Canvas生成的CanvasMediaStream是无真实硬件溯源的纯软视频流，这类轨道在WebRTC媒体栈的校验逻辑里优先级低于真实设备采集的硬轨道。如果合流时先把Canvas的视频轨加入新的MediaStream，再加入麦克风的音频轨，会让整个合并流的首个媒体轨道是无溯源的软视频，直接触发Kurento的校验规则——无真实设备关联的软视频轨不会被标记为合法的媒体源，同流中的音频轨会被判定为孤立轨道直接丢弃。
  对照测试结果能交叉验证这个逻辑：屏幕共享的视频轨属于真实设备触发的采集流，带硬件溯源标记，哪怕是纯屏幕共享无音频的场景，也不会被判定为非法源，所以同流中的音频能正常被识别转发；常规摄像头采集的视频轨同理，本身是硬轨道，不存在被丢弃的问题。
  验证时可以调整合流的轨道添加顺序，优先把音频轨放在轨道列表第一位，对应参考代码：

  const canvasStream = canvas.captureStream(30);
  const micStream = await navigator.mediaDevices.getUserMedia({ audio: true });
  // 错误写法：先加视频轨再加音频轨，触发校验异常
  // const mergedStream = new MediaStream([...canvasStream.getVideoTracks(), ...micStream.getAudioTracks()]);
  // 正确写法：先加音频轨再加视频轨
  const mergedStream = new MediaStream([...micStream.getAudioTracks(), ...canvasStream.getVideoTracks()]);
  

• 检查SDP协商时的媒体类型顺序：WebRTC的SDP协商会按轨道顺序生成媒体行，如果首个媒体行是无溯源的软视频，Kurento侧的媒体协商逻辑会默认按首个媒体行的类型初始化管道，忽略后续的音频通道，这也是Peer连接能正常建立但音频不通的典型原因——连接建立只校验信令通道，不校验实际媒体通道的初始化状态。

Kurento侧的校验排查方向 #

• 打开Kurento Media Server的调试日志，检查收到合并流时的轨道接收顺序，重点查找和音频轨状态相关的日志，确认是否存在音频轨因前置软视频轨被标记为未激活的条目。
• 临时验证方案：如果日志确认是轨道顺序导致的激活异常，可以调用Kurento WebRTC端点的setAudioSource接口，手动指定需要转发的音频轨道，跳过自动的顺序推断逻辑，测试音频是否能正常传输。

内容的提问来源于stack exchange，提问作者Shubham