WebRTC SFU转发不能直接memcpy音视频帧，因SRTP加密、独立SSRC/序列号/时间戳及密钥上下文使裸包拷贝破坏解密、重排与同步，导致decryption failed或SSRC collision。
WebRTC SFU 转发为什么不能直接 memcpy 音视频帧
因为 WebRTC 的音视频流在传输层已加密（SRTP），且每个 RTCRtpSender 关联独立的 SSRC、序列号、时间戳和密钥上下文。直接拷贝 RTP 包会破坏接收端的解密、丢包重排与同步逻辑，导致 decryption failed 或 SSRC collision 错误。
正确做法是让 SFU 在 RTP 层做“有状态转发”：复用原始包的 payload 和 timestamp，但重写 header 中的 SSRC、sequence number、timestamp（需按目标接收者时钟基线重映射），并用该接收者的 SRTP 密钥重新加密。
- 必须为每个
RTCRtpReceiver→RTCRtpSender对维护独立的 SRTP context（含密钥、salt、ROC、seq_num） - 转发前要校验原始包的 MAC（SRTP auth tag），解密后才可修改 header；否则无法通过接收端校验
- 音频需额外处理
RTX包：SFU 一般不重传，应直接丢弃 RTX，避免触发接收端重复解包
混流（audio mixing / video compositing）必须绕过 WebRTC 栈自己实现
WebRTC 原生不提供服务端混流 API；MediaStreamTrack 是客户端概念，SFU 进程里没有 MediaStream 实例。所有混流操作必须在解密后的原始媒体数据上进行。
音频混流核心是 PCM 帧对齐与加权叠加：从多个解密后的 opus 解码器（如 libopus）获取 10ms/20ms 的 int16_t PCM，统一采样率（如 48kHz）、声道数（如 mono），再按音量权重相加（注意饱和截断）。视频混流则需用 FFmpeg 或 libyuv 做 YUV 裁剪+缩放+贴图合成，输出新帧后送入编码器（如 libvpx 或 x264）。
- 音频混流前务必做 AEC（回声消除）参考信号对齐，否则混出的流会引发远端啸叫 —— 即使 SFU 不参与通话，也要把各路原始上行音频作为参考输入给混音模块
- 视频混流时，每个子画面的
timestamp必须严格对齐到同一 timebase（如 90kHz），否则浏览器渲染会出现卡顿或跳帧 - 混流输出的编码参数（bitrate、keyframe interval、profile）需显式控制，不能依赖 encoder 自适应 —— 否则多路进、单路出时码率抖动会极大
libwebrtc 的 RemotePeerConnection 不适合做 SFU 转发节点
官方 PeerConnection 设计目标是端到端通信，其内部硬编码了 ICE 状态机、DTLS 握手流程、RTP 统计聚合等，无法关闭或替换其中的 SRTP 处理路径。试图用多个 PeerConnection 实例模拟转发，会导致：
- 每个实例占用 ~30MB 内存 + 多个线程，100 路并发即超 3GB，且 CPU 被握手/心跳/统计日志吃满
-
SetRemoteDescription触发完整 SDP 协商，无法跳过 offer/answer 流程 —— SFU 不该参与协商，只应透传与改写 - 无法访问裸 RTP 包：所有
OnPacketReceived回调都已被 SRTP 解密封装，你拿不到原始加密包，也没法干预加密过程
真正可行的是基于 libwebrtc 的底层模块（如 rtc::PacketSocket, srtp, VideoEncoder）自行组装，或选用专为 SFU 设计的库，例如 mediasoup（C++ 内核 + Node.js 控制面）或 janus-gateway（C，插件式架构）。
转发延迟与拥塞控制必须独立实现
WebRTC 的 TransportCC 和 REMB 反馈是端到端的，SFU 位于中间，既不是发送方也不是接收方，无法直接参与标准拥塞控制闭环。若不做干预，下行链路会因缺乏反馈而持续超发，触发大量丢包。
解决方案是 SFU 必须同时扮演“伪接收者”和“伪发送者”：对每条上行流，向发送端反馈 REMB（基于本机接收带宽估算）；对每条下行流，向接收端发送 TransportCC feedback（基于本机发出速率与队列水位）。这要求你解析并生成对应的 RTCP 包（rtcp::Remb, rtcp::TransportFeedback），且时间戳字段必须严格符合 RFC 3550 / 8085。
- 不要复用客户端的 RTCP 处理逻辑 ——
webrtc::RTCPReceiver默认丢弃非本端 SSRC 的 feedback，需 patch 或绕过 - 队列水位检测不能只看 socket sendq，必须包含 SRTP 加密、RTP header 重写、混流编码等全链路耗时，否则反馈滞后会导致瞬时拥塞
- 音频转发建议启用
PLI抑制：当检测到某路音频丢包率突增，立即向对应发送端发 PLI，促使其关键帧刷新，避免解码器持续 conceal
混流本身是计算密集型操作，尤其视频；转发路径上的任何锁竞争（比如共用一个 TaskQueue 处理所有流的 RTP 解包）都会成为瓶颈。实际部署时，转发、解密、混流、编码、加密、发送最好拆到不同线程池，并用无锁队列（如 moodycamel::ConcurrentQueue）传递帧指针 —— 指针传递比 memcpy 几百 KB 的 YUV 数据快两个数量级。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
