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