波仔
📹 第十章 GB／T 28181协议原理
📄 一句话概括

回放之前必须先检索：平台问「这段时间有哪些录像」，设备才答得出「从哪能播」。 它和点播的区别是「要清单」还是「要流」——清单错了，后面怎么播都对不上。

📝 本节和前面几节的关系

前六节讲的全是「实时」。从这一节开始进历史。 历史比实时多两步：先检索清单，再按清单去回放或下载。 所以这一节是后面两节的前提。

一、检索查的是什么

检索的返回不是「文件列表」，是「时间段列表」： 每条记录给一个开始时间、一个结束时间，平台据此知道「这段可播」。 这一点和直觉不一样：设备里存的是文件，但报出来的是时间区间。 因为「文件怎么切」是设备自己的事，平台只关心「哪段时间有录像」。 所以同一个文件可能被拆成多条记录报出来，也可能多个文件被合并成一条。 判断「有没有录像」只看时间覆盖，别看条数。 记录里还有两个字段容易被忽略： Secrecy 表示这段录像的密级，Type 表示是定时录还是报警录。 做取证类项目时，这两个字段要落库，否则事后没法证明「这段录像是原始的还是被处理过的」。

二、切分方式决定体验

录像按什么粒度切，直接影响回放的顺滑程度。 按小时切最好索引，但跨小时的片段要拼； 按文件切和设备实际存储对齐，但文件大小不一、结果很乱； 按天切最简单，但一个文件几十 GB，定位极慢。 监控项目最常见的其实是「按事件」：移动侦测触发的录像天然一段一个事件。 听着很合理，实际有个大坑——摄像头前面有棵树的话，风一吹就是几十段。 所以「按事件」必须配合「合并」：相邻两段间隔小于几秒就并成一段， 否则检索结果会多到没法看。 这个合并逻辑不该放在设备端，因为设备只报事实，合并是平台的理解。 放在平台侧，换设备也不用改。

三、检索也要分页

道理和目录查询一样：SumNum 给总数，游标给续查位置。 区别在于记录大小： 一条设备条目九十多字节，一条录像记录一百八十多字节——同样的页大小，报文要大三倍。 所以录像检索的「每页条数」要比目录查询设得更小，常见是二十到五十条。 还有一个实际问题：检索时间段越长，返回越多。 一次查一个月的录像，可能几万条。 所以界面上要限制「最多查几天」，或者按天分组、点哪天查哪天。

四、动手 Demo：一天的录像，检索要返回多少条

造一条真实的录像记录，量它的长度。 再按三种切分方式算一天要返回多少条、报文多大。

item = ("<Item><DeviceID>34020000001320000001</DeviceID>"
        "<Name>北门</Name>"
        "<StartTime>2026-10-24T00:00:00</StartTime>"
        "<EndTime>2026-10-24T01:00:00</EndTime>"
        "<Secrecy>0</Secrecy><Type>time</Type></Item>")
print("一条", len(item), "字节")

for name, seg in (("按小时", 1), ("按半小时", 2), ("按事件", 20)):
    n = 24 * seg
    print(name, n, "条", "%.1f KB" % (len(item) * n / 1024.0))

实跑输出：

--------------------------------------------------------------------
一天的录像，检索要返回多少条
--------------------------------------------------------------------
**回放之前必须先检索**：**平台要问「这段时间里有哪些录像」，设备才答得出来「从哪播」。**
**它和点播的区别是：一个要「流」，一个要「清单」。**

  一条录像记录 186 字节

  切分方式                     一天记录数     返回报文
  -----------------------------------------------------------
  **按小时切**                 **24 条**      **4.4 KB**
  **按半小时切**               **48 条**      **8.7 KB**
  **按事件切（约 20 段）**     **480 条**     **87.2 KB**

**第一行和第二行差一倍，但都在几 KB**——**所以录像检索不是「量大」的问题。**
**它是「切得太碎反而难播」的问题**：
**一条记录就是一段可播的区间，切得越碎，回放时要切的次数越多。**

**录像切分方式直接影响回放体验**：
  切法           好处                       坏处
  -----------------------------------------------------------------------------
  **按小时**     **记录少、好索引**         **跨小时的片段要拼**
  **按文件**     **和设备实际文件对齐**     **文件大小不一，检索结果乱**
  **按事件**     **刚好一段一个事件**       **事件密时记录爆炸**
  **按天**       **最简单**                 **一个文件几十 GB，回放定位慢**

**第三行是监控项目的常态**：**移动侦测触发的录像本来就是「事件驱动」的，天然一段一个事件。**
**但一旦摄像头前面有棵树，风一吹就是几十段，检索结果能到几百条。**

**所以检索也要分页**，道理和目录查询一样：**`SumNum` 给总数，游标给续查位置。**
**只是录像记录比设备条目大得多（186 字节对 91 字节）**，**同样的条数，报文要大三倍。**

一条记录一百八十六字节， 比设备条目（九十多字节）大了一倍——因为多了起止时间和密级、类型这几个字段。 三行结果从 4.4 KB 到 87 KB，看着都不大，但最后一行暴露了真正的问题： 按事件切，一天就有四百八十条，查一个星期就是三千多条。 所以「按事件切」听着最合理，实际最需要合并：间隔小于五秒的相邻段要并成一段， 否则界面上一屏就刷完了。 那张切分对照表的第三行说的就是这件事： 「事件密时记录爆炸」不是理论风险，是装上去第一天就会遇到的现实。

30 秒实验

  1. 算一下：按小时切，一天几条？（24 条）
  2. 想一下：检索返回的是「文件列表」还是「时间段列表」？（时间段）
  3. 想一下：为什么「按事件切」必须配合合并？

常见误区

  1. 以为「检索返回的是文件列表」。 返回的是时间段，文件怎么切是设备的事。
  2. 以为「记录条数多说明录像多」。 只看时间覆盖，条数取决于切分粒度。
  3. 以为「按事件切最精确」。 事件密时记录会爆炸，必须合并。
自测三问（点开对答案） 1. 检索返回的每条记录包含什么？ —— **设备编号、起止时间、密级、录像类型**。 2. 为什么录像记录比设备条目大？ —— **多了起止时间（各十九个字符）和密级、类型字段**。 3. 「按天切」的坏处是什么？ —— **一个文件几十 GB**，回放定位极慢。

下一节讲回放：和点播只差一个字面量，但多了一整套播放控制。

相关笔记