在 reComputer R2245 上部署 Viseron
对 reComputer R2245 上的持续 Viseron 录制进行基准测试,并验证 Hailo-8 集成。
摘要
本项目在一台 reComputer R2245 上进行,该设备搭载 4GB Raspberry Pi CM5、64 位 Debian 13 以及 Hailo-8 AI 加速器。一个 Viseron 3.5.3 容器已持续运行约九天。一部 1280×720 H.264 摄像头能够持续录制,且 Viseron Web 界面保持可访问。在 Darknet 以 1 FPS 进行持续检测的情况下,容器 CPU 使用率约为 50.7%,其进程的合计 RSS 约为 1.11GiB,CM5 温度范围约为 40.6°C 至 42.8°C。
Hailo-8 硬件本身运行正常。在使用 YOLOv8s HEF 模型进行的五秒随机输入测试中,处理了 503 帧,相当于约 100.6 FPS,硬件延迟为 6.66ms。Hailo 芯片平均温度为 29.55°C,CM5 未出现降频。
1. 测试环境
1.1 硬件与系统
| 项目 | 测试设备上的结果 |
|---|---|
| 设备 | Seeed Studio reComputer R2245,主机名 reComputer-R22 |
| 计算模块 | Raspberry Pi Compute Module 5 Rev 1.0 |
| CPU | 四核 Arm Cortex-A76,最高 2.4GHz |
| 内存 | 4.0GiB |
| 操作系统 | Debian GNU/Linux 13.2 (trixie),ARM64 |
| 内核 | 6.12.62+rpt-rpi-2712 |
| 系统存储 | 29.1GB eMMC;测试期间已使用 66%,约 9.3GB 可用 |
| AI 加速器 | Hailo-8 M.2,设备节点 /dev/hailo0 |
| HailoRT/驱动/固件 | 4.23.0 / 4.23.0 / 4.23.0 |
| Docker | Docker CE 29.7.2,Compose 5.4.0 |
| 网络 | 千兆 IPv4 局域网上的 ETH0;测试期间已禁用其他接口 |
| 摄像头 | 一路 H.264 流;录制初始化文件报告为 1280×720 |
2. 部署
2.1 确认录制驱动器已实际挂载
不要仅凭目录名称来识别驱动器。
findmnt -T /mnt/nvme
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL
df -hT /mnt/nvme只有当 findmnt 报告的 SOURCE 指向 NVMe 分区(例如 /dev/nvme0n1p1)时,才应将该目录视为录制驱动器。如果 NVMe 驱动器未安装或未挂载,请先停止连续录制,而不要允许 Docker 在系统驱动器上创建同名目录。
生产部署建议:
- 使用高耐久性 NVMe SSD,格式化为
ext4。 - 使用其 UUID 将驱动器添加到
/etc/fstab。 - 在启动 Viseron 之前,确认其已成功挂载。
- 为服务添加挂载依赖项,以免 NVMe 驱动器缺失时录制回退到 eMMC。
- 备份
/srv/viseron/config,该目录同时包含 PostgreSQL 数据和 Viseron 配置。
2.2 推荐的 Compose 文件
以下 Compose 配置适用于 R2245。请将镜像标签替换为已通过回归测试的固定版本。仅当 HailoRT 版本匹配时,映射 Hailo 设备才有用。
services:
viseron:
image: roflcoopter/viseron:3.5.3
container_name: viseron
restart: unless-stopped
shm_size: "1024mb"
ports:
- "8888:8888"
volumes:
- /srv/viseron/config:/config
- /mnt/nvme/viseron/segments:/segments
- /mnt/nvme/viseron/snapshots:/snapshots
- /mnt/nvme/viseron/thumbnails:/thumbnails
- /mnt/nvme/viseron/event_clips:/event_clips
- /mnt/nvme/viseron/timelapse:/timelapse
- /etc/localtime:/etc/localtime:ro
# Enable this only after aligning the HailoRT version.
# Viseron requires version 4.22.0.
# devices:
# - /dev/hailo0:/dev/hailo0启动并检查服务:
cd /srv/viseron
docker compose up -d
docker compose logs --tail=200在以下地址打开 Web 界面:
http://DEVICE_IP:88882.3 推荐的摄像头配置
使用 secrets.yaml 存储摄像头凭证。
# secrets.yaml
camera_host: 192.168.10.101
camera_username: admin
camera_password: "REPLACE_WITH_THE_ACTUAL_PASSWORD"# config.yaml
ffmpeg:
camera:
camera_1:
name: Front Gate
host: !secret camera_host
port: 554
path: /Streaming/Channels/101/
username: !secret camera_username
password: !secret camera_password
substream:
port: 554
path: /Streaming/Channels/102/
stream_format: rtsp
mog2:
motion_detector:
cameras:
camera_1:
fps: 2
darknet:
object_detector:
cameras:
camera_1:
fps: 1
scan_on_motion_only: true
labels:
- label: person
confidence: 0.75
trigger_event_recording: true
nvr:
camera_1:将主码流用于直接复制录制,并使用较低分辨率的子码流进行解码和检测,这是针对 CM5 最有效的优化之一。Hailo 仅加速神经网络推理,它不能替代 H.264/H.265 视频解码。
3. 单路摄像头录制与资源测试
3.1 测试条件
- 一路 H.264 摄像头流
- 录制初始化文件报告为 1280×720
- FFmpeg 使用
-c:v copy写入 fMP4 片段,未重新编码 - Darknet 物体检测,帧率为 1 FPS
scan_on_motion_only: false,即无运动时仍持续推理- 连续采样五次,间隔约两秒
- 无多摄像头浏览器预览或并发回放
3.2 结果
| 指标 | 测量结果 |
|---|---|
| Viseron 容器平均 CPU 使用率 | 50.66% |
| 五次采样 CPU 范围 | 49.78%–51.94% |
| 容器内进程合计 RSS | 约 1140.5MiB |
| 进程数 | 158–159 |
| CM5 温度 | 40.6–42.8°C |
| 降频/欠压标志 | 0x0 |
| 短期录制数据速率 | 约 4.259Mbps |
| 预估每日录制量 | 约 46.0GB/天 |
| 局域网内 Web 首页响应时间 | 10 次请求平均 39.29ms |
Docker 的 CPU 使用率 50% 约相当于半个 CPU 核心。
录制目录在 15 秒内增长了 7,986,412 字节,相当于约 4.259Mbps。此结果仅适用于当前摄像头流。实际存储需求应根据所有摄像头的组合比特率计算:
Daily storage (GB) ≈ Total bit rate (Mbps) × 10.8在可用存储为 10GB 的情况下,若不应用清理策略,当前单路摄像头比特率将仅能提供约五小时的额外录制空间。因此,在添加更多摄像头之前,必须安装并验证 NVMe 驱动器。
3.3 用户体验
测试期间,Web 首页返回 HTTP 200,摄像头录制片段持续增长,并生成了有效的物体检测快照。Viseron 基于组件的配置使得可以独立组合摄像头、检测器、录制和存储策略,非常适合熟悉 YAML 的用户。
4. Hailo-8 测试与 Viseron 集成
4.1 独立硬件测试
主机成功检测到 Hailo-8。使用系统提供的 yolov8s_h8.hef 模型进行了五秒推理测试:
| 指标 | 测量结果 |
|---|---|
| 已处理帧数 | 503 |
| 等效吞吐量 | 约 100.6 FPS |
| 硬件延迟 | 6.66ms |
| 最低 Hailo 温度 | 29.02°C |
| 平均 Hailo 温度 | 29.55°C |
| 最高 Hailo 温度 | 29.68°C |
| 测试前后 CM5 温度 | 40.6°C / 44.4°C |
| CM5 降频标志 | 0x0 |
4.2 使用官方 Viseron 方法集成 Hailo-8
预期的 Viseron 配置为:
hailo:
object_detector:
cameras:
camera_1:
fps: 1
scan_on_motion_only: true
labels:
- label: person
confidence: 0.75
trigger_event_recording: true
nvr:
camera_1:同时必须将设备映射到容器内:
devices:
- /dev/hailo0:/dev/hailo0Viseron 官方文档明确警告,其容器当前使用 HailoRT 4.22.0,其他宿主机驱动版本可能不兼容。由此产生的错误示例如下:
Driver version (4.23.0) is different from library version (4.22.0)
HAILO_INVALID_DRIVER_VERSION(76)
Failed to detect Hailo architecture
Failed to start Hailo 8 detector5. Viseron 与 Frigate 对比
| 类别 | Viseron | Frigate |
|---|---|---|
| 开源许可证 | MIT | MIT |
| ARM64 Docker 支持 | 支持多架构镜像 | 支持 ARM64,包括面向 Raspberry Pi 的构建 |
| 配置模型 | 可自由组合摄像头、移动侦测、物体检测、NVR、存储等组件 | 围绕摄像头、检测、跟踪、Review 与录像功能组织 |
| 连续/事件录像 | 支持灵活的分层存储 | 支持简洁的保留策略 |
| 物体检测 | Hailo、Coral、Darknet、Ultralytics、外部服务等 | Hailo、Coral、ONNX、OpenVINO、TensorRT 等 |
| 本设备 Hailo-8 状态 | 容器 4.22 与宿主机 4.23 冲突,目前不可用 | Seeed 提供 R2000/Hailo 参考教程,实际版本仍需验证 |
| 物体跟踪 | 可围绕检测事件录像,但跟踪并非其强项 | 跟踪与 Review 是工作流核心组成部分 |
| 音频检测 | 非主要功能 | 内置音频事件检测 |
| 存储 | 多层存储,支持独立的事件与连续录像控制 | 为连续、移动、警报与检测录像提供清晰的保留策略 |
| Home Assistant | 通过 MQTT 发现方式集成 | 集成更成熟,社区资源更丰富 |
| 学习曲线 | 较高,组件组合灵活 | 中等,上手路径更统一 |
| 最适合 | 希望自定义检测流水线与存储策略的用户 | 优先考虑跟踪、Review、Home Assistant 及成熟部署示例的用户 |
Viseron 的主要优势在于其开放性与可组合性。例如,可先用 MOG2 过滤移动,再由 Hailo 执行物体检测,最后通过后处理或 MQTT 处理结果。其存储分层也支持将近期连续录像保存在 NVMe,同时将长期事件归档至 NAS 等架构。
Frigate 的优势在于检测、跟踪、Review 与 Home Assistant 构成了更完整的产品工作流。若目标是尽快在 R2245 上部署 Hailo-8,而非体验 Viseron 的组件组合,Frigate 目前是更稳妥的默认选择。
6. 建议
何时选择 Viseron
- 计划部署 1 至 4 路摄像头的小型系统,且以本地录像为主。
- 熟悉 Docker、YAML、RTSP 及基本的 Linux 管理。
- 重视分层存储与灵活的组件组合。
- 可以先使用移动侦测或基于 CPU 的检测,等待 Hailo 版本对齐。
- 愿意通过日志排查摄像头路径、依赖与驱动问题。
何时 Frigate 是当前更优选择
- 必须立即使用 Hailo-8 进行物体检测。
- 重度依赖 Home Assistant。
- 物体跟踪、Review 与音频事件具有更高优先级。
- 希望遵循 Seeed 现有的 R2000 部署教程。
- 不想维护自定义的 HailoRT 容器。