每路码率
—
Mbit/s
免费工具
CCTV / NVR 存储计算器
估算每路摄像头的码率、总吞吐量、所需存储容量、RAID 配置以及为可靠安装应购买的硬盘数量。
结果
总码率
—
Mbit/s
裸存储容量
—
TB
需购买
—
TB
提示：使用内置的打印功能可导出一页式的清晰摘要，便于交给客户或采购部门。
如何使用本计算器
- 从摄像头数量、分辨率和编码方式开始。计算器会估算每路摄像头在移动时所需的带宽。
- 调整 RAID 级别和硬盘数量，查看可用容量以及应购买的实际硬盘容量。
- 如果你已经从特定录像机或安装规范中知道每路摄像头的配置，可开启手动码率。
- 使用打印摘要，与你的团队或客户快速分享采购概览。
CCTV 与 NVR 存储计算器：技术参考指南
本指南详述了驱动我们 CCTV 存储计算器的计算方法、经验公式和核心假设。请参考此文档，了解目标码率、压缩方式选择和存储开销如何影响你的视频留存方案。
该引擎从三个运行维度评估容量：码率估算、压缩标准（H.264 与 H.265 的存储需求）以及阵列拓扑（CCTV RAID 计算指标）。
1. 码率如何估算
本摄像头存储估算器不依赖通用的固定查表值，而是采用动态计算模型，基于真实世界的摄像头性能指标来模拟带宽消耗。
活动摄像头吞吐量的主公式定义为：
Bitrate_Active = baseBR × fpsFactor × K_Codec × K_Scene
基础码率（baseBR）
基础设施基准负载直接根据传感器分辨率计算：
baseBR = Resolution (MP) × 1.3
应用示例： 一台标准的 Full HD 1080p 摄像头（约 2.07 MP），以 15 FPS 的基准帧率运行，采用标准 H.264 压缩和中等场景复杂度，结果为： 2.07 × 1.3 × 1.0 × 1.0 约为 2.69 Mbit/s 该系数是从供应商规划指南中得出的经验基准值，用于确保在主动监控期间获得最佳的像素密度。
帧率缩放（fpsFactor）
带宽并不会随帧率（FPS）的调整而线性变化。由于现代编码器捕捉的是帧间的时间差异，而非逐帧传输完整的静态图像，因此帧率翻倍对总数据量的影响是次线性的。引擎采用幂律曲线来准确建模这一行为：
fpsFactor = (FPS / 15)^0.45
在设计高帧率（30 fps）部署时，该缩放因子可避免容量的过度分配。
2. H.264 与 H.265 的存储需求
视频压缩的效率会随环境噪声和运动熵的变化而改变。
| 编码选项 | 乘数（K_Codec） | 对监控存储的实际影响 |
|---|---|---|
| H.264 Baseline | × 1.00 | 标准的传统基准。主要为兼容较旧的编码硬件而保留。 |
| H.264 High | × 0.60 | 采用高级熵编码的优化 H.264 实现。数据量约减少 40%。 |
| H.265 / HEVC | × 0.40 | 高效视频编码。相对于标准 H.264 配置，通常可将码率需求降低约 40-60%。 |
| H.265+ (Smart) | × 0.25 | 动态模式。利用背景建模来最小化静态场景的开销。在高噪声条件下（K_Scene >= 1.4）会因场景持续变化而自动降级至 × 0.38。 |
场景复杂度修正系数（K_Scene）
- 低（× 0.7）： 出入受控、像素变化极小的环境（例如安静的仓库或夜间室内走廊）。
- 中（× 1.0）： 标准零售环境或人流适中的商业空间。
- 高（× 1.4）： 动态、不受约束、易持续移动的室外环境（例如繁忙的路口、人群、摆动的树叶或变化的光照）。高噪声会限制帧间压缩效率。
3. 移动侦测的影响
启用移动触发录像配置后，平台会采用双状态占空比。在无活动期间，数据流会降至用户自定义的空闲帧率上限，并将场景复杂度降至最低限值（0.7）。净时间需求计算如下：
Bitrate_Mean = (Bitrate_Active × M) + (Bitrate_Idle × (1 - M))
其中 M 表示在标准 24 小时周期内估算的移动活动百分比。此外，若选择了音频采集，每路摄像头会固定增加 64 kbit/s（0.064 Mbit/s）的分配，用于承载标准的 G.711 PCM 声音流。
4. RAID 存储开销
物理硬盘规划不止于裸数据量的数学计算。内置的 CCTV RAID 计算模块利用标准的容错阵列，精确确定需要购买多少存储层级：
- RAID 1： 纯镜像架构。冗余开销恰好需要 2.0 × 净容量，固定限制为 N=2 块硬盘。
- RAID 5： 单分布式校验。至少需要 3 块硬盘。存储容量损失恰好等于 1 块硬盘：N / (N - 1)。
- RAID 6： 双分布式校验。至少需要 4 块硬盘。通过预留两块硬盘存放校验数据，可承受两块硬盘同时故障：N / (N - 2)。
- RAID 10： 镜像/条带组合阵列。至少需要 4 块硬盘，且严格限于偶数布局（N mod 2 = 0）。物理容量的一半（50%）用于冗余开销。
硬盘计算： 引擎将总容错需求除以硬盘数量（N），并自动将结果匹配到标准的商用 HDD 容量档位（例如 2、4、6、8、12、16、20 TB）。
5. 存储与文件系统开销
视频监控存储计算过程中包含一个基准开销选项（建议为 15%），用于吸收系统性的容量损失：
- 二进制-十进制换算： 硬盘厂商使用十进制计算存储容量（每 TB 为 10^12 字节），而操作系统则以二进制方式格式化阵列（每 TB 为 1024^3 字节）。这种系统性不一致会使物理硬盘容量减少约 7.3%。
- 元数据日志： 文件系统（如 EXT4 或 XFS）会预留一定比例的存储块，用于元数据索引、文件恢复表和扇区映射。
- 保护余量： NVR 存储阵列在完全写满时写入效率会下降；保留标准的 5-10% 缓冲，可在常规的自动 FIFO 磁盘清理期间避免性能下降。
6. NVR 吞吐量上限
如果你的系统总吞吐量超过 320 Mbit/s，计算器会触发优化警告。
尽管标准的千兆接口能处理更高的裸数据流量，但 320 Mbit/s 代表了许多中端商用 NVR 平台的典型录像吞吐量上限。超过这一界限会成为内部 SoC 处理路径或存储数据库引擎写入速度的瓶颈，直接导致视频丢帧、码流不稳定或回放延迟。运行超过该阈值的系统需要在多个 NVR 节点间拆分网络布局，或升级到高吞吐量的项目级硬件。