波仔
📹 第七章 ONVIF协议原理解析
📄 一句话概括

「视频分析」和「分析设备」的区别不在功能，在位置：一个跑在摄像机里，一个是独立机器。 所以它们的 service 也不同：前者是 analytics，后者是 analyticsdevice。

📝 本节和前面几节的关系

上一节讲「分析什么」，这一节讲「在哪台机器上分析」。 这一节是「诚实边界」最明显的一节——本机没有实现 analyticsdevice，所以没有 Demo 输出。

一、五个维度看差别

维度 视频分析 分析设备
跑在哪 摄像机固件里 独立的服务器或分析盒
service analytics analyticsdevice
算力 受摄像机芯片限制 可以堆 GPU
覆盖几路 只有自己这一路 可以看几十路
典型场景 运动检测、越界 人脸、车牌、行为分析

第三行是根本差别：摄像机芯片是为编码设计的，算力有限， 跑个帧差运动检测还行，跑人脸识别就不够。 所以「智能分析」在工程上分成两档：轻量的放前端（省带宽），重量的放后端（省前端成本）。 这个取舍在报价时很关键：前端智能贵在每台都要加钱，后端智能贵在一台要买好的。 十路摄像机的差价乘以十，可能还不如买一台分析服务器—— 这就是为什么存量项目升级几乎都选「加分析盒」。

二、本机只做了前一半

这是本节必须说清的一件事：

项 本机 说明
模块名 MotionDetector —
模块类型 tt:MotionDetection —
有没有 analyticsdevice 没有 只实现了 analytics
能不能当分析设备用 不能 缺整个 service

第三、四行是这一节的诚实边界：我没有实现 analyticsdevice 那一组接口， 所以「分析设备」这一节只有概念，没有 Demo 输出。 不编一个假的 GetAnalyticsDevices 来充数——那种「看起来跑通了」的假数据比没有更糟， 因为它会让人以为「照着做就能通」。 这一节的价值只在「知道有这条分支」，不在「能跑」。

三、分析设备在工程上怎么用

步 做什么 为什么
1 分析盒接入视频流（RTSP 拉） 它不改摄像机，只旁路看
2 分析盒产出结构化数据 人脸特征、车牌号
3 结果回写到 NVR 或平台 和录像时间对齐

第一行那个「旁路」是最大的优点：不用换摄像机，老设备也能智能化。 这也是为什么存量项目升级时，方案总是「加分析盒」而不是「换摄像机」—— 换设备的成本是分析盒的十倍以上。 但旁路有个代价：一路流被拉两次（NVR 一次、分析盒一次），摄像机要出双份带宽。 所以大项目里要给分析盒单独走一个网口，否则它会和录像抢带宽，表现是「录像有马赛克」。 第三行的「和录像时间对齐」是个隐藏难点： 分析结果带的是自己的时间戳，录像带的是设备的时间戳，两者差几秒就对不上画面。 所以分析盒必须和摄像机对时（07.02.06 那个 UTCDateTime 就用在这里）。

四、为什么不自己做前端智能

很多人会想「摄像机不是有算力吗，为什么不用」。 因为摄像机的算力和功耗是绑死的：

约束 后果 所以
芯片是编码专用的 跑通用算法效率低 只能跑轻量模型
功耗有上限（PoE 供电） 算多了会超功率 加不动 GPU
散热靠外壳 夏天满载会降频 算力不稳定

第二行最容易被忽略： PoE 供电的功率上限决定了摄像机不能堆算力——一台 30 瓦的摄像机，芯片再强也跑不了大模型。 所以「前端智能」这个词在工程上要打折：它做的是「轻量筛选」，不是「完整识别」。 第三行的降频更隐蔽：冬天的实验室跑得好好的算法，夏天装在铁壳里就掉帧， 而且日志里看不出来——只是「有时候不准」。 这也是为什么重算法宁可放后端：机房有空调。

五、动手 Demo：分析设备，是另一台机器

这一节没有能跑的分析设备——本机只实现了 analytics，没有 analyticsdevice。 所以 Demo 做的是「验边界」：调一个 analyticsdevice 的操作，看设备怎么回。 结果会是 Fault，而这个 Fault 本身就是本节的结论。

# analyticsdevice 这一组本机没实现，调一个试试
_a, b, _n = S.call(port, "analyticsdevice", "GetAnalyticsDevices")
r = ET.fromstring(b)
f = r.find(".//{%s}Fault" % S.NS_S)
print(f.find("{%s}Code/{%s}Value" % (S.NS_S, S.NS_S)).text)
print(f.find("{%s}Reason/{%s}Text" % (S.NS_S, S.NS_S)).text)

# 对照：analytics 这一组是有的
_a, b2, _n = S.call(port, "analytics", "GetAnalyticsModules")
print("modules fault:", b2.count("Fault"))

实跑输出：

--------------------------------------------------------------------
分析设备，是另一台机器
--------------------------------------------------------------------
**「视频分析」（07.02.13）和「分析设备」（07.02.14）的区别不在功能，在位置。**
  **一个在摄像机里跑，一个是独立的机器。**

**两者对比：**

  项                视频分析（VideoAnalytics）      分析设备（AnalyticsDevice）
  ----------------------------------------------------------------------------------
  跑在哪            **摄像机固件里**                **独立的服务器或分析盒**
  service           `analytics`                     **`analyticsdevice`**
  算力              受摄像机芯片限制                **可以堆 GPU**
  覆盖几路          **只有自己这一路**              **可以看几十路**
  典型场景          运动检测、越界                  **人脸、车牌、行为分析**

  **第三行是根本差别**：  **摄像机芯片是为编码设计的，算力有限**，
  **跑个帧差运动检测还行，跑人脸识别就不够。**
  **所以「智能分析」在工程上分成两档**：  **轻量的放前端（省带宽），重量的放后端（省前端成本）。**
  **这个取舍在报价时很关键**：  **前端智能贵在每台都要加钱，后端智能贵在一台要买好的。**

**本机模拟的是「视频分析」，不是「分析设备」：**

  项                          本机                    说明
  ------------------------------------------------------------------------------------
  模块名                      `MotionDetector`        —
  模块类型                    `tt:MotionDetection`    —
  有没有 `analyticsdevice`    **没有**                **只实现了 `analytics`**
  能不能当分析设备用          **不能**                **缺整个 service**

  **第三、四行是这一节的诚实边界**：  **我没有实现 `analyticsdevice` 那一组接口**，
  **所以「分析设备」这一节只有概念，没有 Demo 输出。**
  **不编一个假的 `GetAnalyticsDevices` 响应来充数**——
  **那种「看起来跑通了」的假数据，比没有更糟。**

**分析设备在工程上怎么用：**

  步    做什么                            为什么
  ----------------------------------------------------------------------
  1     分析盒接入视频流（RTSP 拉）       **它不改摄像机，只旁路看**
  2     分析盒产出结构化数据              人脸特征、车牌号
  3     结果回写到 NVR 或平台             **和录像时间对齐**

  **第一行那个「旁路」是最大的优点**：  **不用换摄像机，老设备也能智能化。**
  **这也是为什么存量项目升级时，方案总是「加分析盒」而不是「换摄像机」**——
  **换设备的成本是分析盒的十倍以上。**
  **但旁路有个代价**：
  **一路流被拉两次（NVR 一次、分析盒一次），摄像机要出双份带宽。**
  **所以大项目里要给分析盒单独走一个网口。**

这个 Fault 是模拟器的「未知操作」分支返回的， 不是「真实的 analyticsdevice 未实现」的规范响应—— 两者形状一样（都是 s:Sender），但含义不同。 这一点必须说清：我验的是「不认识的操作会回 Fault」，不是「设备缺这个 service」。 真实设备上，缺 service 的表现有三种：回 Fault、回 404、直接断连（07.02.05 那张表）。 所以「收到 Fault」只能说明「这条路不通」，说明不了「为什么不通」。 要区分原因，得看 GetServices 里有没有那一项。 第二段那个对照是必要的： 同样的客户端代码、同样的服务端，只是操作名不同，一个成功一个失败—— 这就把「环境问题」排除了，剩下的只能是「操作不存在」。 做对照实验的价值就在这里：控制变量。

30 秒实验

  1. 把 GetAnalyticsDevices 换成 GetSupportedRules，看还能不能拿到 Fault（应该不能）。
  2. 查 GetServices 的返回，确认里面有没有 analyticsdevice 那一项。
  3. 把模拟器里加一个空的 analyticsdevice 分支，看 Demo 的输出变成什么。

常见误区

  1. 以为「视频分析」和「分析设备」是功能差别。 是位置差别：一个在摄像机里，一个是独立机器。
  2. 以为前端智能能做人脸识别。 PoE 功耗和散热限制了算力，前端只适合轻量筛选。
  3. 把 Fault 当成「原因」。 Fault 只说「不通」， 要说清原因得看 GetServices 里有没有那个 service。
自测三问（点开对答案） 1. 「视频分析」和「分析设备」最根本的差别是什么？ —— **位置**：前者跑在摄像机固件里，后者是独立的服务器或分析盒。 **service 也不同**（`analytics` vs `analyticsdevice`）。 2. 为什么存量项目升级多用「加分析盒」而不是「换摄像机」？ —— **旁路不改原有设备，老摄像机也能智能化**；**换设备的成本是分析盒的十倍以上。** 3. 旁路方案有什么代价？ —— **一路流被拉两次**（录像一次、分析一次），**摄像机要出双份带宽**， 所以大项目要给分析盒单独走网口。

下一节讲显示：display 这一组和监控摄像机没关系， 它管的是「解码器怎么把多路画面拼到一块屏上」。

相关笔记