最近整理了一篇脱敏后的实验记录：把 WebRTC 音频从 Pion `OnTrack` 收到后，解码 Opus RTP 为 PCM ，再通过 FFmpeg `arnndn` 做 RNN 降噪，先输出文件做对比验证。
文章地址：
https://www.lodan.me/zh-cn/posts/server-side-webrtc-noise-reduction-pion-ffmpeg-rnn/
我现在的判断是：
- 这条链路适合先做离线验证，不适合一上来就做实时转发。
- `int16` PCM 要对应 FFmpeg `s16le`，格式边界不能含糊。
- 真正难的是延迟、CPU 、缓冲、FFmpeg 进程生命周期、丢包和音视频同步。
- 如果设备侧硬件和 WebRTC 3A 表现不可控，服务端降噪可以作为补充方向，但不能当成免费能力。
想讨论一下：大家在 WebRTC 或实时音频场景里，有没有把降噪、增益、混音这类处理放到服务端做过？最后卡住的是延迟、效果，还是资源成本？