如何停止向单个WebRTC对等端发送视频轨道而不影响其他对等端？

为什么设置sentTrack.enabled = false会影响所有对等端？ #

MediaStreamTrack的enabled状态是全局的，所有关联这个轨道的PeerConnection都会同步这个状态，所以一旦设为false，所有接收方都会停止收到视频。

仅停止向单个对等端发送视频的方法 #

不需要重新捕获新的流/轨道，用以下两种方案即可：

方案1：从目标PeerConnection中移除视频轨道

添加轨道到PeerConnection时，会返回一个RTCRtpSender对象，你需要把每个PeerConnection对应的sender保存起来（比如用Map<RTCPeerConnection, RTCRtpSender>存储）。之后要停止给某个对等端发视频时，调用：

// targetPeer是要停止的对等连接，sender是之前保存的对应视频轨道的sender
targetPeer.removeTrack(sender);

如果之后需要恢复发送，重新调用addTrack把原轨道加回去就行。

方案2：给目标对等端替换成静音轨道

创建一个静音的视频轨道，然后替换目标PeerConnection中的原轨道：

// 创建静音视频轨道的工具函数
function createSilentVideoTrack() {
  const canvas = document.createElement('canvas');
  canvas.width = 1;
  canvas.height = 1;
  const ctx = canvas.getContext('2d');
  ctx.fillStyle = '#000';
  ctx.fillRect(0, 0, 1, 1);
  return canvas.captureStream().getVideoTracks()[0];
}

// 替换轨道
const silentTrack = createSilentVideoTrack();
sender.replaceTrack(silentTrack); // sender是目标对等端对应的RTCRtpSender

// 恢复原轨道的话，再调用一次replaceTrack
// sender.replaceTrack(originalSentTrack);

这种方式的好处是不需要移除再添加，状态切换更平滑。

是否需要为每个用户捕获单独的流/轨道？ #

完全不需要。上面的两种方案都基于原有的单个捕获轨道就能实现，不需要额外从摄像头获取新流。只有当你需要给不同用户提供差异化的视频参数（比如不同分辨率、帧率）时，才需要考虑单独捕获，但这属于特殊场景。

多流/轨道会增加处理器负载吗？ #

• 如果是多次调用getUserMedia捕获多个独立轨道：会显著增加CPU负载，因为摄像头需要为每个轨道单独编码，系统资源消耗会翻倍甚至更多。
• 如果是用clone()复制原轨道：负载增加极小，因为克隆后的轨道共享底层的媒体源，只是上层的状态（比如enabled）是独立的，编码工作还是由原轨道完成。
• 如果是使用静音轨道这类虚拟轨道：几乎不会增加负载，因为这类轨道不需要摄像头硬件参与，仅靠canvas生成静态帧，资源占用可以忽略。

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