Jump to content

HW Acceleration for AMD 300U with Docker and Unraid

NormSwarm

By NormSwarm
in Linux

 Share
Go to solution Solved by NormSwarm,

Recommended Posts

NormSwarm

NormSwarm   12

Posted
Posted (edited)

Hello,

So, I'm using linuxserver/emby:beta for my docker image, I've passed the devices /dev/dri/card0 and /dev/dri/renderD128  to the container.1955573457_Screenshot2022-12-21183043.png.801914a95fba943520d239313aef1ba1.png

Emby doesn't detect all the available profile for decoding and encoding (Also, I have an active Emby Premiere subscription).

I've installed into the image `vainfo` into the container to check that everything is good and I see all the profile (like HEVC, H264): 

root@bd304a409b20:/# vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 22.0.5 for AMD Radeon Vega 3 Graphics (raven, LLVM 13.0.1, DRM 3.47, 5.19.17-Unraid)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

As you can see, there are more profile than just MPEG-2 and VP9, but those aren't found by emby.

To test further, I've installed Jellyfin image. I've configured it to use hardware decoding using vaapi and selected the HEVC decoding (normal and 10 bit). I tested to stream to the browser a hevc 10bit file, it used hardware decoding without any issue. I check the GPU usage with radeontop.

Here is a transcode log from jellyfin proving that ffmpeg had no issue using the device.

transcode-log-jellyfin.log

Emby hardware detection log:

hardware_detection-63807243716.txt

What can I do to force Emby to recognize the VAAPI profiles ?

Edited by NormSwarm
Adding more logs
Link to comment
Share on other sites
NormSwarm

NormSwarm   12

Posted
  • Author
Posted

Also wanted to add, I have the same result with the official docker image emby/embyserver:beta which was the image I was using before.

I've switched to LinuxServer because it was easier for me to install vainfo into it.

Link to comment
Share on other sites
  • Solution
NormSwarm

NormSwarm   12

Posted
  • Author
  • Solution
Posted

So I've been digging more, making ffdetect just ouput the proper JSON I need to force the encoder/decoder.

Now when I actually trigger a transcoding I see this: 

22:10:17.868 [AVHWDeviceContext @ 0x70f5c0] libva: dlopen of /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so failed: /app/emby/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so)

I have the feeling this is the source of all the problems.

This is the version available of GLIBCXX in the libstdc++ provided by emby: 

root@bd304a409b20:/# strings /app/emby/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_DEBUG_MESSAGE_LENGTH

In comparison, this is the list of version available provided by Ubuntu: 

root@bd304a409b20:/# strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep  GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH



If I copy the lib from the Ubuntu GLIB, everything works, ffdetect and the transcoding. Basically, the GLIB package with Emby is too old to work properly with modern version of the radeon driver. 

cp   /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /app/emby/libstdc++.so.6

@Luke & @softworkz Please update the glib you pack inside Emby.

Link to comment
Share on other sites
NormSwarm

NormSwarm   12

Posted
  • Author
Posted

So, in case anybody is interested, the fix I found only works for the linuxserver image.

For the official emby image, I surmise it's related to the old version of GLIB used compared to the version of the AMD Driver installed into it (Mesa Gallium driver 22.2.3 for AMD Radeon Vega 3 Graphics (raven, LLVM 14.0.6, DRM 3.47, 5.19.17-Unraid)).

I still suggest updating the libstdc++ used in the image and in the package to provide GLIBCXX 3.4.29. This is surely the source of all the other post about HW acceleration disappearing. I think the graphic drivers got updated but no the GLIB.

Unfortunately, since even the Dockerfile used to create the image is closed source, I can't help more on this.

Hopefully that will help @Luke and @softworkz into fixing the problem.

Link to comment
Share on other sites
  • 3 weeks later...
Luke Emby Team

Luke   37066

Posted
Posted
On 12/23/2022 at 10:54 PM, NormSwarm said:

So, in case anybody is interested, the fix I found only works for the linuxserver image.

For the official emby image, I surmise it's related to the old version of GLIB used compared to the version of the AMD Driver installed into it (Mesa Gallium driver 22.2.3 for AMD Radeon Vega 3 Graphics (raven, LLVM 14.0.6, DRM 3.47, 5.19.17-Unraid)).

I still suggest updating the libstdc++ used in the image and in the package to provide GLIBCXX 3.4.29. This is surely the source of all the other post about HW acceleration disappearing. I think the graphic drivers got updated but no the GLIB.

Unfortunately, since even the Dockerfile used to create the image is closed source, I can't help more on this.

Hopefully that will help @Luke and @softworkz into fixing the problem.

@NormSwarm we will review this. Thanks !

Link to comment
Share on other sites
  • 2 weeks later...
alucryd

alucryd   216

Posted
Posted

@NormSwarmThe stdc++ issue only applies when you're running the linuxserver container and are trying to use anything outside of what we provide. On our image everything is compiled using the same version and should work out of the box, it doesn't matter whether it's an older version.

I've updated our whole video stack, including the mesa drivers, and I pushed an image for the purpose of debugging, it includes a copy of vainfo, the tag is 4.8.0.21-debug. Could you give it a try?

  • Thanks 1
Link to comment
Share on other sites
NormSwarm

NormSwarm   12

Posted
  • Author
Posted (edited)

@alucryd Still encountering the same issue.

I went reading about Mesa driver, and they removed support for hardware acceleration (avc, hevc, VC1) : https://forum.manjaro.org/t/upstream-mesa-removal-of-avc-hevc-vc-1-hardware-acceleration-amd-gpus/128385

So basically, Emby shouldn't use the upstream version of mesa, but a patched version that re-enable the hardware acceleration (it seems Ubuntu Jammy and Arch have gone that route).

Edit: if you're compiling Mesa for the package, it simply need to have the encoder/decoder enabled through configuration flags:
https://forum.endeavouros.com/t/endeavouros-mesa-codec-support/34607

or more direct:

https://github.com/archlinux/svntogit-packages/blob/packages/mesa/repos/extra-x86_64/PKGBUILD#L86 

Trying display: drm
libva info: VA-API version 1.17.0
libva info: Trying to open /lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Mesa Gallium driver 22.3.3 for AMD Radeon Vega 3 Graphics (raven, LLVM 15.0.7, DRM 3.47, 5.19.17-Unraid)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

 

Edited by NormSwarm
Link to comment
Share on other sites
NormSwarm

NormSwarm   12

Posted
  • Author
Posted

@alucryd We have a fix :D The encoder/decoder properly show up 

/ # vainfo
Trying display: drm
libva info: VA-API version 1.17.0
libva info: Trying to open /lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Mesa Gallium driver 22.3.3 for AMD Radeon Vega 3 Graphics (raven, LLVM 15.0.7, DRM 3.47, 5.19.17-Unraid)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

 

image.png.f3186b08e442c2f7c783965e818c5c00.png

  • Like 1
Link to comment
Share on other sites
  • 1 month later...
ouch

ouch   0

Posted
Posted
On 12/22/2022 at 10:25 PM, NormSwarm said:

So I've been digging more, making ffdetect just ouput the proper JSON I need to force the encoder/decoder.

Now when I actually trigger a transcoding I see this: 

22:10:17.868 [AVHWDeviceContext @ 0x70f5c0] libva: dlopen of /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so failed: /app/emby/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so)

I have the feeling this is the source of all the problems.

This is the version available of GLIBCXX in the libstdc++ provided by emby: 

root@bd304a409b20:/# strings /app/emby/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_DEBUG_MESSAGE_LENGTH

In comparison, this is the list of version available provided by Ubuntu: 

root@bd304a409b20:/# strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep  GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH



If I copy the lib from the Ubuntu GLIB, everything works, ffdetect and the transcoding. Basically, the GLIB package with Emby is too old to work properly with modern version of the radeon driver. 

cp   /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /app/emby/libstdc++.so.6

@Luke & @softworkz Please update the glib you pack inside Emby.

Thank you for the information. I am curious about the performance of hardware accelerated transcoding with AMD 300U, do you have any data about that? Thanks agian @NormSwarm

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...