search

mdhiggins / sonarr-sma

Sonarr docker based on linuxserver/sonarr with SMA built in using python3
MIT License
38 stars 18 forks source link

Enabling vaapi #37

Closed hroman73 closed 2 years ago

hroman73 commented 2 years ago

I try to enable vaapi on both sonarr-sma and radarr-sma but get the same error in the log:

E: Package 'libva' has no installation candidate

when i check ffmpeg -hwaccel i get:

ffmpeg: error while loading shared libraries: libva.so.2: cannot open shared object file: No such file or directory

How can I confirm it is utilizing the gpu when re-encoding?

mdhiggins commented 2 years ago

Did you build a vaapi supporting version of the container?

mdhiggins commented 2 years ago

You'll also need to pass your VAAPI device to the docker container

    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128

Device path may vary depending on your system

Also using just --hwaccel vaapi will only get you a decoder, you'll also need to choose a VAAPI enabled encoder as well for encoding

Getting full hardware level decoder to encoder passing without software abstraction gets even more complicated, see the HWAccel ffmpeg guide and the numerous issues on the main SMA repo for that but it will require you setting pretty much all the hwaccel related options

The radarr-sma repo also has some issues regarding VAAPI setup you can browse through

hroman73 commented 2 years ago

Yes I did both build as well as pass /dev/dri to the container...here is part of the docker-compose.yaml for Sonarr:

sonarr: hostname: sonarr container_name: sonarr build: context: https://github.com/mdhiggins/sonarr-sma.git#build args: sonarr-tag: develop ffmpeg_tag: 4.4-vaapi2004 depends_on:

mdhiggins commented 2 years ago

I wonder if this is an issue of mixing mono and Ubuntu. I believe the developer branch of Sonarr has migrated to mono but the VAAPI build of FFMPEG is Ubuntu.

Does rolling back to an earlier tag of Sonarr that's still on Ubuntu fix the issue by chance?

hroman73 commented 2 years ago

I switched the tag to latest and have the same issue...

E: Sub-process /usr/bin/dpkg returned an error code (1) E: Package 'libva' has no installation candidate

mdhiggins commented 2 years ago

It looks like the 'latest' tag has also been rebased to mono at this point (as of April) so that switch back to latest probably didn't change anything, feel free to correct me if I'm mistaken here

https://github.com/mdhiggins/radarr-sma/issues/34#issuecomment-1042711688

One option that might work is to not build FFMPEG or use the jrottenberg FFMPEG at all and instead use mono and pull FFMPEG from the repo, see that link for a radarr example but Sonarr should work too (at least on the develop tag which is definitely on mono)

hroman73 commented 2 years ago

i've done the update and the libva error is gone, how would i confirm that ffmpeg is using vaapi?

mdhiggins commented 2 years ago

You would have to look at your CPU/GPU usage during a job being run and then compare it with the VAAPI options turned off. Remember, adding the hwaccel parameter only turns on the decoder not the encoder though and decoding isn't all that intensive and not all input codecs will have a hw decoder. For the most performance gains I would include a VAAPI encoder as well (by adding it to the video codec list as your first codec)

https://unix.stackexchange.com/questions/525473/vaapi-usage-monitoring

h264vaapi and h265vaapi are the most common encoder choices