国标只规定「必须支持 H.264」，不规定码率，所以码率要自己选。 而码率一旦选错，后面所有容量规划全错。
上一节的编号是「谁是谁」。这一节的码率是「要占多少地方」，两者是容量规划的两半。 Demo 把四种分辨率的码率、存储量、封装膨胀一次算清。
一、码率的选择是个三角
清晰度、码率、存储，三者只能挑两个。 想更清楚就得给更多码率，想省硬盘就得降码率，而两者都会影响「能不能看清人脸」。
| 分辨率 | 像素 | 典型码率 | 一路一小时 |
|---|---|---|---|
| 1080p | 1920×1080 | 4096 kbps | 1.76 GB |
| 720p | 1280×720 | 2048 kbps | 0.88 GB |
| D1 | 704×576 | 1024 kbps | 0.44 GB |
| CIF | 352×288 | 512 kbps | 0.22 GB |
第四列是机房唯一关心的数字：它乘「路数乘天数」就是硬盘需求。 而这一列是「一路一小时」，乘 24 就是一天，乘 30 就是一个月。 注意这里的「典型码率」不是规范：国标只管「必须支持 H.264」，码率、帧率、GOP 全是工程参数。 所以同一个 1080p，有人跑 2 Mbps 有人跑 8 Mbps，画质和存储量差四倍。
二、封装会让实际占用比标称大一点
国标要求 PS 封装，而 RTP 每包还要加 12 字节头，所以「实际占用」永远比「标称码率」大一点。 这个膨胀和帧率直接相关：帧率翻倍，包数翻倍，头的总量也翻倍。 所以「提高帧率」比「提高码率」更费头开销——这一点和第八章语音包的结论是同一个道理。 膨胀比例很小（千分之几），但有三个地方会被它咬到：一是百兆口接十几路就满了； 二是交换机的背板带宽要按「实际占用」算；三是运营商按「实际流量」计费。 最后一条实践：国标要求必须支持 H.264，H.265 是可选。 所以对接前必须先问清「上级平台收不收 H.265」， 收不了就得在设备侧改编码，而不是在平台侧转码——转码一路 1080p 要吃掉一个核。
三、动手 Demo：码率是选出来的，不是算出来的
四种分辨率各算一遍存储量，再算 1080p 加上 RTP 与 PS 头之后的实际占用。
for name, kbps in (("1080p", 4096), ("720p", 2048),
("D1", 1024), ("CIF", 512)):
gb = kbps * 3600 / 8 / 1024 / 1024
print(name, kbps, round(gb, 2), "GB/小时")
kbps = 4096
rtp = 12 * 25 * 8 / 1000.0 # 25 帧每秒，每帧一个包
ps = 30 * 25 * 8 / 1000.0
print("实际占用 %.1f kbps" % (kbps + rtp + ps))
实跑输出：
--------------------------------------------------------------------
码率是选出来的，不是算出来的
--------------------------------------------------------------------
**国标对媒体编码只做「必须支持什么」的规定，不规定具体码率**。
**而码率一旦选错，后面所有容量规划全错。**
分辨率 像素 典型码率 一路一小时
--------------------------------------------------------------
**1080p** **1920×1080** **4096 kbps** **1.76 GB**
**720p** **1280×720** **2048 kbps** **0.88 GB**
**D1** **704×576** **1024 kbps** **0.44 GB**
**CIF** **352×288** **512 kbps** **0.22 GB**
**第四列是机房最关心的数字**：**它乘上「路数乘天数」，就是硬盘需求。**
**但存下来的并不是「裸码率」那么多**，**因为国标要求 PS 封装，而 PS 是有头的**：
项目 带宽
---------------------------------
**裸码率** **4096 kbps**
**RTP 头** **2.4 kbps**
**PS 头** **6.0 kbps**
**实际占用** **4104.4 kbps**
**膨胀** **0.2%**
**膨胀不到百分之一，看着不多**，**但一千路乘上去就是几十兆。**
**更值得注意的是它和帧率有关**：
**帧率翻倍，每帧一个小包，头的总量也翻倍**——**所以「提高帧率」比「提高码率」更费头开销。**
**最后一条实践**：**国标要求必须支持 H.264，H.265 是可选**。
**所以对接前必须先问清「上级平台收不收 H.265」**，
**收不了就得在设备侧改编码，而不是在平台侧转码**——**转码一路 1080p 要吃掉一个核。**
四种分辨率的存储量基本是「像素减半、码率减半」，所以 1080p 换 720p，硬盘直接省一半。 但画质不是线性下降的——1080p 到 720p 还能认人，再往下就只能看「有没有人」了。 第二段算出的膨胀不到百分之一，看着可以忽略，但一千路乘上去就是几十兆。 更要紧的是它和帧率绑定：25 帧改 30 帧，包数涨两成，头也跟着涨两成。 所以「省带宽」的正確顺序是： 先降帧率（对存储影响小、对头开销影响大），再降码率，最后才降分辨率—— 因为分辨率一降，画质是断崖式的。
30 秒实验
- 算一下：100 路 1080p 存 30 天要多少 TB？（1.76 乘 24 乘 30 乘 100，约 126 TB）
- 想一下：为什么「提高帧率」比「提高码率」更费头？
- 想一下：平台不支持 H.265 时，该在哪一侧改？
常见误区
- 以为「国标规定了码率」。 它只规定必须支持 H.264，码率是工程参数。
- 以为「标称码率就是实际占用」。 RTP 与 PS 头会让它涨一点，千路乘上去就明显了。
- 以为「平台侧转码最省事」。 一路 1080p 转码吃掉一个核，该在设备侧改。
自测三问（点开对答案）
1. 1080p 跑 4096 kbps，一路一小时多少 GB？ —— **约 1.76 GB**，乘 24 就是一天的量。 2. 为什么帧率翻倍带宽涨得更快？ —— **每帧一个包，包数翻倍，RTP 与 PS 头也翻倍**。 3. 省带宽的正确顺序？ —— **先降帧率、再降码率、最后降分辨率**，因为分辨率影响最断崖。下一节追问：既然裸流也能传，为什么国标非要套一层 PS？
- ☐ （本节完，下一节 10.05.03 媒体存储封装格式）