一、四项功能，缺一不可

四行里最贵的是第二行：硬盘按「路数 × 码率 × 天数」乘出来，这是监控项目成本的绝对大头。 第一行和第三行是矛盾的：实时要低延迟，远程要带宽， 所以工程上常常是「本地主码流存、远程子码流看」两条流。

二、先算清楚硬盘

容量公式只有一行：码率 ÷ 8 × 86400 ÷ 1000，单位 GB。

4 Mbps 是 1080p H.264 的常态：一路一天 43 GB，16 路一个月 20 TB 上下。 一台 8 盘位 NVR 插 8 块 8 TB 是 64 TB 标称，扣掉 RAID 和格式化损耗之后， 装得下 30 天，但不宽裕。

三、换编码能省多少

同一份 30 帧短片实测三种配置，省下来的比例可以直接乘在容量上：

降质量省 20%，换 H.265 再省 7 个点。 这就是为什么监控厂拼命推 H.265：省的不是带宽，是硬盘钱。 但要注意这是同一份画面的比例，换更复杂的画面，H.265 的优势会更大（04.03 讲过原因）。

四、三个「看着不重要，其实要命」的特点

第一行是所有「Demo 能跑」和「产品能用」的分界线：短跑看不出泄漏，长跑才暴露。 第二行的对策是留余量——按峰值加 20%，别按平均值。 第三行是本章的隐藏主线：存下来的东西必须能被检索，所以一定要封装（04.05.03）、 一定要有时间戳（04.06）。

五、动手 Demo：一路 1080p 存一天要多少硬盘

Demo 先算容量表，再用同一份 30 帧短片实测三种配置的字节数，把比例乘到容量上。 所有数字都是算出来的，公式在正文里写着。

# 容量 = 码率(Mbps) / 8 * 86400 / 1000   单位 GB
for mb in (1, 2, 4, 8):
    day = mb / 8.0 * 86400 / 1000.0
    print(mb, "%.1f GB/天" % day, "%.1f TB/16路30天" % (day*30*16/1000))
# 再实测三种配置的字节数，按比例折算
for name, codec, opt in [("H.264 c23", "libx264", {"crf":"23"}),
                          ("H.264 c28", "libx264", {"crf":"28"}),
                          ("H.265 c28", "libx265", {"crf":"28"})]:
    sz = encode_once(codec, opt)
    print(name, sz, sz / base)

实跑输出：

--------------------------------------------------------------------
一路 1080p 存一天要多少硬盘
--------------------------------------------------------------------
**监控的第一个工程问题不是「怎么编」，是「硬盘够不够」。**
  这一节把容量算清楚，**所有数字都是算出来的，公式只有一行。**

  **容量（GB） = 码率（Mbps） ÷ 8 × 86400 ÷ 1000**
  **÷8 是把比特换成字节，86400 是一天的秒数，÷1000 是按十进制 GB 算。**

  码率        一路一天      一路 30 天    16 路 30 天
  --------------------------------------------------------
  1 Mbps      10.8 GB       324 GB        5.2 TB
  2 Mbps      21.6 GB       648 GB        10.4 TB
  4 Mbps      43.2 GB       1296 GB       20.7 TB
  8 Mbps      86.4 GB       2592 GB       41.5 TB

  **4 Mbps 那行是 1080p H.264 的常态**：一路一天 43 GB，16 路一个月就是 20 TB 上下。
  **一台 8 盘位的 NVR 插 8 块 8 TB 是 64 TB 标称**，扣掉 RAID 和格式化损耗，**装得下，但不宽裕。**

**同样的画面，换几个参数能省多少（同一份 30 帧短片实测换算）：**

  配置            30 帧字节     相对      一路 30 天
  --------------------------------------------------------
  H.264 crf 23    10634         1.00 倍   1.3 TB
  H.264 crf 28    8542          0.80 倍   1.0 TB
  H.265 crf 28    7781          0.73 倍   0.9 TB

  **第三行是 H.265，省下来的比例直接乘在容量上。**
  **这就是为什么监控厂拼命推 H.265：省的不是带宽，是硬盘钱。**
  **注意这里的「一路 30 天」是按 4 Mbps 基准乘比例算的**，不是真跑 30 天，
  **是估算，但换算过程是透明的。**

  **最后提醒一句**：上面所有数都是「码率 × 时间」，**前提是码率稳定。**
  用 CRF 的话码率随画面波动，**硬盘容量要按峰值留余量，一般留 20%。**

H.265 那一行只省了 7 个百分点（相对 H.264 crf 28），和 04.03 的结论一致： 简单画面上 H.265 吃不到便宜。 「一路 30 天」这一列是估算：按 4 Mbps 基准乘字节比例算的，不是真跑 30 天。估算可以， 但要把口径写出来。

30 秒实验

1. 把码率从 4 Mbps 改成 2 Mbps，重算 16 路 30 天的容量。
2. 把天数改成 90，看硬盘数是不是正好三倍（不是，见 05.01.03）。
3. 给容量加 20% 余量，重算一遍，和 NVR 的 64 TB 标称比。

常见误区

1. 以为监控的技术难点在「画质」。 难点在容量、带宽、长跑稳定性，画质反而排最后。
2. 以为按平均码率算容量就够。 CRF 模式码率波动，要按峰值加 20%。
3. 以为存下来就行。 不能按时间检索的录像等于没存，所以必须封装。

下一节把监控系统的四段结构画出来，看延迟是在哪一段攒起来的。

• ☐ （本节完，下一节 05.01.02 视频监控系统的工作原理及结构）

相关笔记

• 视频监控系统的工作原理及结构
• 控制视频的码率及分辨率
• 🎬 音视频原理及应用 · 26 课
• 📹 视频监控与国标 · 索引