Hardware encoding on AMD A10 within a Docker container on Emby 4.0.0.2

[bkloppenborg 1]

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

[Luke 37060]

Interesting, @@softworkz, any thoughts?

[softworkz 3335]

@@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.

[bkloppenborg 1]

Here is the full hardware detection log after restarting the server.

 

I'll try Emby on bare metal tonight and report back.

HWDetect.txt

[softworkz 3335]

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..

[agates 2]

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?

[SkyBehind 23]

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

[softworkz 3335]

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

[agates 2]

 

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?

[softworkz 3335]

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.

[bkloppenborg 1]

@@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

[Luke 37060]

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.

[softworkz 3335]

@@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..)

[softworkz 3335]

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

[bkloppenborg 1]

@@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.

[softworkz 3335]

Let's wait and see whether @@alucryd or @@alturismo would be able to help you with this.

[alturismo 37]

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

[bkloppenborg 1]

@@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:

1. Container doesn't have the relevant devices forwarded - appears to be ok.
2. Container doesn't run with the relevant group permissions - appears to be ok.
3. Container doesn't have vaapi support. Emby ships libva, libva-drm - should be ok.
4. 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!

[agates 2]

@@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

[Luke 37060]

We actually base our Docker on arch linux in case it may help.

[agates 2]

I was looking here, is it not up to date?  https://github.com/MediaBrowser/Emby.Build/tree/master/docker-containers/base

[alturismo 37]

@@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:

1. Container doesn't have the relevant devices forwarded - appears to be ok.
2. Container doesn't run with the relevant group permissions - appears to be ok.
3. Container doesn't have vaapi support. Emby ships libva, libva-drm - should be ok.
4. 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

[bkloppenborg 1]

@@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.

[agates 2]

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

[bkloppenborg 1]

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