使用wrtc构建的少对多WebRTC广播服务CPU占用过高如何解决？

你对CPU占用过高的原因判断是正确的：wrtc默认的addTrack逻辑会触发底层对音视频流的解码+重编码流程，哪怕收发两端的编码参数完全一致也会执行该操作，这是为端侧通话场景设计的逻辑，完全不适合SFU广播场景。

要实现零编解码的纯包转发，你需要抛弃直接转发MediaStreamTrack的方案，改用原始RTP包透传逻辑，具体实现步骤如下：

• 第一步：采集主播侧已编码的原始RTP包
  主播端RTCPeerConnection建立完成后，不要直接操作回调拿到的MediaStreamTrack，而是给对应音视频RTCRtpTransceiver的receiver绑定onrtp事件，直接获取主播端上传的、已经完成编码的裸RTP数据包，该环节不涉及任何编解码操作。
• 第二步：对齐所有连接的编码参数
  主播和观众的SDP协商阶段，强制过滤编码格式，要求所有端统一使用同一种音视频编码（例如统一H264 High profile、opus 48kHz立体声），避免因编码不匹配触发转码。
• 第三步：透传RTP包到观众端
  为每个观众的RTCPeerConnection提前创建对应数量的音视频RTCRtpTransceiver，将从主播侧拿到的原始RTP包，直接调用观众侧对应RTCRtpSender的send()方法发送即可，全程仅做内存拷贝和转发，无任何编解码计算。

注意事项 #

• 需要透传RTCP包：观众端发起PLI关键帧请求时，需要将该RTCP包转发给对应主播，主播收到后会发送关键帧，避免新加入的观众出现花屏、无画面的问题。
• 不要使用wrtc内置的MediaStream流转逻辑，该逻辑默认会走解码→渲染→编码的全流程，仅适合端到端通话场景，不适合SFU转发。

完成上述修改后，1主播1观众的CPU占用通常会降到1%以下，单核心CPU可轻松支持数百路观众的并发转发。

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