gbhub 网关截图：所有设备统一出图
版本：v2026.09 | 适用范围：gbhub 视频监控平台
一、核心机制
gbhub 不把截图命令透传给设备，而是自己从 ZLM 统一出图。
上级发 CaptureCmd → gbhub 收到 → gbhub 从本地 ZLM 抓帧 → 上传 → 回调上级
不管下级设备是什么型号、什么协议、什么能力，gbhub 都用同一种方式生成图片。
二、为什么要统一
2.1 设备差异是运维灾难
| 设备 | 如果各自实现 | 结果 |
|---|---|---|
| 2022 新 IPC | 支持 CaptureCmd，自己上传 | 一套流程 |
| 2016 老 IPC | 只支持 Snapshot，图回传 sip | 另一套流程 |
| 不支持截图的 NVR | 只能推流 | 又一套流程 |
| 第三方设备 | 私有协议 | 再一套流程 |
上级要为每一种设备适配，代码和配置失控。
2.2 gbhub 的做法：抹平差异
gbhub 不看设备，只看 ZLM。
| 步骤 | 由谁做 |
|---|---|
| 设备推流给 ZLM | 设备（所有设备都会推流） |
| 从 ZLM 抓帧 | gbhub（统一） |
| 上传图片 | gbhub（统一） |
| 上报索引 | gbhub（统一） |
设备只需要会推流——这是所有监控设备的基本能力。
三、统一出图流程
上级发 CaptureCmd
↓
gbhub 收到，不转发
↓
gbhub 确认 ZLM 有流（无流则内网触发拉流）
↓
gbhub 从 ZLM 抓一帧（127.0.0.1，本地）
↓
gbhub 上传图片（OSS / 上级服务器）
↓
gbhub 回调上级索引
全程 gbhub 主导，设备只负责推流。
四、核心优势
4.1 设备零适配
| 维度 | 传统透传 | gbhub 统一 |
|---|---|---|
| 设备要求 | 支持 CaptureCmd / Snapshot | 只要能推流 |
| 上级配置 | 每设备一套 | 一套 |
| 新设备接入 | 要适配协议 | 直接推流即可 |
| 老设备支持 | 不支持就无解 | 一样能截图 |
4.2 上级公网消耗恒定
不管什么设备，上级收到的都是：
- 一张图 250 KB
- 一个索引回调（几十字节）
从 7.5 MB（拉 30 秒流）降到 250 KB，节省 30 倍。
4.3 图片格式统一
- 分辨率统一（ZLM 输出一致）
- 压缩格式统一（JPEG）
- 命名规则统一
- 上传路径统一
上级拿到的图完全一致，不用处理各种设备差异。
4.4 索引统一
- 所有设备的截图进同一个 ZSet 索引
- 上级查询历史用同一套 API
- 分页、删除、清理全部统一
4.5 排查简单
- 图从哪来？gbhub 的 ZLM 抓帧
- 为什么失败？看 gbhub 日志
- 不用追设备端的实现
所有问题都在 gbhub 侧，可控。
五、和其他方案对比
| 维度 | 设备自己截 | gbhub 统一 |
|---|---|---|
| 设备要求 | 支持 2022 标准 | 只要能推流 |
| 老设备兼容 | ❌ | ✅ |
| 第三方设备 | 需私有适配 | ✅ 通用 |
| 图片格式 | 五花八门 | 统一 |
| 上传方式 | 每设备一套 | 统一 |
| 上级配置 | 每设备配 | 一套 |
| 故障排查 | 分散在各设备 | 集中在 gbhub |
| 公网消耗 | 看设备实现 | 恒定 250 KB |
六、适用场景
| 场景 | gbhub 统一出图的价值 |
|---|---|
| 多品牌设备混用 | 不需要分别适配 |
| 新老设备并存 | 老的也能截图 |
| 大量第三方接入 | 只要推流就行 |
| 上级要求统一格式 | 天然统一 |
| 运维人力有限 | 只维护 gbhub |
七、核心价值总结
| 维度 | 收益 |
|---|---|
| 设备兼容 | 只要能推流，就能截图 |
| 上级透明 | 一套配置，不感知设备差异 |
| 公网节省 | 恒定 250 KB / 次，节省 30 倍 |
| 格式统一 | 分辨率 / 压缩 / 命名 / 路径全一致 |
| 索引统一 | 所有设备进同一历史库 |
| 排查简单 | 问题都在 gbhub 侧 |
八、一句话总结
不管什么设备，只要会推流，gbhub 就能出图——上级永远只收到统一的 250 KB 图片。
gbhub 团队 | https://gb.automate.org.cn