视频会议系统源码是一套可以装进自己机房的音视频会议方案：多人房间、屏幕共享、聊天、录制回放、会议管理后台。它与公有云会议最大的差别不在功能，在两条——数据不出内网，以及带宽要自己扛。
这两条决定了一切：选型、成本、能撑多少人、要不要自建转码集群，全都由此推导。
视频会议系统源码是一套什么方案？
是一套「客户端 + 信令 + 媒体转发 + 录制转码」四层的自建方案。
客户端层——Web 端（WebRTC）、桌面端（Electron 或原生）、移动端。采集摄像头与麦克风、编码、渲染。
信令层——负责「谁在哪个房间、谁发起了共享、谁在说话」。通常走 WebSocket。
媒体层——音视频流的转发与混合。这是性能的核心。
录制与转码层——把会议录下来、转成可回放的格式、按需转码成不同清晰度。
四层里，媒体层决定了这套系统能撑多少人，其余三层都是常规工程。
私有化部署最实际的动机是什么？
是数据不出内网，其次才是可控与合规。
真实的采购动机排序通常是：
第一条，数据不出内网。政府、军工、医疗、金融、大型制造，这几类客户的会议内容不允许出公网。录制文件尤其敏感——一场战略会的录像存在外部云上，很多单位不能接受。
第二条，网络环境受限。内网、专网、隔离网环境下，公有云会议根本连不上。
第三条，可控。版本自己定、功能自己改、出问题自己查。
第四条，长期成本。高频使用的大单位，按年付云会议的费用可能超过自建。
代价也很明确：带宽、服务器、运维，全部自己承担。 这一点在采购时最容易被低估。
SFU 和 MCU 差在哪？
差在服务器做什么：混合还是转发。
MCU（多点控制单元）——服务器把多路音视频解码、混合成一路，再编码发给每个人。客户端只收一路流，带宽压力在服务器。优点是客户端轻，缺点是服务器 CPU 消耗巨大，且无法做个性化布局。
SFU（选择性转发单元）——服务器不做编解码，只把每路流分别转发给需要的人。服务器 CPU 压力小，带宽压力大。客户端自己解码多路、自己排版。
现在的自建方案基本都走 SFU，原因很实际：CPU 比带宽贵，而且现代终端的解码能力足够。
SFU 的代价是上行带宽：十人会议、每人 1Mbps，服务器的下行就是 90Mbps（每人接收其他九路）。这就引出了下一节。
带宽怎么估算？
按「上行人数 × 码率」算，不是按「房间人数 × 码率」算。
这是一个最容易算错的地方。以十人会议、每人 720p 约 1Mbps 为例：
服务器下行 ＝ 10 人 × 9 路 × 1Mbps ＝ 90Mbps
服务器上行 ＝ 10 人 × 1 路 × 1Mbps ＝ 10Mbps
如果开了屏幕共享（通常 1.5~2.5Mbps），还要再加。
由此得出几条工程结论：
百兆带宽撑不住十人 720p。 实际部署建议按同时在线人数的峰值配带宽，并留 50% 余量。
大房间必须用小流。 二十人以上时，大部分人的画面不需要高清——用「只对活跃发言人发高清、其余发低清」的策略，带宽能降一个数量级。
纯音频会议带宽可以极低。 语音用 Opus 编码，每路只要几十 kbps，这是很多场景的性价比之选。
弱网下靠什么撑住？
靠自适应码率、前向纠错、以及「宁可降清晰度也不卡」的策略。
真实网络环境远不如机房稳定：家庭宽带抖动、移动网络切换、企业出口拥塞。
三层对抗手段：
码率自适应——根据实时丢包与延迟调整发送码率。丢包升高就降到 360p，网络恢复再升回去。
前向纠错（FEC）——发冗余数据，小丢包不用重传就能恢复。对实时音视频来说，重传往往来不及，FEC 更有效。
抖动缓冲——接收端缓一小段时间再播放，吸收网络抖动。缓冲太长会延迟，太短会卡顿，要动态调。
还有一条是产品层面的：弱网时给用户明确提示——「网络不佳，已降低画质」。用户知道原因就不会骂系统烂。
录制与回放怎么做？
录制方式决定服务器成本，回放体验决定用户满意度。
三种录制方式：
服务端录制——服务器解码所有流、合成画面、编码成 MP4。质量可控、用户无感，但 CPU 消耗大，需要独立的转码机。
客户端录制——在某一个参会者端录制。成本低，但依赖那个人不掉线。
旁路推流——把会议推流到流媒体服务器录制。适合大规模直播场景。
实务建议：小规模会议用服务端录制，大规模用旁路推流。 不要所有场景都用同一种。
回放还要考虑：是否要转码成多清晰度、是否要打时间轴章节、录制文件存多久、存储怎么清理。 这些运维细节不做，磁盘三个月就满。
和公有云会议差在哪？
差在「谁负责最后一公里」。
公有云会议的价值是全球节点与自动扩容——你不用担心带宽、不用担心并发峰值、不用担心跨国延迟。
自建方案的价值是数据主权与可定制——但所有这些能力都要自己做。
| 维度 | 公有云会议 | 私有化自建 |
|---|---|---|
| 数据位置 | 服务商机房 | 自己机房 |
| 扩容 | 自动 | 提前规划 |
| 跨国质量 | 有节点优化 | 靠自己 |
| 定制 | 受限 | 完全可控 |
| 起步成本 | 低 | 高（服务器+带宽） |
| 长期成本 | 随用量涨 | 相对固定 |
判断标准很实在：如果会议内容不敏感、人数波动大，用公有云更划算；如果内容敏感、人数稳定、有内网要求，自建才成立。
什么样的单位适合自建？
内容敏感、人数稳定、有内网或专网环境、有运维能力的单位。
四个条件至少满足三个：会议内容不能出内网、同时在线规模可预测（比如固定几百人）、有隔离网络环境、有机房与运维团队。
反过来，几十人的小公司、会议量不大，自建是纯亏——服务器加带宽的年费，够买好几年云会议了。
和会议会务报名签到系统的关系要说清：那边管「会议怎么组织」（报名、签到、议程），这边管「会议怎么开」（音视频传输）。一个是会务，一个是会议本身，两套系统可以对接但不是一回事。
和会议室预约系统也是同理：预约管「房间什么时候空着」，视频会议管「人怎么在线见面」。