[Support]: 0.11-beta3 on RASPI4 utilizes 100% cpu

Describe the problem you are having

I use a dedicated RASPI4 64 bit RaspiOS buster + Edge TPU for Frigate. 8 CAM’s After upgrading from older test version 0.11.0-3de1948 (docker container) the beta3 utilize all cpu’s permanently (emtpy DB).

Before: ~40-50% total cpu load (average cpu shows 1.65) Beta3: 99% (average cpu shows more then 12) Especially each ffmepg process takes around 30% (before 5%)

Interessting fact: Dahua cameras are massively delayed using beta3

Config: idential (without max_seconds of course); Configuration file shows two camera configurations in one (no name and dahua hdbw3841e)

Any suggestion?

Version

0.11-beta3

Frigate config file

...
detectors:
  coral:
    type: edgetpu
    device: usb
...
record:
  enabled: False
  expire_interval: 60
  retain:
    days: 0
    mode: all
  events:
#    max_seconds: 300
    pre_capture: 5
    post_capture: 5
    objects:
      - person
    required_zones: []
    retain:
      default: 30
      objects:
        person: 90

snapshots:
  enabled: False
  clean_copy: True
  timestamp: False
  bounding_box: False
  crop: False
  height: 175
  quality: 70
  required_zones: []
  retain:
    default: 30
    objects:
      person: 90
ffmpeg:
  global_args: -hide_banner -loglevel warning
  hwaccel_args: 
    - -c:v         #ARM64bit
    - h264_v4l2m2m #ARM64bit
  input_args: -avoid_negative_ts make_zero -fflags nobuffer -flags low_delay -strict experimental -fflags +genpts+discardcorrupt -rtsp_transport tcp -stimeout 5000000 -use_wallclock_as_timestamps 1
  output_args: 
    detect: -f rawvideo -pix_fmt yuv420p
    record: -f segment -segment_time 60 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy -an
    rtmp: -c copy -f flv
...
  cam:
    ffmpeg:
      inputs: 
#        - path: rtsp://camerauser:{FRIGATE_RTSP_PASSWORD}@x.x.y.z:80/1 #no name camera
        - path: rtsp://camerauser:{FRIGATE_RTSP_PASSWORD}@x.x.y.z:554/cam/realmonitor?channel=1&subtype=1 #dahua hdb3841e

          roles:
            - detect
            - record
    detect:
#      width: 720 #no name
#      height: 480 #no name
      width: 704 #dahua
      height: 576 #dahua
      fps: 5
      enabled: True
      max_disappeared: 20
    motion:
      mask: [not shown]
    best_image_timeout: 10
    record:
      enabled: True
      expire_interval: 60
      retain:
        days: 0
        mode: all
      events:
        pre_capture: 5
        post_capture: 5
        objects:
          - person
        required_zones: []
        retain:
          default: 30
          objects:
            person: 90  
    rtmp:
      enabled: False
    live:
      height: 480
      quality: 8
    snapshots:
      enabled: True
      timestamp: False
      bounding_box: False
      crop: False
      height: 175
      required_zones: []
      retain:
        default: 30
        objects:
          person: 90
    mqtt:
      enabled: True
      timestamp: True
      bounding_box: True
      crop: True
      height: 270
      quality: 70
      required_zones: []
    objects:
      track:
        - person
      filters:
        person:
          mask:
            - [not shown]
    timestamp_style:
      position: "tl"
      format: "%Y-%m-%d %H:%M:%S"

Relevant log output

n/a - no errors

FFprobe output from your camera

n/a

Frigate stats

n/a

Operating system

Other

Install method

Docker Compose

Coral version

USB

Network connection

Wired

Camera make and model

dahua ipc-hdb3841e

Any other information that may be helpful

No response

[S-Przybylski]

The newer Image b36b635 seems to solve my problem with the no name cameras! Wow! I have re-integrated all 8 cam’s (6 no name and 2 dahua) with enabled hw accelaeration - all are working. The ffmpeg utilization is currently similar to the 0.11.0-3de1948 (very old image).

And yes I have changed the stimeout to timeout!

I leave this instance running to test how stable it will be. Thank you @blakeblackshear for your great support.

Any additional recommendation ? Could this be the next beta6?

[blakeblackshear]

@S-Przybylski I was able to reproduce this. I think its because the default pixel format from the hardware decoder changed between 4.3.3 and 4.3.4, so it’s having to do the extra work to convert NV12 to yuv420p. I tested jellyfin ffmpeg on arm64 and it’s better, so I am going ot switch to jellyfin everywhere. That’s probably better anyway.