一、Profile S 的四条硬要求

「要求」不是「建议」，少一条就不许印 ONVIF 的标。

第一行是个常见的误解： 「支持 H.265 所以更先进」不代表更符合 Profile S—— Profile S 只要求 H.264，H.265 是 Profile T 的事。 一台只给 H.265 的设备，按 S 的标准反而不合格。 第三行「至少 720p」是下限，没有上限——4K 的机器也符合 S。 第四行最容易被忽略：很多国产设备「ONVIF 能用」但组播发现不回，客户端只能靠手填 IP， 严格说不算 Profile S。

二、带宽账：一路 1080p25 到底多大

按码率算，一天的量不受编码格式影响，只受码率影响：

公式：kbps ÷ 8 × 86400 ÷ 10⁶ = GB／天。 ÷8 把 bit 换 byte，86400 是一天秒数，÷10⁶ 从 KB 换到 GB。 第三行要看清：H.265 省的是「同画质下的码率」，不是「同码率下的画质」。 所以这一行和第一行数字一样，是因为画质不同—— 同码率下 H.265 画质更好，这才是它的价值（04.03 实测过）。 第四列那些「几百路」是纯数学：千兆全线速、只跑这一种流、不算任何开销。 真实现场一台千兆交换机接三四十路就该考虑上行了—— 因为问题从来不是「能不能跑」，是「卡不卡」。

三、四个 Profile 的关系

S 和 T 是「上下位」关系： 符合 T 的设备通常也符合 S，反过来不成立（T 要求 H.265 和元数据）。 G 和 M 是「加装」：一台 Profile S 的摄像机， 接了 NVR 才谈得上 G——录像在 NVR 上，不在摄像机上。 这个区分在报价时很有用：你要录像回放，光买「支持 Profile S 的摄像机」不够，还要 NVR。 很多人以为 S 包含 G，签完合同才发现要补一台 NVR。

四、Q、C、A、D：门禁那一支

这四个和监控关系不大，但值得知道它们存在， 因为「ONVIF 支持门禁」这句话会让很多人以为监控也能管门禁。

后三行是完全不同的产品线： Profile C 的门禁控制器不提供 RTSP 流，Profile S 的摄像机不管开门。 所以「ONVIF 是一套协议」这句话要打个折：它是一套「方法论」加几个互不相干的品类规范， 共享 SOAP／WSDL 这套底层，业务层各管各的。

五、动手 Demo：Profile S 到底要求什么，算一遍带宽

Demo 只做一件事：把码率换算成「一路一天多大」，再算千兆能跑几路。 公式写在代码里，数字由代码算，口径写在正文里。

BW = [("720p25", 2048), ("1080p25", 4096),
      ("1080p25 H.265", 2048), ("4K25 H.265", 8192)]

for name, kbps in BW:
    # kbps/8 是 KB/s，×86400 是 KB/天，÷1e6 得 GB/天
    gb = kbps / 8.0 * 86400 / 1e6
    # 1000 Mbps = 1000000 kbps
    n = 1000000.0 / kbps
    print(name, "%.1f GB" % gb, "%.0f 路" % n)

实跑输出：

--------------------------------------------------------------------
Profile S 到底要求什么，算一遍带宽
--------------------------------------------------------------------
**Profile S 是最普及的一个 Profile，管的是「实时流」。**
  这一节把它的硬性要求和它带来的带宽账算清楚。

**Profile S 的几条硬要求（不是建议）：**

  项              要求                          做不到的后果
  --------------------------------------------------------------------------------
  编码            **必须 H.264**（可选 MJPEG）  只给 H.265 的不算 Profile S
  传输            **必须 RTP over RTSP**        只给 HTTP-FLV 的不算
  分辨率          至少 720p                     只给 D1 的老设备不算
  发现            **必须支持 WS-Discovery**     只能手填 IP 的不算

  **第三行要注意**：「至少 720p」是**下限**，**没有上限**——**4K 的机器也符合 Profile S。**
  **第四行最容易被忽略**：很多国产设备「ONVIF 能用」但**组播发现不回**，**客户端只能靠手填 IP**，
  严格说不算。

**带宽账：一路 1080p25 是多少**

  规格                典型码率      一路一天      千兆能跑几路
  ----------------------------------------------------------------
  720p25              2048 kbps     22.1 GB       488 路
  1080p25             4096 kbps     44.2 GB       244 路
  1080p25 H.265       2048 kbps     22.1 GB       488 路
  4K25 H.265          8192 kbps     88.5 GB       122 路

  第四列是按「千兆全线速、只跑这一种流」算的**理论上限**，实际打三到五折。
  **因为交换机背板、磁盘写入、解码都要分走带宽。**

  **第四列那些「几百路」是纯数学，不要当成工程值。**
  **真实现场，一台千兆交换机接三四十路就该考虑上行了。**
  **因为这不是「能不能跑」，是「卡不卡」。**

**把四个 Profile 摆在一起看差异：**

  Profile     管的品类                  代表操作
  ----------------------------------------------------------------------------------
  **S**       视频流（监控主力）        `GetStreamUri`／`GetProfiles`
  **G**       录像存储与回放            `GetRecordings`／`FindRecordings`
  **T**       高级流（H.265、元数据）   `GetStreamUri` + 元数据流
  **M**       元数据与分析              `GetSupportedRules`／`GetAnalyticsModules`

  **S 和 T 是「上下位」关系**：
  **符合 T 的设备通常也符合 S，但反过来不成立**（T 要求 H.265 和元数据）。
  **G 和 M 是「加装」**：一台 Profile S 的摄像机，**接了 NVR 才谈得上 G**（录像在 NVR 上，
  不在摄像机上）。

2048 kbps 换成 22.1 GB：2048 ÷ 8 = 256 KB/s，×86400 = 22,118,400 KB，÷10⁶ ≈ 22.1 GB。 和第五章那个「4 Mbps 一路一天 43.2 GB」对得上（4096 kbps 这里是 44.2 GB， 差的是 4096 与 4000 的差别）。 「千兆能跑几路」这个数只用来做量级判断， 不要拿去报价——真实工程里要考虑交换机背板、磁盘写入、客户端解码，打三到五折。 这里没有「实测」，全是算术。 所以本节没有 Demo 输出里的实测部分——我没有摄像头，也没有千兆链路，编不出实测数据。

30 秒实验

1. 把 4K 的码率改成 16384，看一路一天变成多少（176.9 GB）。
2. 按「16 路 1080p25 存 30 天」算总容量，和第五章的 20.7 TB 比。
3. 把 1080p25 的码率从 4096 降到 2048，算一线能多跑几路，再想想画质掉多少。

常见误区

1. 以为支持 H.265 就自动符合 Profile S。 S 只要求 H.264，H.265 是 Profile T 的事—— 只给 H.265 的设备按 S 的标准反而不合格。
2. 以为 Profile S 包含录像。 G 才是录像，摄像机本身不存录像，录像在 NVR 上。
3. 以为「千兆能跑 244 路」是工程值。 那是理论极限，真实打三到五折。

下一节看 Profile 落到真设备上是什么样：声明了哪个，就决定了你能调哪些操作。

• ☐ （本节完，下一节 07.01.05 ONVIF应用）

相关笔记

• ONVIF规范
• ONVIF应用
• 视频监控系统的功能及特点
• 📹 视频监控与国标 · 索引