基于getUserMedia()与WebRTC，能否在发送前修改媒体缓冲区？

完全可以在getUserMedia()获取的媒体流与WebRTC发送链路之间插入自定义处理逻辑，实现对媒体数据的修改（比如你说的base64编码/解码），且上层业务代码完全不需要感知这个过程。

核心实现思路：使用TransformStream处理媒体轨道 #

现代浏览器支持MediaStreamTrackProcessor和MediaStreamTrackGeneratorAPI，能轻松构建媒体流的处理管道，把原始轨道转换成经过自定义处理的轨道，再传给WebRTC的PeerConnection。这种方式对上层完全透明，业务代码只需要使用处理后的轨道即可。

发送端：对视频帧进行base64编码处理

// 1. 获取原始视频轨道
const stream = await navigator.mediaDevices.getUserMedia({ video: true });
const originalTrack = stream.getVideoTracks()[0];

// 2. 创建处理器和生成器，构建处理管道
const processor = new MediaStreamTrackProcessor({ track: originalTrack });
const generator = new MediaStreamTrackGenerator({ kind: 'video' });

// 3. 自定义处理逻辑：将帧数据转为base64（仅演示，实际不建议这么做）
processor.readable.pipeThrough(new TransformStream({
  async transform(frame, controller) {
    // 将视频帧转为Blob
    const blob = await frame.convertToBlob();
    // Blob转base64
    const reader = new FileReader();
    reader.readAsDataURL(blob);
    reader.onloadend = () => {
      const base64Data = reader.result.split(',')[1];
      // 转回二进制（WebRTC仅支持二进制媒体数据）
      const binaryData = Uint8Array.from(atob(base64Data), c => c.charCodeAt(0));
      // 创建新视频帧（保留原始帧的时间戳等关键信息）
      const newFrame = new VideoFrame(binaryData, { 
        timestamp: frame.timestamp, 
        codedWidth: frame.codedWidth, 
        codedHeight: frame.codedHeight 
      });
      controller.enqueue(newFrame);
      frame.close();
    };
  }
})).pipeTo(generator.writable);

// 4. 使用处理后的轨道创建WebRTC连接
const pc = new RTCPeerConnection();
pc.addTrack(generator);
// 后续ICE协商、Offer/Answer流程和普通WebRTC通话一致

接收端：对收到的帧进行base64解码处理

// 1. 收到远端轨道后，构建解码管道
pc.ontrack = (event) => {
  const receivedTrack = event.track;
  const processor = new MediaStreamTrackProcessor({ track: receivedTrack });
  const generator = new MediaStreamTrackGenerator({ kind: 'video' });

  // 2. 解码base64，还原原始帧
  processor.readable.pipeThrough(new TransformStream({
    async transform(frame, controller) {
      const blob = await frame.convertToBlob();
      const reader = new FileReader();
      reader.readAsArrayBuffer(blob);
      reader.onloadend = () => {
        const binaryData = new Uint8Array(reader.result);
        // 二进制转base64再解码（对应发送端编码逻辑）
        const base64Data = btoa(String.fromCharCode(...binaryData));
        const decodedBinary = Uint8Array.from(atob(base64Data), c => c.charCodeAt(0));
        const newFrame = new VideoFrame(decodedBinary, { 
          timestamp: frame.timestamp, 
          codedWidth: frame.codedWidth, 
          codedHeight: frame.codedHeight 
        });
        controller.enqueue(newFrame);
        frame.close();
      };
    }
  })).pipeTo(generator.writable);

  // 3. 渲染处理后的轨道，业务代码无需感知中间解码逻辑
  const videoElement = document.getElementById('remote-video');
  videoElement.srcObject = new MediaStream([generator]);
};

注意事项 #

• 上述示例中的base64编码/解码仅为演示逻辑，实际视频通话中这么做会大幅增加带宽占用，完全不实用。实际场景中可替换为帧加密、滤镜处理等有意义的操作。
• 除了TransformStream，还可以通过WebRTC的RTP扩展或自定义SDP修改来处理媒体数据，但复杂度更高，TransformStream是最直观的透明处理方式。
• 这种处理方式对上层业务完全透明，收发端业务代码只需和处理后的MediaStream交互，无需关心中间的数据修改过程。

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