search

weltenwort / frigate-synology-dsm7

Dockerfile and docker-compose file to enable google coral USB accelerators in containers on Synology DSM 7
MIT License
115 stars 18 forks source link

Help wanted if possible. Update to newer versions #41

Closed Caros2017 closed 1 year ago

Caros2017 commented 2 years ago

First of all, what a great project, thanks for sharing. I have a question and I am wondering how you solved this. I wanted to run the newest frigate on DSM7.

I changed these two lines in the dockerfile (line 1 and 16): From:

FROM blakeblackshear/frigate:0.10.0-amd64 AS build
FROM blakeblackshear/frigate:0.10.0-amd64

To:

FROM blakeblackshear/frigate:0.11.0-beta2 AS build
FROM blakeblackshear/frigate:0.11.0-beta2

If I want to build this docker I get:

Err:5 http://archive.ubuntu.com/ubuntu focal InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3B4FE6ACC0B21F32 NO_PUBKEY 871920D1991BC93C
W: GPG error: http://archive.ubuntu.com/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3B4FE6ACC0B21F32 NO_PUBKEY 871920D1991BC93C
E: The repository 'http://archive.ubuntu.com/ubuntu focal InRelease' is not signed.

Normally (it's not safe I know) you can solve this by adding: RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C

To run this you need to have gnupg2 installed. So I can add this to the dockerfile: RUN apt-get -y install gnupg2

The problem I am facing then is that for installing gnupg2 I get the same signature verification error.

How did you manage to solve this, or am I doing something wrong here?

weltenwort commented 2 years ago

Hi @Caros2017 :wave: Frigate v0.11.0 has changed the docker base image to Debian which means my manually added Ubuntu src repo is not compatible anymore. I'll have to switch to the Debian equivalent to rebuild libusb.

I've been delaying the update because 0.11.0 is still in beta and I couldn't anticipate how much will still change before the release. But maybe I can look into it during the weekend.

Caros2017 commented 2 years ago

Hi @weltenwort ! Now I understand the issue, thanks for the quick reply! I know it's a whole different question, but do you know if it's able to run without privileged=true, since libusb is used within docker?

deviant77 commented 2 years ago

Hi @Caros2017 👋 Frigate v0.11.0 has changed the docker base image to Debian which means my manually added Ubuntu src repo is not compatible anymore. I'll have to switch to the Debian equivalent to rebuild libusb.

I've been delaying the update because 0.11.0 is still in beta and I couldn't anticipate how much will still change before the release. But maybe I can look into it during the weekend.

Hi @weltenwort, I have it fully working in one of my branches, and have been testing the build for a while (and beta bugs aside it's working okay). I'll send you a PR shortly. Apologies for not following this up since we last spoke!

weltenwort commented 2 years ago

I know it's a whole different question, but do you know if it's able to run without privileged=true, since libusb is used within docker?

@Caros2017 there might be a way around it by granting specific capabilities, but I have not yet invested a lot of time into finding that out. I'd also be interested to run it with fewer privileges.

weltenwort commented 2 years ago

@deviant77 no worries :wink:

weltenwort commented 2 years ago

Based on @deviant77's contribution I created a v0.11.0-beta2 pre-release. Please let us know if this works for you.

Caros2017 commented 2 years ago

Based on @deviant77's contribution I created a v0.11.0-beta2 pre-release. Please let us know if this works for you.

That's really fast thanks! I have something new running now :). My events screen is not showing anything, but that has someting to do with frigate. Will figure that out after the weekend.

Caros2017 commented 2 years ago

I know it's a whole different question, but do you know if it's able to run without privileged=true, since libusb is used within docker?

@Caros2017 there might be a way around it by granting specific capabilities, but I have not yet invested a lot of time into finding that out. I'd also be interested to run it with fewer privileges.

I would love to see that. I am running nothing else in docker on DSM with priviliged:true. I got everything (including Zigbee and Z-wave stick) running on specific user:group privileges. This is possible with udev rules, because the drivers are added in DSM. Here there are no drivers, so I have no clue where to set the privileges.

Also the hwacell will be a challenge I think. But running without privileged:true will be a huge step forward already.

weltenwort commented 2 years ago

For accessing the DRI device we might be able to use the same solution as described in https://github.com/jellyfin/jellyfin/issues/2281. The device /dev/dri/renderD128 has the group videodriver on my host.

Regarding the coral USB device: Not sure if it possible to only mount a sub-tree of /dev/usb into the container. If it is, then a udev rule on the host and a group assignment similar to the above might help? :thinking:

Caros2017 commented 2 years ago

For accessing the DRI device we might be able to use the same solution as described in jellyfin/jellyfin#2281. The device /dev/dri/renderD128 has the group videodriver on my host.

Regarding the coral USB device: Not sure if it possible to only mount a sub-tree of /dev/usb into the container. If it is, then a udev rule on the host and a group assignment similar to the above might help? 🤔

I think there are 3 challenges. 1: /dev/dri/renderD128. In synology this is indeed mapped to group videodriver. I think this is indeed solvable by the issue mentioned above. 2: Coral USB drive. I am not sure if it is possible to only mount a subtree. Other issue I see is that you never know which device it gets mounted to? For Zigbee and Z-wave sticks I use these udev statements:

KERNEL=="ttyACM[0-9]*",OWNER="docker_user",GROUP="docker"
KERNEL=="ttyUSB[0-9]*",OWNER="docker_user",GROUP="docker"

To be honest I am lacking knowledge here. 3: Frigate seems to use S6-Overlay. This needs root to start. Solution can be a small custom script which drops privileges after being booted. Similar like this

Seems to be more complex than I initially hoped.

weltenwort commented 2 years ago

Seems to be more complex than I initially hoped.

indeed, but still worth keeping an eye on IMHO

Regarding the root user, there seems to be limited support for starting with other users: https://github.com/just-containers/s6-overlay#user-directive

baylanger commented 2 years ago

Hi! Fresh install on a DS720+ (geminilake) but with hwaccel enable, the camera's video in my browser lags and the frame never reaches "current time". Also the CPU doesn't seems to go down at all. The docker instance was created with "default" configuration posted here.

ffmpeg:
  hwaccel_args:
    - -hwaccel
    - vaapi
    - -hwaccel_device
    - /dev/dri/renderD128
    - -hwaccel_output_format
    - yuv420p

Camera feed is rtsp @ 3840 x 2160 @ 6fps.

Please share your hwaccel experience, I'm curious to know.

Great work @weltenwort - Thank you!

Caros2017 commented 2 years ago

Hi! Fresh install on a DS720+ (geminilake) but with hwaccel enable, the camera's video in my browser lags and the frame never reaches "current time". Also the CPU doesn't seems to go down at all. The docker instance was created with "default" configuration posted here.

{noformat} ffmpeg: hwaccel_args: - -hwaccel - vaapi - -hwaccel_device - /dev/dri/renderD128 - -hwaccel_output_format - yuv420p {noformat}

Camera feed is rtsp @ 3840 x 2160 @ 6fps.

Please share your hwaccel experience, I'm curious to know.

@baylanger see this bug report. I am experiencing the same unfortunately with all of the beta versions... :(

https://github.com/blakeblackshear/frigate/issues/3227

baylanger commented 2 years ago

see this bug report. I am experiencing the same unfortunately with all of the beta versions... :(

blakeblackshear/frigate#3227

After spending ~5 hours for a working solution (Coral + hwaccel), glad to hear it's a bug. Hopefully it gets fixed soon.

baylanger commented 2 years ago

I was seeing errors (see below) and noticed ffmpeg process kept crashing every ~5-10 seconds, the process would die and restart. That explains earlier docker reporting CPU jumping around for the instance and that the video kept lagging.

I tried qsv and I've got positive impacts. ffmpeg process being stable, CPU usage is now "constant" and video feed doesn't lag anymore.

Ref : https://github.com/blakeblackshear/frigate/issues/3227#issuecomment-1134022914

But the errors below differ from what is reported in the 3227 issue.

[2022-07-09 16:37:00] ffmpeg.living.detect           ERROR   : [h264 @ 0x5639fc487540] Invalid NAL unit 0, skipping.
[2022-07-09 16:37:00] ffmpeg.living.detect           ERROR   :     Last message repeated 2 times
[2022-07-09 16:37:00] ffmpeg.living.detect           ERROR   : [h264 @ 0x5639fc58e2c0] Increasing reorder buffer to 1
[2022-07-09 16:37:00] ffmpeg.living.detect           ERROR   : [AVHWFramesContext @ 0x7f3bb80c7300] Failed to sync surface 0x16: 23 (internal decoding error).
[2022-07-09 16:37:00] ffmpeg.living.detect           ERROR   : [h264 @ 0x5639fc251a00] Failed to transfer data to output frame: -5.
[2022-07-09 16:37:00] ffmpeg.living.detect           ERROR   : Error while processing the decoded data for stream #0:0
[2022-07-09 16:37:15] frigate.video                  ERROR   : living: Unable to read frames from ffmpeg process.
[2022-07-09 16:37:15] frigate.video                  ERROR   : living: ffmpeg process is not running. exiting capture thread...
[2022-07-09 16:37:20] watchdog.living                ERROR   : Ffmpeg process crashed unexpectedly for living.
deviant77 commented 2 years ago

I tried qsv and I've got positive impacts. ffmpeg process being stable, CPU usage is now "constant" and video feed doesn't lag anymore.

Ref : blakeblackshear/frigate#3227 (comment)

But the errors below differ from what is reported in the 3227 issue.

I'm not sure what hwaccel_args you are using, but for QSV it has changed since I wrote that post. For 0.11 beta 3, 4, and 5 it's now: hwaccel_args: -c:v h264_qsv

Beta 6 might ship with Jellyfin ffmpeg 5.0.1 (currently 4.4.1), so worth trying that when it's released.

baylanger commented 2 years ago

@deviant77 thanx for sharing the new args for qsv and the possibility of Jellyfin ffmpeg in the next beta.

I made the change this morning, somehow CPU for the ffmpeg process shows it went up ~1 %

2022-07-10_09-54-00

I'm not sure how to adjust the args for the 2 other processes... one of them might be the recording stream to disk and the other one for viewing the feed in the browser? I'll figure it out.

I was wondering how someone could make a "hass frigate addons" using this frigate-synology-dsm7 image? Late last night I fork the original hass addon, thinking I could copy/paste/modify between the 2 repos.. to realize it doesn't seem to be plug & play - at least not for someone like me who is fairly new w/ docker & hass.

Caros2017 commented 2 years ago

@deviant77 thanx for sharing the new args for qsv and the possibility of Jellyfin ffmpeg in the next beta.

I made the change this morning, somehow CPU for the ffmpeg process shows it went up ~1 %

2022-07-10_09-54-00

I'm not sure how to adjust the args for the 2 other processes... one of them might be the recording stream to disk and the other one for viewing the feed in the browser? I'll figure it out.

I was wondering how someone could make a "hass frigate addons" using this frigate-synology-dsm7 image? Late last night I fork the original hass addon, thinking I could copy/paste/modify between the 2 repos.. to realize it doesn't seem to be plug & play - at least not for someone like me who is fairly new w/ docker & hass.

Have you tested with the non-beta also? I have exactly the same setup and only Vaapi is working on the 0.10 version. The 11 beta version all give me bad results for Vaapi as well QSV.

For Hass add-on, I don't know what you mean. This docker image adds some drivers for Google coral on Synology, but for the rest it's exactly the same as the original Frigate. So you can use the regular Hass add-on for frigate in HomeAssistant.

weltenwort commented 2 years ago

I was wondering how someone could make a "hass frigate addons" using this frigate-synology-dsm7 image? Late last night I fork the original hass addon, thinking I could copy/paste/modify between the 2 repos.. to realize it doesn't seem to be plug & play - at least not for someone like me who is fairly new w/ docker & hass.

I assume you mean https://github.com/blakeblackshear/frigate-hass-addons? I looked at its manifest and it seems to use the same container images as the standalone version:

https://github.com/blakeblackshear/frigate-hass-addons/blob/4bfa11d1d632f90ddd2a3bd86a4edf7ed9bb7f59/frigate_fa_beta/config.yaml#L7

If true this means we should be able to fork the addon to use this synology-coral-enabled image variant. (This reminds me once again that we should try to contribute the synology support upstream once the stable version is released.)

baylanger commented 2 years ago

I assume you mean https://github.com/blakeblackshear/frigate-hass-addons? I looked at its manifest and it seems to use the same container images as the standalone version:

https://github.com/blakeblackshear/frigate-hass-addons/blob/4bfa11d1d632f90ddd2a3bd86a4edf7ed9bb7f59/frigate_fa_beta/config.yaml#L7

Yes.

I look at that file earlier and now realized I had misunderstood how the "addon" install process works.

True I could go that route. My hass install runs inside "Synology vmm". I plan to do quick video streaming / benchmark between frigate running inside the hass vm and a Docker instance. I allocated all 4 cores to the vm, this way I'm hoping hass reacts quickly to commands/events/etc. This time perhaps running frigate outside of hass makes sense if someone wants to control "cpu priority".

If true this means we should be able to fork the addon to use this synology-coral-enabled image variant. (This reminds me once again that we should try to contribute the synology support upstream once the stable version is released.)

Definitely.

I do wish the image would include more binaries, like "ps". Perhaps some of the hwaccel utilization reporting tools and few other debug tools.

baylanger commented 2 years ago

FYI for those of you having high CPU usage...

https://github.com/blakeblackshear/frigate/issues/3227#issuecomment-1186267881

weltenwort commented 2 years ago

That's great news, thanks for the pointer. And thank you @Caros2017 for submitting #55 which sets the appropriate ffmpeg-jellyfin env var by default.

baylanger commented 2 years ago

I tried frigate rc1 on my 720 ... somehow the CPU for some processes were higher and I'm not sure why.

I created this PR to update the image to rc1... not sure if that's all needed to make it happen?

https://github.com/weltenwort/frigate-synology-dsm7/pull/59

weltenwort commented 2 years ago

@baylanger thank you, I have merged your PR and created a v0.11.0-rc1 release

weltenwort commented 1 year ago

I've released an image for 0.11.0. Please feel free to open a new issue if you experience any problem with the Coral support. Problems with frigate itself should be directed at the upstream repository https://github.com/blakeblackshear/frigate directly.

Thanks all for your collaboration and @deviant77 for consistently delivering version bump PRs. :clap: