Deploying Viseron on the reComputer R2245

Abstract

This project was conducted on a reComputer R2245 equipped with a 4GB Raspberry Pi CM5, 64-bit Debian 13, and a Hailo-8 AI accelerator. A Viseron 3.5.3 container had already been running continuously for approximately nine days. A single 1280×720 H.264 camera was able to record continuously, and the Viseron web interface remained accessible. With Darknet performing continuous detection at 1 FPS, the container used approximately 50.7% CPU, the combined RSS of its processes was approximately 1.11GiB, and the CM5 temperature ranged from approximately 40.6°C to 42.8°C.

The Hailo-8 hardware itself operated normally. In a five-second random-input test using a YOLOv8s HEF model, it processed 503 frames, equivalent to approximately 100.6 FPS, with a hardware latency of 6.66ms. The average Hailo chip temperature was 29.55°C, and the CM5 showed no throttling.

1. Test Environment

1.1 Hardware and System

2. Deployment

2.1 Confirm That the Recording Drive Is Actually Mounted

Do not identify a drive from its directory name alone.

findmnt -T /mnt/nvme
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL
df -hT /mnt/nvme

The directory should be treated as a recording drive only when the SOURCE reported by findmnt points to an NVMe partition such as /dev/nvme0n1p1. If the NVMe drive has not been installed or mounted, stop continuous recording first instead of allowing Docker to create a directory with the same name on the system drive.

Recommendations for a production deployment:

1. Use a high-endurance NVMe SSD formatted as ext4.
2. Add the drive to /etc/fstab using its UUID.
3. Confirm that it is mounted successfully before starting Viseron.
4. Add a mount dependency to the service so that a missing NVMe drive does not cause recordings to fall back to eMMC.
5. Back up /srv/viseron/config, which contains both the PostgreSQL data and the Viseron configuration.

2.2 Recommended Compose File

The following Compose configuration is suitable for the R2245. Replace the image tag with a fixed version that has passed regression testing. Mapping the Hailo device is useful only when the HailoRT versions match.

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

Start and inspect the service:

cd /srv/viseron
docker compose up -d
docker compose logs --tail=200

Open the web interface at:

http://DEVICE_IP:8888

2.3 Recommended Camera Configuration

Use secrets.yaml to store camera credentials.

# 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:

Using the main stream for direct-copy recording and a lower-resolution substream for decoding and detection is one of the most effective optimizations for the CM5. Hailo accelerates neural-network inference only; it does not replace H.264/H.265 video decoding.

3. Single-Camera Recording and Resource Tests

3.1 Test Conditions

• One H.264 camera stream
• Recording initialization file reported 1280×720
• FFmpeg wrote fMP4 segments using -c:v copy, without re-encoding
• Darknet object detection at 1 FPS
• scan_on_motion_only: false, meaning inference continued even when there was no motion
• Five consecutive samples taken approximately two seconds apart
• No multi-camera browser preview or concurrent playback

3.2 Results

A Docker CPU value of 50% corresponds to approximately half of one CPU core.

The recording directory grew by 7,986,412 bytes in 15 seconds, equivalent to approximately 4.259Mbps. This result applies only to the current camera stream. Actual storage requirements should be calculated from the combined bit rate of all cameras:

Daily storage (GB) ≈ Total bit rate (Mbps) × 10.8

With 10GB of available storage, the current single-camera bit rate would provide space for only about five hours of additional recordings if no cleanup policy were applied. Therefore, an NVMe drive must be installed and verified before adding more cameras.

3.3 User Experience

During testing, the web home page returned HTTP 200, camera recording segments continued to grow, and valid object-detection snapshots were generated. Viseron's component-based configuration makes it possible to combine cameras, detectors, recording, and storage policies independently, making it well suited to users who are comfortable with YAML.

4. Hailo-8 Testing and Viseron Integration

4.1 Standalone Hardware Test

The host successfully detected the Hailo-8. A five-second inference test was performed with the system-provided yolov8s_h8.hef model:

4.2 Integrating Hailo-8 Using the Official Viseron Method

The expected Viseron configuration is:

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:

The device must also be mapped into the container:

devices:
  - /dev/hailo0:/dev/hailo0

The official Viseron documentation explicitly warns that its container currently uses HailoRT 4.22.0 and that other host driver versions may be incompatible. An example of the resulting error is:

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 detector

5. Viseron vs. Frigate

Viseron's main advantage is its openness and composability. For example, MOG2 can filter motion first, Hailo can then perform object detection, and post-processing or MQTT can handle the result. Its storage tiers also support architectures such as keeping recent continuous recordings on NVMe while archiving long-term events to a NAS.

Frigate's advantage is that detection, tracking, Review, and Home Assistant form a more complete product workflow. If the goal is to deploy Hailo-8 on an R2245 as quickly as possible rather than experiment with Viseron's components, Frigate is currently the safer default choice.

6. Recommendations

When to Choose Viseron

• You plan to deploy a small system with one to four cameras and primarily local recording.
• You are comfortable with Docker, YAML, RTSP, and basic Linux administration.
• You value tiered storage and flexible component composition.
• You can begin with motion detection or CPU-based detection while waiting for the Hailo versions to be aligned.
• You are willing to troubleshoot camera paths, dependencies, and drivers through logs.

When Frigate Is Currently the Better Choice

• Hailo-8 must be used for object detection immediately.
• You rely heavily on Home Assistant.
• Object tracking, Review, and audio events are higher priorities.
• You want to follow Seeed's existing R2000 deployment tutorial.
• You do not want to maintain a custom HailoRT container.