WebRTC 添加轨道时如何通过替换空轨道避免renegotiation流程

方案1：占位轨道配合replaceTrack（首选，生产环境成熟） #

这是目前实现中途加流不触发协商的最优方案，你遇到的无法直接实例化MediaStreamTrack的问题，可以通过生成虚拟媒体源的方式解决：

• 视频占位轨道可以通过1x1透明canvas捕获流生成，音频占位轨道可以通过静音音频流生成，初始建立 PeerConnection 时就把对应kind的占位轨道加入，此时SDP里已经预留了对应媒体的m-line，后续替换轨道无需重新协商。
• 示例代码：

// 生成视频占位轨道
const createPlaceholderVideoTrack = () => {
  const canvas = document.createElement('canvas');
  canvas.width = 1;
  canvas.height = 1;
  const ctx = canvas.getContext('2d');
  ctx.fillStyle = 'transparent';
  ctx.fillRect(0, 0, 1, 1);
  const stream = canvas.captureStream(1); // 帧率设为1降低带宽占用
  const track = stream.getVideoTracks()[0];
  track.enabled = false; // 初始禁用，进一步降低资源占用
  return track;
}

// 初始建立语音通话时，就把占位视频轨道加入PeerConnection
const placeholderTrack = createPlaceholderVideoTrack();
peerConnection.addTrack(placeholderTrack, localStream);

// 后续需要开启视频时直接替换轨道即可，无需协商
const mediaStream = await navigator.mediaDevices.getUserMedia({video: true});
const realVideoTrack = mediaStream.getVideoTracks()[0];
const videoSender = peerConnection.getSenders().find(sender => sender.track?.kind === 'video');
await videoSender.replaceTrack(realVideoTrack);
realVideoTrack.enabled = true;

方案2：Data Channel 传输媒体流（不推荐，仅适合特殊场景） #

该方案理论可行，但生产环境落地成本很高：

• 实现逻辑是将音视频帧编码为二进制块，通过Data Channel定时发送，对端收到后解码渲染到canvas/audio元素，全程不需要走WebRTC的媒体协商流程。
• 缺陷明显：需要自行实现帧分片、丢包重传、音视频同步、编码优化等逻辑，高分辨率高帧率场景下延迟、卡顿问题远高于原生WebRTC媒体轨道，除非有特殊的自定义流需求，否则不建议使用。

注意事项 #

• 占位轨道的kind必须和后续要替换的真实轨道一致，视频占位轨道只能替换视频轨道，音频同理。
• 如果需要支持双向都中途开视频，双方初始化PeerConnection时都要添加对应占位轨道。

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