一、先说结论：带宽不够是最常见的”能开会但看不清”根因
很多单位反馈”视频会议画质模糊、有声音没画面”，第一反应是”带宽不够”。但实际测算下来，90% 的问题出在”按最低值规划”或”按终端数而非并发数估算”，而不是真的带宽不够。
本文给出一套可以直接套用的计算方法：先看码率档位表，再按四种典型场景实算，最后对照服务器与网络配置要求。全部数字都是可以直接用在自己项目上的。
二、单路视频需要多少带宽：码率档位对照表
视频会议的单路带宽由”分辨率 + 帧率 + 编码格式”三者共同决定。H.265 相比 H.264 约节省 40%–50% 带宽，这是信创改造和带宽紧张场景下的首选。
| 分辨率 | 建议帧率 | H.264 最低 | H.264 推荐 | H.265 推荐 | 典型场景 |
|---|---|---|---|---|---|
| 176×144 | 10 帧 | 32 Kbps | 128 Kbps | 64 Kbps | 画面共享、辅路 |
| 320×240 | 15 帧 | 100 Kbps | 200 Kbps | 100 Kbps | 培训室辅助 |
| 640×480 | 15 帧 | 178 Kbps | 512 Kbps | 256 Kbps | 老旧会议室 |
| 704×576 | 20 帧 | 256 Kbps | 768 Kbps | 384 Kbps | 标清会议室 |
| 1280×720 | 25 帧 | 512 Kbps | 2 Mbps | 1 Mbps | 主流会议室 |
| 1920×1080 | 25 帧 | 1 Mbps | 3 Mbps | 1.5 Mbps | 高端会议室 |
| 3840×2160 | 30 帧 | 4 Mbps | 8 Mbps | 4 Mbps | 旗舰会场、直播 |
| 屏幕共享 | — | 100 Kbps | 300 Kbps | 150 Kbps | PPT 演示 |
音频另算：Opus 编码下通常仅 6–32 Kbps，可忽略不计。这也是为什么”算带宽只算视频”就够了。
三、两个最容易算错的概念
3.1 并发数 ≠ 参会人数
| 概念 | 定义 | 举例 |
|---|---|---|
| 参会人数 | 一场会议里的总人数 | 50 人的大会 |
| 并发数 | 同时需要 MCU 转发处理的会场数 | 50 人在 1 个会场 = 1 方并发 |
举例：某集团有 100 个会议室，平均 8 人/间，同时进行的会议最多 20 场。那么：
- 并发数 = 20 场 × 1 = 20 方（不是 100）
- 若每个会议室都是 1 台终端，终端总数 = 100 台
- 但 MCU 只需按 20 方并发配置
这就是最常见的采购失误：按总人数 100 方去买 MCU，实际只需要 20 方，多花了 4–5 倍的钱。
3.2 上下行不对称
| 角色 | 上行 | 下行 | 原因 |
|---|---|---|---|
| 被广播的终端 | 1 路视频 | 收 N 路视频 | 要收所有人的画面 |
| 普通参会者 | 1 路视频（除非发言） | 收 N 路视频 | 同上 |
| MCU 服务器 | 所有终端下行之和 | 所有终端上行之和 | 转发中心 |
关键结论：终端侧带宽压力小（下行 2–6 Mbps），MCU 服务器侧才是瓶颈（上行可达 18–50 Mbps）。网络规划时别把服务器带宽按客户端算。
四、四种典型场景实算
场景 A：10 人小型会议（720P，4 人被广播）
| 项目 | 计算 | 结果 |
|---|---|---|
| 单路推荐带宽 | 720P @ H.264 | 2 Mbps |
| 被广播 4 人 · 上行 | 4 × 2 Mbps | 8 Mbps |
| 被广播 4 人 · 下行 | 4 × 3 × 2 Mbps | 24 Mbps |
| 其他 6 人 · 上行 | 0（未发言） | 0 |
| 其他 6 人 · 下行 | 6 × 4 × 2 Mbps | 48 Mbps |
| MCU 上行 | 8 + 48 | 56 Mbps |
| MCU 下行 | 4 × 2 Mbps | 8 Mbps |
| 建议配置 | 上行 × 1.5 冗余 | ≥ 100 Mbps |
场景 B：50 人大型会议（720P，全员可见）
| 项目 | 计算 | 结果 |
|---|---|---|
| 单路 | 720P @ H.264 | 2 Mbps |
| 每人上行 | 1 路（发言时） | 2 Mbps |
| 每人下行 | 50 路 | 100 Mbps |
| MCU 上行 | 50 × 2 Mbps | 100 Mbps |
| MCU 下行 | 50 × 2 Mbps | 100 Mbps |
| 建议配置 | 双万兆口 | 2 × 10GE |
注意：50 人会议在 720P 下，每个客户端下行已达 100 Mbps。这就是为什么大型会议必须用 MCU 集中转发（SFU 只是转发不转码，带宽反而更高）。
场景 C：省-市-县三级级联（各级 MCU）
| 层级 | 并发 | 单路 | 本级 MCU 带宽 | 说明 |
|---|---|---|---|---|
| 省级（汇聚） | 汇聚 30 路上行 | 2 Mbps | 60 Mbps 上行 | 收全部下级流 |
| 市级 | 本地 8 方 + 向上 4 路 | 2 Mbps | 24 Mbps | 本地转发 + 上送 |
| 县级 | 本地 5 方 | 2 Mbps | 20 Mbps | 终端接入 |
级联的关键点：每加一级，就多一次编解码（增加约 30–50 ms 延迟），且省级的上行压力是各下级上行之和。三级架构下省级 MCU 建议不低于 2×10GE。
场景 D：H.265 信创方案的带宽节省
| 并发 | 分辨率 | H.264 方案 | H.265 方案 | 节省 |
|---|---|---|---|---|
| 20 方 | 720P | MCU 上行 40 Mbps | MCU 上行 20 Mbps | 20 Mbps |
| 50 方 | 1080P | MCU 上行 150 Mbps | MCU 上行 75 Mbps | 75 Mbps |
| 100 方 | 1080P | MCU 上行 300 Mbps | MCU 上行 150 Mbps | 150 Mbps |
信创项目必看：H.265 在信创环境下的适配已经成熟，是带宽紧张场景的最优解。以 100 方 1080P 项目为例，仅带宽一项每年可省下的专线费用就相当可观。
五、带宽不够时会发生什么：QoS 表现对照
| 丢包率 | 语音表现 | 视频表现 | 系统应对 |
|---|---|---|---|
| < 1% | 清晰 | 流畅 | 无需干预 |
| 1%–5% | 偶有杂音 | 轻微卡顿 | 自动调节码率 |
| 5%–15% | 断续 | 明显卡顿 | 降分辨率至 720P |
| 15%–25% | 断续加重 | 花屏 | 降分辨率至标清 |
| 25%–30% | 仍连续 | 降级 | QoS 前向纠错生效 |
好视通 MCU 采用动态冗余前向纠错（FEC）+ 智能路由 + 自适应码率，在丢包率 25%–30% 情况下仍能保障语音连续，视频则自动降级。这是选型时最该问厂商的技术指标——很多竞品在 10% 丢包时语音就已经断续。
六、服务器与网络配置建议
| 并发规模 | MCU 配置 | 网络接口 | 带宽预留 |
|---|---|---|---|
| ≤ 50 方 | 单机，单电源 | GE × 2 | 上行 100 Mbps |
| 50–300 方 | 单机，双电源 + 双主控 | 2×10GE SFP+ | 上行 500 Mbps |
| 300–1000 方 | 集群，多节点 | 2×10GE SFP+ | 上行 1–2 Gbps |
| 多级架构 | 每级独立 MCU + 级联 | 2×10GE SFP+ | 按层级累加 |
冗余余量建议：服务器带宽按实测峰值的 1.5–2 倍预留。原因：① 会议峰值常超出均值 30%–50%；② 故障切换期间新旧链路并存；③ 未来扩容不需要重新采购网络设备。
七、一张可以直接抄的预算清单
| 项目 | 30 方 720P | 100 方 1080P | 300 方 1080P |
|---|---|---|---|
| MCU 服务器 | 1 台（双电源双主控） | 1 台（2×10GE） | 2 台集群 |
| MCU 上行带宽 | 100 Mbps | 300 Mbps | 900 Mbps |
| 网络建议 | 千兆专线 × 2 | 万兆上联 + 千兆备份 | 万兆 × 2 负载均衡 |
| 单方带宽（含余量） | 3 Mbps | 4.5 Mbps | 4.5 Mbps |
| 客户端侧建议 | 4 Mbps | 6 Mbps | 6 Mbps |
八、给采购方的三条实用建议
1. 招标文件里把码率写清楚，别只写”支持高清”
建议写法：“支持 720P@25fps 以上，单路建议带宽不低于 2Mbps，支持 H.265 编码（同等画质下带宽节省不低于 40%）”。这样投标方无法用低配终端应标，实际使用效果也有保障。
2. 把”并发数”和”QoS 指标”写进技术要求
建议写法：“MCU 支持不少于 XXX 方并发接入；具备丢包补偿机制，在网络丢包率 25%–30% 情况下保障语音连续性”。后者是硬指标，能直接筛掉弱方案。
3. 要求提供实际测算，而不是笼统承诺
要求供应商按你的实际会议室数量、实际并发场景、实际网络环境出带宽测算表，含客户端侧、服务器侧、级联各层。拿到表后按本文公式复核一遍，就能看出配置是否合理、有没有虚报。
九、常见问题速答
Q1：终端配置很高，为什么会议室还是卡？
大概率是服务器侧带宽不足。终端算力不解决转发瓶颈，MCU 上行不够会拖累所有会场。检查方法：看 MCU 网卡实时流量是否长期接近线速。
Q3：标清就够了吗？
看用途。日常会议与培训 720P 足够，4K 主要用于高端会议室与大屏场景。在预算有限时，把钱从终端分辨率挪到服务器并发能力上，体验提升更明显——这是很多项目”钱花了效果不好”的原因。
Q4：运营商专线 100M 够用吗？
够 30 方 720P 会议（需 100 Mbps 上行）。但要注意专线是上下行对称的，会议室侧上行到 MCU 与 MCU 侧上行是两条路径，整体规划时要把两端都算进去。
Q5：信创项目带宽会更高吗？
不会，反而更低。H.265 在同等画质下比 H.264 节省 40%–50% 带宽，这是信创场景的额外红利。适配国产芯片与 OS 后算力完全够用。
十、总结
带宽计算的核心就三步：
- 查码率档位表 —— 确定单路带宽（720P = 2 Mbps，1080P = 3 Mbps）
- 算并发而非人数 —— 同时进行的会议数才是配置依据
- 上下行分开算 —— 服务器上行是真正的瓶颈
算完之后，按 1.5–2 倍留余量，配双网口与冗余电源。剩下的交给 QoS——好视通 MCU 在 25%–30% 丢包下仍保语音连续，这是选型时最该问清楚的指标。
需要针对贵单位的实际会议室数量、并发场景出具体测算表？把会议室清单、终端类型、并发峰值发给我们，技术顾问会在 1 个工作日内给出可直接用于招标文件的带宽测算与技术参数建议。
技术咨询：151-1695-8750｜ 商务合作：152-1055-3790
Chinese