基于Jitsi的高校视频通话产品可扩展低资源录制方案咨询

现有方案问题根源 #

• 前端MediaRecorder API录制依赖客户端算力、网络状态，终端设备性能不足、网络波动时必然出现卡顿、音频缺失问题，且无法保证录制文件的完整性，不符合审计场景的高可靠性要求
• 原生Jibri采用X11虚拟桌面+Chrome渲染会议界面的实现逻辑，资源占用高、单实例并发能力弱，只适合小规模部署场景

可落地优化方案 #

方案1：Jibri轻量化改造（改造成本最低） #

• 替换原生Jibri的X11+Chrome渲染链路，直接调用ffmpeg从Jitsi Videobridge（JVB）拉取指定会议的RTP音视频流做混合编码，跳过桌面渲染环节，单实例并发能力可提升3-5倍
• 配置硬件编码加速：x86服务器可启用NVENC/VA-API硬件编码，CPU占用可降低60%以上，单实例可支持10路以上并发会议录制
• 配置按需录制策略：仅当会议触发审计录制规则时才启动对应Jibri实例，避免资源空耗

方案2：JVB旁路录制架构（扩展性最高，适合大规模部署） #

该方案是ToB视频会议场景的主流录制实现，完全兼容现有Jitsi部署：

• 配置JVB开启RTP旁路转发能力，将需要录制的会议的所有参会者音视频流、共享桌面流直接转发到独立录制集群，无需经过Jibri的界面渲染流程
• 录制服务采用GStreamer或ffmpeg直接对裸RTP流做混合、编码、封装，单核心CPU即可支持1-2路会议录制，资源消耗仅为原生Jibri的1/4
• 支持录制节点动态扩缩容，可承载100路以上并发会议录制，生成的MP4文件可直接归档到对象存储，满足审计的不可篡改要求

方案3：混合录制架构（兼顾功能和成本） #

如果审计要求录制内容包含参会者列表、聊天框、会议信息等完整界面元素，用轻量化无头浏览器Puppeteer替代Jibri默认的Chrome实例，配合硬件编码，资源占用比原生Jibri低40%左右；如果仅要求录制纯音视频+共享屏幕内容，直接采用旁路流合成方案即可。

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