降低Freeswitch多方视频会议媒体延迟的优化方案及适用性咨询

• 调整mod_conference混流缓冲配置：将conference-video-mux-buffer-size参数从默认值下调至150~200ms，减少混流环节的帧缓存等待时长；同步关闭混流输出的帧对齐缓冲，避免为了对齐各路帧引入额外等待。
• 编解码参数调优：混流编码器使用H.264 Baseline profile，关闭B帧，采用ultrafast编码预设，将VBV缓冲大小设置为和码率匹配的最小值，关键帧间隔设置为500ms以内，降低编码端的缓冲延迟。如果所有接入端编码格式统一，强制关闭不必要的转码逻辑，仅在混流环节做一次编解码。
• 优化Verto端jitter buffer配置：将verto-jitter-buffer-length下调至20~40ms，测试场景下无明显网络抖动时可直接关闭自适应jitter buffer，减少端侧的播放缓冲延迟。
• 调度优先级优化：将Freeswitch的视频处理线程绑定物理核心，设置为实时调度优先级，避免操作系统调度带来的随机延迟。
• 降低冗余计算开销：测试阶段关闭会议录制、旁路直播等额外输出链路，同步适当降低混流画布的分辨率/帧率（比如720P@25fps），减少编解码和混流的计算耗时。

• 该场景下的合理总端到端延迟应控制在400ms以内，排除固定100ms网络RTT后，服务侧混流转码的额外延迟应不超过300ms，即可支撑流畅的双向实时对话。
• 目前已有大量落地的低延迟Freeswitch视频会议案例，多用于10方以内的中小型会议、云联络中心视频坐席等场景，优化到位的方案端到端延迟可稳定在300~350ms区间，完全满足实时交互需求。

• 如果你的业务场景以单会议16方以内的中小型实时视频会议为主，Freeswitch完全可以支撑，不需要更换方案，完成上述优化后基本可以达到预期延迟指标。
• 如果后续需要支持单会议几十至上百人参会、SVC分层编码、动态布局调整等复杂需求，Freeswitch的mod_conference模块在性能和功能上会存在瓶颈，可以考虑更换为Mediasoup、Janus这类专门面向WebRTC场景设计的SFU方案。

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