bkloppenborg 1 Posted January 16, 2019 Share Posted January 16, 2019 (edited) I would like to use the VAAPI hardware encoding working on my AMD A10-7870K APU (with a Radeon R7 integrated GPU) with Emby 4.0.0.2 running in a Docker container. I believe I have set up everything correctly, but the hardware detection script is returning an error code. Suggestions would be welcome. Background: I've configured Emby as suggested on DockerHub to enable VAAPI by adding the `video` group to the Emby GIDLIST and providing direct access to the `/dev/dri` devices as shown in this extract from my `docker-compose.yml` file: emby: image: emby/embyserver:latest restart: always networks: - web volumes: - /mnt/scratch/emby/config:/config - /mnt/scratch/emby:/mnt/emby ports: - "8096:8096" # http - "8920:8920" # https (not used) environment: - UID=1000 - GID=100 - GIDLIST=100,44 devices: - /dev/dri:/dev/dri container_name: emby On the host machine `vainfo` returns sensible results which shows the H264 encoding entrypoints are indeed present and operable: $ vainfo error: can't connect to X server! libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: mesa gallium vaapi 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 VAProfileNone : VAEntrypointVideoProc But when I run `ffdetect` from within the container, detection fails with an error code: # /bin/ffdetect vaencdec ffdetect version 4.0.2-emby_2018_12_09 Copyright (c) 2018-2018 softworkz for Emby Llc built with gcc 6.3.0 (crosstool-NG crosstool-ng-1.23.0) configuration: --cc=x86_64-pc-linux-gnu-gcc --arch=x86_64 --prefix=/home/embybuilder/Buildbot/x64/ffmpeg-x64/staging --pkg-config=pkg-config --disable-doc --disable-ffplay --disable-vdpau --disable-xlib --enable-fontconfig --enable-gnutls --enable-gpl --enable-iconv --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libwebp --enable-libx264 --enable-libzvbi --enable-version3 --enable-libsmbclient --enable-cuda --enable-cuvid --enable-libmfx --enable-nvenc --enable-vaapi --enable-cross-compile --cross-prefix=x86_64-pc-linux-gnu- --extra-libs='-lexpat -lfreetype -lfribidi -lfontconfig -liconv -lpng -lz -lvorbis -logg -lnettle -lhogweed -lgmp -laddns-samba4 -lasn1util-samba4 -lauthkrb5-samba4 -lCHARSET3-samba4 -lcliauth-samba4 -lcli-cldap-samba4 -lcli-ldap-common-samba4 -lcli-nbt-samba4 -lcli-smb-common-samba4 -lcom_err -lcommon-auth-samba4 -ldbwrap-samba4 -ldcerpc-binding -ldcerpc-samba-samba4 -ldl -lflag-mapping-samba4 -lgenrand-samba4 -lgensec-samba4 -lgse-samba4 -lgssapi_krb5 -llibcli-lsa3-samba4 -llibsmb-samba4 -linterfaces-samba4 -liov-buf-samba4 -lk5crypto -lkrb5 -lkrb5samba-samba4 -lkrb5support -lldb -lldbsamba-samba4 -lmessages-dgm-samba4 -lmessages-util-samba4 -lmsghdr-samba4 -lmsrpc3-samba4 -lndr -lndr-krb5pac -lndr-nbt -lndr-samba-samba4 -lndr-standard -lreplace-samba4 -lsamba-cluster-support-samba4 -lsamba-credentials -lsamba-debug-samba4 -lsamba-errors -lsamba-hostconfig -lsamba-modules-samba4 -lsamba-security-samba4 -lsamba-sockets-samba4 -lsamba-util -lsamba3-util-samba4 -lsamdb -lsamdb-common-samba4 -lsecrets3-samba4 -lserver-id-db-samba4 -lserver-role-samba4 -lsmbconf -lsmbd-shim-samba4 -lsmb-transport-samba4 -lsocket-blocking-samba4 -lsys-rw-samba4 -ltalloc -ltalloc-report-samba4 -ltdb -ltdb-wrap-samba4 -ltevent -ltevent-util -ltime-basic-samba4 -lutil-cmdline-samba4 -lutil-reg-samba4 -lutil-setid-samba4 -lutil-tdb-samba4 -luuid -lwbclient -lwinbind-client-samba4 -ldrm' --target-os=linux --enable-shared --disable-static libavutil 56. 14.100 / 56. 14.100 GetDeviceName: unable to open pci.ids file GetDeviceName unable to load pci.ids file [DEVICE] DeviceIndex=0 DEVICEINFO:VendorId=4098 DEVICEINFO:DeviceId=4879 DEVICEINFO:SubsytemVendorId=5208 DEVICEINFO:SubsytemDeviceId=53248 DEVICEINFO:DevPath=/sys/bus/pci/devices/0000:00:01.0 DEVICEINFO:DrmCard=/dev/dri/card0 DEVICEINFO:DrmRender=/dev/dri/renderD128 DEVICEINFO:IsEnabled=1 DEVICEINFO:IsBootVga=1 DEVICEINFO:ERROR:Number=-1 DEVICEINFO:ERROR:Message=Failed to initialize VA /dev/dri/renderD128. Error -1 [/DEVICE] Any thoughts on whats wrong here? Thanks. Edited January 16, 2019 by bkloppenborg Link to comment Share on other sites More sharing options...
Luke 37060 Posted January 16, 2019 Share Posted January 16, 2019 Interesting, @@softworkz, any thoughts? Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 16, 2019 Share Posted January 16, 2019 @@bkloppenborg - Could you please post the hardware detection log from emby? I don't have much experience with Docker. But maybe you'll need to install the latest AMD drivers inside the container... There's some Intel driver included in the Emby package, but that's not the case for AMD IIRC. PS: I would recommend running Emby on the host, not inside a container. Link to comment Share on other sites More sharing options...
bkloppenborg 1 Posted January 16, 2019 Author Share Posted January 16, 2019 Here is the full hardware detection log after restarting the server. I'll try Emby on bare metal tonight and report back. HWDetect.txt Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 17, 2019 Share Posted January 17, 2019 Emby is unable to access the render node. I've seen from others that they have devices: - /dev/dri/renderD128:/dev/dri/renderD128 In their docker file, but I got no knowledge in that area.. Link to comment Share on other sites More sharing options...
agates 2 Posted January 17, 2019 Share Posted January 17, 2019 Hi, I'm getting the same issue (same error in hwdetect), and have verified that /dev/dri/renderD128 is available in the docker container with the render gid. Here is the output of vainfo on my base system: libva info: VA-API version 1.3.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_3 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.3 (libva 2.3.0) vainfo: Driver version: Mesa Gallium driver 18.3.1 for Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.20.1-gentoo, LLVM 7.0.1 ) 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 VAProfileNone : VAEntrypointVideoProc It looks like radeonsi_drv_video.so is missing from the container. It's just part of mesa. Perhaps the Emby team could add vaapi drivers for radeonsi? Link to comment Share on other sites More sharing options...
SkyBehind 23 Posted January 17, 2019 Share Posted January 17, 2019 Emby is unable to access the render node. I've seen from others that they have devices: - /dev/dri/renderD128:/dev/dri/renderD128 In their docker file, but I got no knowledge in that area.. I don't remember what the specific line was when I did it CLI, it was something like mentioned above. I'm looking at my Portainer now, if using that, you have to add it under "Runtime & Resources" in the "Devices" section. host: /dev/dri/render128 container: /dev/dri/render128 For good measure, I also did /dev/dri/card0 Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 17, 2019 Share Posted January 17, 2019 (edited) Hi, I'm getting the same issue (same error in hwdetect), and have verified that /dev/dri/renderD128 is available in the docker container with the render gid. Here is the output of vainfo on my base system: No. vainfo must work inside the container. It looks like radeonsi_drv_video.so is missing from the container. It's just part of mesa. Perhaps the Emby team could add vaapi drivers for radeonsi? I'm afraid, that's not possible. There are just too many different versions and we cannot simply pick one. (personally, I don't even agree that we're including the Intel driver). As I said above, you will probably need to install the Radeon driver inside the container. Edited January 17, 2019 by softworkz Link to comment Share on other sites More sharing options...
agates 2 Posted January 17, 2019 Share Posted January 17, 2019 No. vainfo must work inside the container. I'm afraid, that's not possible. There are just too many different versions and we cannot simply pick one. (personally, I don't even agree that we're including the Intel driver). As I said above, you will probably need to install the Radeon driver inside the container. I am well aware that vainfo must work inside the container. I ran the command to give information on my drivers. Too many different versions of open source vaapi drivers? There are very few, and if this is your stance why do you even advertise docker support? Are all emby devs this condescending? Why do I pay for this product? Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 17, 2019 Share Posted January 17, 2019 Too many different versions of open source vaapi drivers? There are very few, and if this is your stance why do you even advertise docker support? Very few is still "few - 1" too many. For AMD there's no single driver that works with all hardware. For AMD hardware acceleration you need to download and install the latest Radeon driver for your GPU from the AMD website. Please see here for links and additional information: https://github.com/MediaBrowser/wiki/wiki/Hardware-Acceleration-on-Linux#va-api I would also like to let you know that Emby supports running as a Docker container, but hardware acceleration is not officially supported for this setup. It rather a community effort and there are a few members here that might be able to help you better than me in this case, although I've done my best to help you instead of saying "not supported" in the first place. Hope you understand better now. Link to comment Share on other sites More sharing options...
bkloppenborg 1 Posted January 17, 2019 Author Share Posted January 17, 2019 @@softworkz I've attached the hardware detection log from Emby 4.0.0.2 installed on bare metal. In this situation the hardware encoding program works correctly. So you are correct, its something missing in the Docker container. It looks like I need to install whatever package provides `mesa gallium vaapi` for this to work. HWDetect-bare-metal.txt Link to comment Share on other sites More sharing options...
Luke 37060 Posted January 17, 2019 Share Posted January 17, 2019 I apologize for the mixup here. He just meant in general across all gpu platforms, not vaapi in particular. Hardware acceleration for Docker at this point is still just getting started. For best results we recommend using the native package. Our Docker support will get there, but it will take time to learn what is needed within the container for each of the GPU platforms. Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 17, 2019 Share Posted January 17, 2019 @@softworkz I've attached the hardware detection log from Emby 4.0.0.2 installed on bare metal. In this situation the hardware encoding program works correctly. So you are correct, its something missing in the Docker container. It looks like I need to install whatever package provides `mesa gallium vaapi` for this to work. Thanks for the log. The detection looks good, but we had a number of issues reported with the "mesa gallum" drivers which were fixed after installing the latest AMD drivers instead. For Docker, I can't really tell whether they are required to be installed only inside the container or both inside and on the host. But I think the safest method would be to install both inside and outside. (any Docker expert please correct my if I'm wrong..) Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 17, 2019 Share Posted January 17, 2019 (edited) I apologize for the mixup here. He just meant in general across all gpu platforms, not vaapi in particular. I actually did mean vaapi drivers. But I didn't mean vaapi drivers in general, I specifically meant vaapi drivers for AMD gpus. The mesa gallum drivers have known issues and there is no single "one-fits-all" latest driver package from AMD. That's why we're not shipping it with any Linux package. (this is not specific to Docker) Edited January 17, 2019 by softworkz Link to comment Share on other sites More sharing options...
bkloppenborg 1 Posted January 17, 2019 Author Share Posted January 17, 2019 @@softworkz Understood. It appears that the Emby Docker image is built from scratch, so it lacks a package manager. In the Emby Docker build stuff here: https://github.com/MediaBrowser/Emby.Build/blob/master/docker-containers/base/Dockerfile The root filesystem is getting copied from a .tar.gz file. Do you know what flavor of Linux this stuff comes from? From other files, I'd guess OpenSuse Tumbleweed, but I'm not for sure. I just know the executalbes from my Ubuntu 18.04 host won't run in the Docker container and vice versa so it is unlikely the libraries will work either. Link to comment Share on other sites More sharing options...
softworkz 3335 Posted January 17, 2019 Share Posted January 17, 2019 Let's wait and see whether @@alucryd or @@alturismo would be able to help you with this. Link to comment Share on other sites More sharing options...
alturismo 37 Posted January 17, 2019 Share Posted January 17, 2019 (edited) not really ... i can say that AMD is also not supported by other apps in terms of hardware acc ... lets start with wich Host OS do you running and is AMD render access supported there ? example, on unraid (thats what i use here) i can use intel only (up to ix-8xxx), nvidia i d have to use a VM instead of a docker ... i already considered upgrading to an i9-9900 ... but that will be soonest supported from linux kernel 4.20 up ... so i wait ... linux ubuntu running a emby docker nvidia works fine ... just to show that it aint that simple with all kind of hardware around there .. and AMD, Docker, ... in summary i can say AMD aint the best choice for this usecase (hw acc on dockers ...) but first you would need to know if its even possible on your system that AMD can be accessed from the docker ... some systems cant do this with the prop ... AMD drivers (only open source ones ...), some systems doesnt support this at all, do you have any app on your system working with the AMD card ? here i always could cross check, TVHeadend, Plex and Emby using my Intel UHD630 device ... just to sort out if its a system or docker thing to start with ... and the error you see i also see here when ffdetect trys to check my nvidia cards (i also have a 1030 and 1070 installed) but they are passed to my 2 windows VM´s ... so docker cant access them .... Edited January 17, 2019 by alturismo Link to comment Share on other sites More sharing options...
bkloppenborg 1 Posted January 17, 2019 Author Share Posted January 17, 2019 @@alturismo My media center server runs an AMD A10-7870K APU (with a Radeon R7 integrated GPU) with Emby 4.0.0.2 running in a Docker container. The host OS is Ubuntu 18.04. On bare metal, both vainfo and ffdetect find VAAPI (I'll investigate how well it works this evening). Within the Docker, ffdetect errors out (see post #1 above). This machine is TUI only (i.e. it doesn't run X). There are no other GPUs in the system. The integrated GPU is not forwarded to any other Docker container or virtual machine. Here are the things that I think could be wrong: Container doesn't have the relevant devices forwarded - appears to be ok. Container doesn't run with the relevant group permissions - appears to be ok. Container doesn't have vaapi support. Emby ships libva, libva-drm - should be ok. Container doesn't have relevant drivers. Emby ships with libdrm_amdgpu. The host machine also has r600_drv_video.so. This could be an issue. Can you think of anything else? Lastly, it appears the libc versions differ between the Emby container and my Ubuntu system because I can't copy executable to/from the host and container and have them execute. This means my libraries probably won't work either. Given that Emby's Docker is built from scratch, what is the closest full Linux distribution on x86_64 from which I might try copying binaries/libraries? Thanks! Link to comment Share on other sites More sharing options...
agates 2 Posted January 17, 2019 Share Posted January 17, 2019 (edited) @@bkloppenborg the docker container uses kiwi and from what I could tell uses opensuse. The container image has RPM and wget inside. I used it to download (via https://software.opensuse.org) and install Mesa-libva but that didn't seem to be enough. And FYI my host system is Gentoo. Edited January 17, 2019 by agates Link to comment Share on other sites More sharing options...
Luke 37060 Posted January 18, 2019 Share Posted January 18, 2019 We actually base our Docker on arch linux in case it may help. Link to comment Share on other sites More sharing options...
agates 2 Posted January 18, 2019 Share Posted January 18, 2019 I was looking here, is it not up to date? https://github.com/MediaBrowser/Emby.Build/tree/master/docker-containers/base Link to comment Share on other sites More sharing options...
alturismo 37 Posted January 18, 2019 Share Posted January 18, 2019 (edited) @@alturismo My media center server runs an AMD A10-7870K APU (with a Radeon R7 integrated GPU) with Emby 4.0.0.2 running in a Docker container. The host OS is Ubuntu 18.04. On bare metal, both vainfo and ffdetect find VAAPI (I'll investigate how well it works this evening). Within the Docker, ffdetect errors out (see post #1 above). This machine is TUI only (i.e. it doesn't run X). There are no other GPUs in the system. The integrated GPU is not forwarded to any other Docker container or virtual machine. Here are the things that I think could be wrong: Container doesn't have the relevant devices forwarded - appears to be ok. Container doesn't run with the relevant group permissions - appears to be ok. Container doesn't have vaapi support. Emby ships libva, libva-drm - should be ok. Container doesn't have relevant drivers. Emby ships with libdrm_amdgpu. The host machine also has r600_drv_video.so. This could be an issue. Can you think of anything else? Lastly, it appears the libc versions differ between the Emby container and my Ubuntu system because I can't copy executable to/from the host and container and have them execute. This means my libraries probably won't work either. Given that Emby's Docker is built from scratch, what is the closest full Linux distribution on x86_64 from which I might try copying binaries/libraries? Thanks! may before trying further to get a docker running with amd hardware accel ... wich i dont know one where this is working .... try emby native on ubuntu and see what happens there ? as your ubuntu is headless anyway and hw accel is important for, did you try this scenario ? even there i assume AMD on linux and hw acc may not be the best friends ... but i hope it works for you ... and yes, in theory your points are correct, but as u may already checked elsewhere u ll see AMD aint the best solution therefore ... even intel is better supported on linux then nvidia. Edited January 18, 2019 by alturismo Link to comment Share on other sites More sharing options...
bkloppenborg 1 Posted January 18, 2019 Author Share Posted January 18, 2019 @@alturismo Already did this, see post #11 from two days ago. My next step is to build an arch-based docker container from scratch and see if I can get hardware acceleration working in there first. It'll be a lot easier with a package manager. Link to comment Share on other sites More sharing options...
agates 2 Posted January 19, 2019 Share Posted January 19, 2019 (edited) Hi, I made my own docker image based on Ubuntu to test this out, and HW decode appears to be working. HW encode gives me an error for the moment when trying playback in the browser, even though it looks like it's working in the background (can see CPU and GPU utilization go up and see files in the temp transcode folder). Git repo: https://gitlab.com/agates/emby-hwaccel-docker Screenshots from the Admin Dashboard: Edited January 19, 2019 by agates Link to comment Share on other sites More sharing options...
bkloppenborg 1 Posted January 19, 2019 Author Share Posted January 19, 2019 Given that @@agates successfully built a Docker image for Emby with vaapi support above, I decided to experiment more with hardware encoding/decoding on my AMD A10-7870k APU. Unfortunately, the results were not positive: 1) Hardware encoding appears broken (see attached log from Emby) on my APU. I investigated installing the proprietary drivers, but its going to be painful as they are four years out of date. (The latest version is Radeon Software Crimson Edition 15.12 for Ubuntu 14.04.) 2) The A10's hardware decoding of the MPEG2 TS streams (from a HD HomeRun) coupled with software encoding leaves odd horizontal streaks across the image. For now I'm going to postpone trying to get this to work and instead consider upgrading my machines. Thank you for the help above! AMD-A10-7870k-emby-bare-metal-vaapi.txt Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now