一、2008 年之前是什么样

每台摄像机一套私有 SDK，每个厂家一个 DLL，每次换品牌重写一遍客户端。 这就是 ONVIF 要终结的局面。

第三行是 ONVIF 最被低估的设计：「支持 ONVIF」这句话几乎没有信息量， 而「支持 Profile S」是可以拿测试用例去验的。 这个区别决定了 ONVIF 是「一个联盟」还是「一堆文档」——它有强制的一致性测试，过了才准印标。

二、十六年的账

从 2008 年 11 月到 2024 年 5 月，5660 天，约 15.5 年。

8 个 Profile 跨 12 年，中间 7 个间隔，平均 1.7 年一个。 但节奏是前紧后松： 2011 到 2014 三年出了四个（S／G／C／A），2018 之后六年只出了两个（M／D）。 原因很实际：能划出来的「设备品类」就那么多，划完了自然慢下来。这不是停滞，是收敛。

三、为什么必须搞 Profile

第二行才是 Profile 的真正价值：它不只是一份文档，是一套测试用例。 所以「支持 Profile S」比「支持 ONVIF」具体得多——后者几乎等于没说。 第三行的「分层」在 07.01.04 展开：Profile S 是核心，T 是它的加强版，G 和 M 是外挂的扩展。

四、和本课其他几册的关系

ONVIF 管的是「怎么找到设备、怎么要流、怎么控制」， 不管「流本身怎么编怎么传」。后者是 RTSP／RTP 的事（第一章）和 FFmpeg 的事（26／30 课）。

第三行和第四行是很多人的误区： 以为 ONVIF 能「取流」就以为它管编码——它只是告诉你 RTSP 地址是什么，流里面是什么它不管。 所以「ONVIF 取流失败」和「取到流但播不出来」是两类完全不同的故障， 前者查 SOAP，后者查 RTSP 和解码器。 分清这两类，排查时间能省一半。

五、动手 Demo：ONVIF 这十六年，长出了几个 Profile

这一节不算协议，只算时间账：从成立到今天多少天、出了几个 Profile、平均几年一个。 所有数字都由代码算出来，Profile 的起始年份是写在表里的常量。

PROF = [("S", 2011), ("G", 2014), ("C", 2014), ("A", 2014),
        ("Q", 2016), ("T", 2018), ("M", 2021), ("D", 2023)]

t0 = datetime.date(2008, 11, 1)
t1 = datetime.date(2024, 5, 1)
print((t1 - t0).days, (t1 - t0).days / 365.25)

yrs = [y for _n, y in PROF]
print((yrs[-1] - yrs[0]) / float(len(yrs) - 1))   # 1.7

实跑输出：

--------------------------------------------------------------------
ONVIF 这十六年，长出了几个 Profile
--------------------------------------------------------------------
**ONVIF 2008 年 11 月成立，第一版规范当年就发了。**
  这一节不算协议，只算时间账：**十六年出了几个 Profile，平均几年一个。**

**从 2008-11-01 到 2024-05-01：5660 天，约 15.5 年。**

  Profile   起始年    至今几年    管什么
  ------------------------------------------------------------------
  S         2011      13          实时流（最普及的一个）
  G         2014      10          录像存储与回放
  C         2014      10          门禁控制
  A         2014      10          门禁控制端
  Q         2016      8           即插即用安装
  T         2018      6           H.265、元数据、双向音频
  M         2021      3           元数据与视频分析
  D         2023      1           门禁外围设备

  **8 个 Profile 跨 12 年，中间 7 个间隔，平均 1.7 年一个。**
  **但前紧后松**：2011~2014 三年出了四个（S／G／C／A），**2018 之后六年只出了两个（M／D）。**
  **原因很实际**：**能划出来的「设备品类」就那么多**，划完了自然慢下来。

**为什么必须搞 Profile，而不是「一个规范管到底」**：

  做法                  问题                              Profile 怎么解决
  --------------------------------------------------------------------------------------
  一份大规范            摄像头和门禁要实现的接口完全不同  按品类切分
  厂商自己声明          声明了不代表真支持                **强制一致性测试**
  只要核心接口          核心接口无法覆盖录像、门禁        **分层：核心 + 扩展**

  **第二行是 Profile 真正的价值**：**它不是一个文档，是一套测试用例。**
  **过了才有资格印 ONVIF 的标。**
  **所以「支持 Profile S」这句话，比「支持 ONVIF」具体得多**——**后者几乎等于没说。**

「平均 1.7 年一个」这个数的分母是 7 不是 8：8 个点之间只有 7 个间隔。 这种「数点还是数间隔」的错误在算增长率时最常见，一错就是 12.5% 的偏差。 Profile 的起始年份是公开信息，不是我测的——这一段是「算」，不是「测」， 所以我只对算术负责，年份本身要查 ONVIF 官网。 「前紧后松」这个观察是从表里看出来的：2011~2014 三年四个，2018~2023 六年两个。 这不是统计结论，是读表结论，说清楚比说得像统计更诚实。

30 秒实验

1. 把 t1 改成今天，重算总天数和年数。
2. 把 Profile 数量假定成 10 个（假设 2025、2027 各出一个），看平均间隔变成多少。
3. 算一下 Profile S 从发布到现在的年数，占 ONVIF 全部历史的百分之多少。

常见误区

1. 以为「支持 ONVIF」是个明确的能力声明。 它几乎等于没说， 有意义的是「支持 Profile S／T／G」中的哪一个。
2. 以为 ONVIF 管编码和传输。 它只负责「发现、配置、要到地址」， 流怎么编、怎么传是 RTSP 和 FFmpeg 的事。
3. 以为 Profile 越多越新越好。 大多数项目只需要 S， 要录像才加 G，要 H.265 才看 T——追新没有收益。

下一节把 ONVIF 的技术框架拆开：一条请求的字节到底花在哪几层。

• ☐ （本节完，下一节 07.01.02 ONVIF的技术框架）

相关笔记

• ONVIF的技术框架
• SOAP简介
• 🎬 视频监控与国标 · 索引
• 📹 视频监控与国标 · 索引