Rebucca 视频分析模型/平台调研报告

调研日期：2026-07  调研对象：本地源码 rebucca-master，公开资料为宇图瑞视官网、Gitee/GitHub 仓库入口及项目 README。  结论摘要：Rebucca 更准确地说不是单一“视频分析模型”，而是一套开源的多路视频接入、流媒体转发、YOLO 小模型推理、大模型复核、布控规则与报警管理平台。它适用于面向安防监控的场景，做中小规模视频 AI 分析、园区/工地/仓库/门店等场景的低成本布控验证，也适合二次开发；但若目标是大规模生产级多路高并发、强 SLA、统一权限审计和工程化运维，需要进一步压测、加固和改造。

1. 资料来源与可信度

1. 官方网站：https://www.yuturuishi.com/  官网将 Rebucca 描述为基于 Python + ZLMediaKit + YOLO 的开源视频分析系统，支持 GB28181/RTSP/RTMP/ONVIF 接入、实时目标检测、区域入侵/滞留告警、跨摄像头追踪，并明确其为商业版 rebekah 的开源轻量版。
   
2. Gitee 仓库：https://gitee.com/Vanishi/rebucca  仓库 README 与本地 README.md 内容一致，显示项目定位、功能、部署要求、使用顺序、MIT License、仓库文件结构和技术标签。
   
3. GitHub 仓库：https://github.com/beixiaocai/rebucca  README 中列出 GitHub 地址；与Gitee仓库的README描述一致。
   
4. 本地源码：G:\Mobile office\rebucca-master本地源码是本报告主要依据，重点阅读文件包括：

• README.md
  
• config.json
  
• requirements-windows.txt
  
• requirements-linux.txt
  
• app/models.py
  
• app/urls.py
  
• app/analysis/manager.py
  
• app/analysis/pipeline.py
  
• app/analysis/biz_rules.py
  
• app/analysis/engines/*.py
  
• app/utils/MediaServerManager.py
  
• app/utils/ZLMediaKitApi.py
  
• app/views/StreamView.py
  
• app/views/AnalysisView.py
  

5. 商业版 Rebekah 手册：<font style="color:rgb(47, 50, 56);">https://beixiaocai.yuque.com/org-wiki-beixiaocai-vo72oa/rebekah</font>
   

由于 Rebucca 没有提供任何文档手册，只能参考其商业版 Rebekah 去了解这款产品，Rebekah是视频行为分析系统v5简称，C++开发的旗舰级Al视频分析系统，性能无与伦比、功能最强大。支持多芯片硬件加速，支持大型服务器与边缘设备，训练模型即可实现人脸、周界、烟火、跌倒等数千种行为检测算法。

2. Rebucca产品介绍

Rebucca 是一款面向视频监控场景的开源智能视频分析平台。采用 Python 开发，它把摄像头接入、流媒体转发、模型推理、区域布控、业务规则、报警截图和 Web 管理界面整合到一个 Django 项目中。适合二次开发、学习研究与轻量级部署。项目永久免费，无任何授权限制，个人学习、商业改造、二次分发都更加自由。 如果需要 AI 视频分析、摄像头智能识别、本地轻量部署，可以直接到 Gitee 或 GitHub搜索 Rebucca，下载源码开始搭建。

Rebucca 是由 Python + ZLMediaKit + YOLO 构建的视频分析系统。支持GB28181 / RTSP / RTMP / ONVIF 摄像头接入、实时目标检测、区域入侵/滞留告警、跨摄像头追踪、事件时间线回放。支持多 YOLO 版本、支持Pytorch、支持PaddleOCR、支持直接推理pt格式的模型、多任务类型、多推理引擎的算法管理。  

从产品形态看，它包含三层：

1. 视频接入与流媒体层  支持 RTSP、RTMP、FLV/HLS、GB28181、ONVIF 发现等摄像头/视频流接入方式，内置 zlm 目录，使用定制命名的 rebucca_zlm 作为 ZLMediaKit 进程，由 MediaServerManager 负责启动、停止、状态检测。
   
2. AI 推理与规则层  小模型侧支持 YOLO-PyTorch、ONNXRuntime、OpenVINO；业务流程支持小模型后处理、大模型后处理、YOLO小模型实时检测+LLM大模型语义复核、检测+ReID+后处理。规则侧支持区域入侵、越线检测、越线计数、方向入侵、密度报警、滞留报警。
   
3. Web 管理与报警运营层  通过 Django 提供视频管理、小模型管理、大模型管理、业务算法、布控管理、报警管理、录像/NVR、控制面板、多语言等页面和接口。
   

🔗 项目地址：

• Gitee：https://gitee.com/Vanishi/rebucca
  
• GitHub：https://github.com/beixiaocai/rebucca
  
• 官网：https://www.yuturuishi.com
  

3. Rebekah与Rebucca对比

rebekah是视频行为分析系统v5简称，是公司旗舰产品：C++ 底层极致开发，性能无与伦比、功能最强大。支持大型服务器与边缘设备，深度对接瑞芯微、昇腾、英伟达等芯片 NPU 硬件加速能力，单路视频推理毫秒级。基于 rebekah，无需考虑音视频开发、编解码开发、界面开发，只需训练自己的模型，即可轻松做出人脸检测、人脸识别、周界入侵、烟火检测、打架、斗殴、跌倒、人群聚集、电动车、垃圾箱、抽烟、攀爬、离岗、睡岗、安全帽、充电桩、工作服、疲劳检测、交通拥堵等数千种视频行为分析算法。

商业版 Rebekah 与开源版 Rebucca 对比区别如下：

商业版购买授权定价表（按不同芯片型号授权）：https://beixiaocai.yuque.com/org-wiki-beixiaocai-vo72oa/rebekah/bvda5lrygo8nq21q

商业版能够支持二次开发的功能：

• 训练基础算法
  
• 二次开发行为算法
  
• 自由组合业务算法（注：业务算法由0个或多个基础算法+1个行为算法组成）
  
• 二次开发报警接收服务器
  
• 开放接口
  
• 软件OEM贴牌，修改logo，修改前端页面
  

4. 部署环境条件

4.1 基础环境

README 给出的基础要求：

• Python 3.10+
  
• FFmpeg，可在 PATH 中，也可在 config.json 中配置路径
  
• ZLMediaKit，流媒体，端口需与 config.json 一致
  
• GPU 可选
  

如果是Linux系统，需要手动进入到zlm/bin.x86.gcc9.4 或 zlm/bin.arm.gcc9.4 ，确保可以正确执行 ./rebucca_zlm

如果执行./rebucca_zlm失败了，可以参考下面的两种方式解决安装环境问题

（1）解决方式一

sudo chmod -R a+x *

echo "export LD_LIBRARY_PATH=\"$(pwd):\$LD_LIBRARY_PATH\"" >> ~/.bashrc && source ~/.bashrc

（2）解决方式二

sudo apt update

sudo apt install -y libsrtp2-1

//下载ubuntu20的libssl1.1包

wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1f-1ubuntu2.24_amd64.deb

sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2.24_amd64.deb

//修复依赖

sudo apt -f install

<font style="color:rgb(47, 50, 56);"></font>

4.2 安装FFmpeg

ffmpeg-build的github：https://github.com/BtbN/FFmpeg-Builds/releases

展开之后选择版本，点击下载。这里选择ffmpeg-n8.1-latest-win64-gpl-8.1.zip（根据实际操作系统版本下载）

把下载的文件解压到目标目录，把FFmpeg添加到Windows环境变量

打开命令行，输入命令ffmpeg, 如果有以下信息输出，表示环境变量配置成功。

首次部署请编辑 <font style="color:rgba(0, 0, 0, 0.8);background-color:rgb(247, 247, 249);">config.json</font>（端口、ZLM、FFmpeg 等）和 <font style="color:rgba(0, 0, 0, 0.8);background-color:rgb(247, 247, 249);">settings.json</font>（界面品牌）。启动配置页保存后多数项热更新生效；改管理端口或调试日志需重启服务。

因为 ZLMediaKit 是项目内置的，因此无需另行部署 ZLMediaKit。只需部署 FFmpeg，之后进入Rebucca项目的config.json文件中，修改成自己的ffmpeg路径，例如：G:\\Tools\\ffmpeg\\ffmpeg-n8.1-latest-win64-gpl-8.1\\bin\\ffmpeg.exe。

当前 config.json 已配置：

• 管理端口：10001
  
• ZLM HTTP 端口：10002
  
• ZLM RTSP 端口：10554
  
• ZLM RTMP 端口：10935
  
• Windows ZLM 启动文件：zlm\bin.x86.windows10\rebucca_zlm.exe
  
• FFmpeg 路径：G:\Tools\ffmpeg\ffmpeg-n8.1-latest-win64-gpl-8.1\bin\ffmpeg.exe
  
• 自动启动流媒体：autoStartMedia = true
  
• 分析目标 FPS：analysisTargetFps = 5
  
• 分析进程模式：analysisProcessMode = 1
  
• 共享推理：analysisSharedInference = true
  
• 推理 worker 数：analysisInferenceWorkers = 2
  

4.3 安装Python环境所需依赖

Windows/Linux requirements 中核心依赖包括：

• Django 5.0.4
  
• opencv-python 4.10.0.84
  
• numpy 1.26.4
  
• onnxruntime 1.19.2
  
• ultralytics >= 8.0.0
  
• torch >= 2.0.0
  
• openai >= 2.0.0
  
• openvino >= 2024.0.0
  
• onvif_zeep 0.2.12
  
• requests、psutil、openpyxl、cryptography 等
  

在项目的根目录下的命令行终端执行：

# Windows

pip install -r requirements-windows.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

或

pip install -r requirements-windows.txt

# Linux

pip install -r requirements-linux.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

或

pip install -r requirements-linux.txt

4.4 启动方式

项目入口是标准 Django：

python manage.py runserver 0.0.0.0:10001

浏览器访问：

http://<host>:10001/

README 中说明默认账号为 admin / admin888。公开体验地址另有演示密码，但本地部署密码应以本地数据库实际账号为准。

登录后的后台管理界面如下：

4.5 Linux 注意事项

如果部署在 Linux，README 提醒需进入 zlm/bin.x86.gcc9.4 或 zlm/bin.arm.gcc9.4，确保 ./rebucca_zlm 可执行。可能需要：

• chmod -R a+x *
  
• 设置 LD_LIBRARY_PATH
  
• 安装 libsrtp2-1
  
• 在部分系统上安装兼容的 libssl1.1
  

5. 技术架构梳理

可以将 Rebucca 理解为如下链路：

摄像头/视频源

 -> RTSP/RTMP/GB28181/ONVIF 接入

 -> ZLMediaKit 拉流/转发

 -> Django 管理端生成可播放/可分析 URL

 -> CameraPipeline 解码与抽帧

 -> 小模型推理/大模型复核/ReID

 -> IoUTracker 目标追踪

 -> 区域/越线/方向/密度/滞留规则判断

 -> 报警截图 + AlarmModel 入库

 -> Web 报警管理/录像/控制面板展示

核心模块职责：

6. 功能作用分析

6.1 视频接入

源码中的 StreamModel 用于管理摄像头和视频流，字段覆盖拉流地址、协议类型、传输模式、用户名密码、转发状态、GB28181 设备 ID、ONVIF/摄像头元数据、录像开关等。路由中存在 /stream/index、/stream/online、/stream/openOnvifDiscover、批量导入导出、启停转发等接口。

实际作用：

• 手动添加 RTSP/RTMP/HTTP 视频流；
  
• 通过 ONVIF 发现局域网摄像头并解析 RTSP；
  
• 通过 GB28181 接入国标设备；
  
• 通过 ZLMediaKit 转成 RTSP、WS-FMP4、HTTP-FLV、RTMP 等播放/分析 URL；
  
• 支持 Excel 批量导入摄像头。
  

6.2 小模型管理

AlgorithmModel 是小模型元数据表，支持：

• YOLOv5、YOLOv8、YOLOv11、YOLO26、OSNet ReID；
  
• detect、segment、classify、pose、obb、reid 等任务类型；
  
• yolo_pytorch、onnxruntime、openvino 三类推理引擎；
  
• CPU、CUDA、OpenVINO GPU 等设备选择；
  
• 置信度、IoU、输入尺寸、标签列表、默认模型等参数。
  

本地 static/upload/weight 已存在示例/已上传模型：

• 20260705130932_yolo11n.pt
  
• 20260705205352_yolo11n.onnx
  
• 20260705205352_yolo11n.xml
  
• 20260705205352_yolo11n.bin
  

这说明当前源码已经具备 PyTorch、ONNX、OpenVINO 三种模型格式的实际配置基础。

6.3 大模型复核

LLMModel 用于配置 OpenAI 兼容 API，包括：

• API 地址；
  
• API Key；
  
• 模型名称；
  
• 超时时间；
  
• 推理工具字段，默认 OpenAI。
  

业务算法中可配置大模型提示词和校验关键词。典型作用是减少误报：例如小模型检测到“人”进入区域后，再把裁剪图或关键帧交给视觉大模型复核“是否有人翻越围栏”“是否存在烟火”等语义问题。

6.4 业务算法与布控规则

BizAlgorithmModel 将“小模型/大模型/后处理逻辑”组合成面向业务的规则。支持流程：

• 流程 1：小模型 + 后处理；
  
• 流程 2：大模型 + 后处理；
  
• 流程 3：小模型 + 大模型 + 后处理；
  
• 流程 4：检测 + ReID + 后处理。
  

后处理规则由 app/analysis/biz_rules.py 实现和解释，主要包括：

• AREA：区域入侵；
  
• LINE_CROSS：越线检测；
  
• LINE_COUNT：越线计数；
  
• DIRECTION：方向入侵；
  
• DENSITY：密度报警；
  
• DWELL：滞留报警。
  

后处理方案说明（共 6 种后处理，按场景选择）

• AREA 区域入侵

• 目标中心点进入布控多边形内即触发报警。适用于周界防范、禁入区域、危险区域等场景。
  

• LINE_CROSS 越线检测

• 有人沿方向线正向（A→B）跨过警戒线时，立即触发一次报警。同一人重复过线会去重。适用于围栏越界、禁止闯入等「一过线就报」的场景。与越线计数的区别：不累计人数，单次过线即报。
  

• LINE_COUNT 越线计数

• 在布控区域内按方向线 A→B 分别累计正向、逆向过线人数；任一方向累计达到设定阈值时才报警。适用于出入口人流统计、限流（如超过 50 人报警）等场景。
  
• 与越线检测的区别：越线检测是「过线立刻报」；越线计数是「累计到 N 人才报」，并可分别统计正向/逆向。
  

• DIRECTION 方向入侵

• 目标在区域内移动时，若运动方向与设定方向一致则报警。适用于单向通行、逆行检测等场景。参考角度与容差可在后端配置（默认向下 90°，容差 45°）。
  

• DENSITY 密度报警

• 布控区域内同时存在的目标数达到或超过阈值时报警（人数从低于阈值升到阈值时触发一次）。适用于人群聚集、排队过长、车辆拥堵等场景。需在布控中配置密度阈值。
  

• WELL 滞留报警

• 目标在布控区域内停留时间超过滞留阈值（秒）时报警。与区域入侵不同：区域入侵是「进入即报」，滞留是「待够时间才报」。滞留阈值在布控中配置。
  

ZoneModel 管理每路摄像头的布控区域，支持多边形坐标、警戒线端点、密度阈值、滞留阈值、检测间隔、检测帧数、区域颜色，以及绑定多个业务算法。

6.5 实时分析流水线

CameraPipeline 是单路摄像头实时分析核心。源码注释和实现显示其采用“解码线程 + 分析循环”的结构：

• 解码线程持续拉流并把最新帧写入有限队列；
  
• 队列满时丢弃旧帧，优先保证实时性；
  
• 分析循环按配置 FPS 节流；
  
• 先做运动检测门控，再跑多个检测器；
  
• 使用 IoUTracker 追踪目标；
  
• 命中布控业务规则后才截图、写报警事件。
  

这意味着 Rebucca 的设计目标偏实时监控，不追求离线逐帧全量分析。它会为了实时性主动丢帧，这对告警类场景通常合理，但对事后精确统计或法证级逐帧分析不是最优。

6.6 报警与录像

AlarmModel 保存报警记录，字段包括摄像头、事件类型、描述、发生时间、元数据 JSON。AnalysisView 支持报警列表、删除、批量删除、清空，并会同步删除报警截图。alarm_service.write_alarm 将分析事件写入数据库，元数据中包括 snapshot_path、区域、业务算法、目标类别、轨迹 ID 等。

RecordingModel 用于 24/7 录像分段索引，字段包括文件路径、开始结束时间、时长、大小、是否含运动、是否含目标。README 和路由中也有 NVR/录像页面。

7. 优势特点

1. 完全开源，商用门槛低  README 和 Gitee 均显示 MIT License，适合内网私有部署、二次开发和原型验证。
   
2. 端到端功能较完整  它不只是推理脚本，已经包含视频接入、流媒体、模型管理、布控、报警、录像、多语言、控制面板等完整闭环。
   
3. ZLMediaKit 内置，部署链路短  对当前环境尤其友好：项目自带 Windows/Linux/ARM 的 zlm 目录，config.json 可直接指向内置 rebucca_zlm.exe。
   
4. 模型格式和推理后端灵活  支持 .pt、.onnx、OpenVINO .xml/.bin，可按硬件选择 PyTorch、ONNXRuntime、OpenVINO。对普通 PC、NVIDIA GPU、Intel GPU/CPU 都有一定适配空间。
   
5. 业务规则丰富  支持区域入侵、越线、方向、密度、滞留等典型安防/园区/工地规则，比单纯 YOLO 检测更贴近真实业务。
   
6. 支持大模型复核  OpenAI 兼容 API 让它可以接入视觉大模型做二次判断，适合处理“是否违规”“是否异常”“是否有烟火”等语义复杂的场景。
   
7. 实时性设计明确  Pipeline 采用有限队列和丢旧帧策略，避免分析滞后无限积压，更适合实时告警。
   

✅ 免费 — MIT 开源协议，不限路数，不限功能，直接商用  ✅ 简单 — RTSP/GB28181/ONVIF 三大协议全支持，海康、大华、宇视插上就用，CPU 就能跑  ✅ 精准 — YOLO 小模型 + LLM 大模型双引擎，两次过滤，误报大幅减少

还有更多硬核能力：

• 六种布控规则随意组合（区域入侵、越线检测、越线计数、方向检测、密度报警、滞留报警）
  
• ReID 跨摄像头追踪，换摄像头照样认出来
  
• 内置 ZLMediaKit 流媒体，24h 录像
  
• 全栈本地化，数据不出内网
  
• 7 种语言切换，Docker 一键部署，10 分钟搞定
  

8. 局限与风险

1. 性能上限有限  官网也明确将 Rebucca 定位为开源轻量版，性能不如 C++ 商业版 rebekah。Python + Django + OpenCV + 多进程推理适合中小规模，但“几十到上百路稳定实时分析”需要硬件和软件专项压测。
   
2. SQLite 不适合高并发长期生产  当前本地存在 rebucca.sqlite3，源码中也对 ORM 操作加了线程锁。SQLite 对单机轻量部署方便，但大量报警、录像索引、多路并发写入时，建议评估迁移到 PostgreSQL/MySQL。
   
3. 安全加固不足，需要二次治理项目有登录、验证码开关和安全 key，但作为生产系统仍需补充：

• HTTPS/反向代理；
  
• 强密码策略；
  
• API 权限分级；
  
• 密钥脱敏；
  
• 操作审计；
  
• 内网访问控制；
  
• 摄像头账号密码加密存储。
  

4. 模型效果取决于训练数据  Rebucca 提供平台和推理框架，不自动保证识别准确率。真正上线前必须针对业务场景训练/微调模型，验证白天/夜晚/雨雾/遮挡/逆光/低码率等情况。
   
5. 大模型复核有成本与延迟  接入云端视觉大模型会带来网络延迟、调用费用和数据合规问题；如果视频数据敏感，应优先考虑本地多模态模型或只传裁剪小图，并做好脱敏。
   
6. 运维能力偏基础  当前适合手动启动和 Web 管理。若要生产运行，需要补 systemd/Windows Service、日志轮转、进程守护、健康检查、异常自动恢复、监控告警等。
   

9. 可行性评估

9.1 软硬件环境的可行性

项目部署环境需具备三个关键前提：

• Python 3.10+
  
• FFmpeg 已部署，直接部署编译好的版本，不要用未编译的源码版本，开源易部署，可行；
  
• ZLMediaKit 已内置，不需要单独部署。
  

本地 config.json 也已经指向 Windows 版内置 ZLM 和 FFmpeg 路径，说明在 Windows 上继续验证是可行的。建议下一步重点验证：

1. python manage.py runserver 0.0.0.0:10001 能否稳定启动；
   
2. 控制面板中 ZLMediaKit 是否自动启动并 API 可用；
   
3. 添加一路 RTSP 摄像头后是否能转发播放；
   
4. 上传/选择 YOLO11n 示例模型后能否完成小模型测试；
   
5. 创建区域入侵规则后能否生成报警截图；
   
6. 多路并发时 CPU/GPU/内存占用和报警延迟。
   

9.2 适合落地的规模

初步建议：

• 1-4 路：适合普通 PC 或轻量服务器验证；
  
• 4-16 路：建议使用 NVIDIA GPU 或较强 CPU，控制分析 FPS 和模型大小；
  
• 16 路以上：需要压测，可能要改数据库、进程管理、模型共享策略、流媒体配置；
  
• 生产级多站点：建议把流媒体、推理、数据库、Web 管理拆分部署或至少容器化。
  

具体路数取决于：

• 视频分辨率；
  
• 分析 FPS；
  
• 模型大小；
  
• CPU/GPU；
  
• 是否启用大模型复核；
  
• 是否全天录像；
  
• 摄像头编码质量和网络稳定性。
  

10. 好不好用：综合评价

10.1 对研发/集成方

好用。原因是代码结构比较直观，Django + SQLite + ZLMediaKit + YOLO 的组合容易理解，模型和业务规则都落在明确的数据表和 Python 模块中。要改功能、加规则、换模型、接自己的 OpenAI 兼容服务，都有清晰入口。

10.2 对最终业务用户

中等偏好用。它已经提供 Web 页面，使用顺序也明确：视频管理 -> 小模型 -> 大模型 -> 业务算法 -> 布控管理 -> 启动分析 -> 报警管理。但它仍偏技术型产品，使用者需要理解摄像头 RTSP、模型类别、置信度、区域绘制、规则绑定等概念。

10.3 对生产运维

需要补强。单机内置部署体验不错，但生产运维需要补服务化、数据库、日志、备份、安全、监控和自动恢复。

总体评价：作为开源视频 AI 分析平台，Rebucca 的完成度高于普通 demo；作为严肃生产系统，需要工程化加固后再上线。

11. 使用方法建议

11.1 标准使用流程

1. 启动服务  python manage.py runserver 0.0.0.0:10001
   
2. 访问管理端  http://<host>:10001/
   
3. 检查系统配置  确认 config.json 中 FFmpeg、ZLM 路径和端口正确；当前 ZLMediaKit 已内置，无需另装。
   

4. 添加摄像头  在“视频管理”添加 RTSP/RTMP/HTTP 视频源，或用 ONVIF 发现设备，确认能播放。
   

5. 配置小模型  在“小模型”中上传或选择 .pt/.onnx/.xml 模型，设置标签、输入尺寸、置信度、推理引擎和设备。
   

6. 配置大模型，可选  在“大模型”中配置 OpenAI 兼容 API，用于语义复核。
   

7. 创建业务算法  选择流程类型、目标类别、后处理规则、滞留/密度/方向/越线参数。
   

8. 布控管理  选择摄像头，画多边形区域或警戒线，绑定业务算法。
   

9. 启动分析  在布控或分析页面点击启动。注意 README 明确：服务重启后需要手动再次启动分析。
   

10. 查看报警  在“报警管理”中查看报警记录、截图、事件类型、业务算法和描述。
    

11.2 场景案例

案例 1：园区周界入侵

目标：夜间或非工作时间，有人进入围栏区域时报警。  配置：

• 摄像头：园区围墙 RTSP；
  
• 小模型：YOLO11n 或自训练 person 检测模型；
  
• 业务算法：流程 1，小模型 + AREA；
  
• 目标类别：person；
  
• 布控：沿围墙内侧画多边形；
  
• 报警：人进入区域后生成截图。
  

可扩展：

• 使用流程 3，让大模型复核“是否为真实人员进入禁区”，减少动物、光影、海报等误报。
  

案例 2：工地未戴安全帽检测

目标：工人进入施工区域且未戴安全帽时报警。  配置：

• 自训练 YOLO 模型，类别包含 person、helmet、no_helmet；
  
• 业务算法：流程 1 或流程 3；
  
• 目标类别：no_helmet；
  
• 后处理：AREA 或 DWELL；
  
• 布控：施工区多边形；
  
• 大模型复核：提示词判断“画面中人员是否未戴安全帽”。
  

注意：

• 原生后处理不包含“人与帽子关联”的复杂逻辑，若只靠类别检测，准确率取决于模型训练质量。严肃上线建议增加专门的 PPE 检测模型或后处理关联逻辑。
  

案例 3：仓库通道逆行/越线

目标：叉车或人员从禁止方向通过通道时报警。  配置：

• 小模型：person/forklift 检测；
  
• 业务算法：LINE_CROSS、LINE_COUNT 或 DIRECTION；
  
• 布控：通道中画警戒线或方向规则；
  
• 阈值：按方向或计数触发。
  

适合：

• 门禁通道；
  
• 装卸口；
  
• 单向通行区域；
  
• 物流仓储动线管理。
  

案例 4：门店客流密度告警

目标：某区域人数超过阈值时提示拥挤。  配置：

• 小模型：person 检测；
  
• 业务算法：DENSITY；
  
• 布控：收银台、入口等待区、展区；
  
• 密度阈值：例如 8 人；
  
• 报警：目标数量达到阈值后生成密度告警。
  

注意：

• 摄像头俯视角度、遮挡和人群密集会影响检测数量，需要现场校准。
  

案例 5：人员滞留

目标：人员在危险区域停留超过指定时间报警。  配置：

• 目标类别：person；
  
• 后处理：DWELL；
  
• 布控：危险区域；
  
• 滞留阈值：例如 30 秒；
  
• 分析 FPS：不用太高，1-5 FPS 通常足够。
  

适合：

• 配电房门口；
  
• 危险化学品区域；
  
• 仓库装卸口；
  
• 医院/养老院重点区域看护。
  

12. 二次开发建议

1. 数据库升级  从 SQLite 迁移到 PostgreSQL/MySQL，尤其是报警和录像索引。
   
2. 服务化部署  Windows 使用服务管理，Linux 使用 systemd；ZLMediaKit、Django、分析进程分开守护。
   
3. 安全增强  摄像头密码和大模型 API Key 加密存储；管理端加 HTTPS、强密码、权限分级和审计。
   
4. 模型工程化  建立模型版本管理、标签规范、阈值评估、误报/漏报样本回流和再训练流程。
   
5. 性能压测  以真实摄像头、真实分辨率、真实模型做 24-72 小时稳定性测试，记录 CPU/GPU、内存、ZLM、报警延迟。
   
6. 告警联动  增加 Webhook、企业微信/钉钉/短信、消息队列、工单系统或上级安防平台对接。
   
7. 生产观测  增加 Prometheus 指标、日志轮转、异常重启、磁盘水位保护和报警快照清理策略。
   

13. 总体结论

Rebucca 是一款可用度较高的开源免费的智能视频监控布控平台，优势在于“从视频接入到报警闭环”的功能完整性，以及对 YOLO、ONNXRuntime、OpenVINO 和 OpenAI 兼容大模型的灵活支持。对已经部署 FFmpeg、源码和内置 ZLMediaKit 的环境来说，继续做本地验证和场景 PoC 是可行的。

建议定位为：

• 适合：技术调研、算法验证、单机/小规模部署、园区/工地/仓库/门店等典型布控场景 PoC、二次开发底座。
  
• 谨慎：大规模多路生产分析、强安全合规场景、需要高可用和统一运维的平台级项目。
  

经测试系统仍存在一些bug，以及检测算法的效果有时候不是很准，有预算尽量使用其商业版本。如果真实使用推荐用 1 路真实摄像头完成“添加视频 -> 模型测试 -> 区域布控 -> 启动分析 -> 生成报警截图”的端到端验证；随后再逐步增加路数和规则，记录资源占用与报警准确率。