CentOS VAAPI

[dcrdev 251]

Just built my new server and am trying to get vaapi working with CentOS 7 - I previously had this working on my old machine with Fedora and amdgpu. This system however will be utilising the Intel graphics controller on my Xeon 1245v6.

 

I installed the following packages -

libva
libva-utils
intel-libva-driver

I also added the emby user to the video group and configured the transcoding device within Emby as /dev/dri/renderD128, which I believe is the DRM device that corresponds to the Intel chip. However ffmpeg is still doing cpu based encoding. The logs state this: "No VA display found for device" - the same thing happens if I run ffmpeg manually. Also I'm unable to gleam anything useful from vainfo due to it complaining about there being no active X Server, which there wont be considering the server is headless.

 

Has anyone managed to get this working? I'd rather not go down the QuickSync route as I don't want to have to maintain a patched kernel.

Edited August 16, 2017 by dcrdev

[Jdiesel 1114]

Was the version of ffmpeg you are using compiled with vaapi enabled? 

[mastrmind11 717]

Just built my new server and am trying to get vaapi working with CentOS 7 - I previously had this working on my old machine with Fedora and amdgpu. This system however will be utilising the Intel graphics controller on my Xeon 1245v6.

 

I installed the following packages -

libva
libva-utils
intel-libva-driver

I also added the emby user to the video group and configured the transcoding device within Emby as /dev/dri/renderD128, which I believe is the DRM device that corresponds to the Intel chip. However ffmpeg is still doing cpu based encoding. The logs state this: "No VA display found for device" - the same thing happens if I run ffmpeg manually. Also I'm unable to gleam anything useful from vainfo due to it complaining about there being no active X Server, which there wont be considering the server is headless.

 

Has anyone managed to get this working? I'd rather not go down the QuickSync route as I don't want to have to maintain a patched kernel.

I've seen a few members w/ it working on CentOS, search around.  However, I can tell you it definitely works on Debian flavors (running it in Ubuntu as we speak).  Not having an X server has no effect on it, as you mentioned headless boxes won't have it running, but I can still get output from vainfo.... so post the output of vainfo and we can go from there.

[dcrdev 251]

Was the version of ffmpeg you are using compiled with vaapi enabled? 

 

Yes definately - I used the same rpm spec, that I used on my old machine.

 

I've seen a few members w/ it working on CentOS, search around.  However, I can tell you it definitely works on Debian flavors (running it in Ubuntu as we speak).  Not having an X server has no effect on it, as you mentioned headless boxes won't have it running, but I can still get output from vainfo.... so post the output of vainfo and we can go from there.

 

Output of vainfo:

[root@example dominic]# vainfo
error: can't connect to X server!
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_34
libva error: /usr/lib64/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Edited August 16, 2017 by dcrdev

[Luke 37119]

While I don't yet have an answer, we are working on a new build system for all of our platforms and this will include a unified approach to ffmpeg and the various hardware acceleration libraries. So stay tuned for that. Thanks.

[dcrdev 251]

While I don't yet have an answer, we are working on a new build system for all of our platforms and this will include a unified approach to ffmpeg and the various hardware acceleration libraries. So stay tuned for that. Thanks.

 

Thanks whilst that's great news - I don't think my problem is ffmpeg or Emby.

[mastrmind11 717]

 

Yes definately - I used the same rpm spec, that I used on my old machine.

 

 

Output of vainfo:

[root@example dominic]# vainfo
error: can't connect to X server!
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_34
libva error: /usr/lib64/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

I'm googling a bit, but did you follow instructions for installing for your specific OS and chip?  Your vaapi/libva version looks pretty old.  Here's the output of my vainfo:

 

bill@XeonServer:/$ vainfo
error: can't connect to X server!
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Server - 1.7.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointEncSlice
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD

[dcrdev 251]

There weren't any instructions really available for CentOS, I just went by the Fedora procedure.

 

The vaapi version is the latest available in the epel repository - which is the Fedora backports for CentOS.

[mastrmind11 717]

There weren't any instructions really available for CentOS, I just went by the Fedora procedure.

 

The vaapi version is the latest available in the epel repository - which is the Fedora backports for CentOS.

Check the testing branch then, perhaps. But like I said, pretty sure there was a topic on this here in the past few weeks.

 

Sent from my SM-G950U using Tapatalk

[dcrdev 251]

OK as a sanity check - I created a persistent Ubuntu 17.04 live usb, installed libva and the Intel driver; I got exactly the same result as above.

 

I'm beginning to suspect this might have something to do with dual graphics, the board I have has a primitive ASpeed video controller for remote management and vga output. There's not really a way to disable it without also having another video card as Kaby Lake doesn't support vga and that's all the motherboard has.

 

I've tried setting the environment variable LIBVA_DRIVER_NAME to i915, but that hasn't helped.

[dcrdev 251]

Progress has been made - using a weird combination of blocking the vga jumpers on the motherboard and force enabling the iGPU in the bios, I'm now able to get vaapi on Fedora Rawhide with a bleeding edge version of libva and libva-intel-driver.

[root@[member="Localhost"] ~]# vainfo
error: can't connect to X server!
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva )
vainfo: Driver version: Intel i965 driver for Intel(R) Kabylake - 1.8.3
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointEncSlice
      VAProfileVP9Profile2            :	VAEntrypointVLD

The problem now is how to build the bleeding edge packages on CentOS, unfortunately it's dependency hell most of the build dependencies require package versions newer than that available on CentOS. I'm going to do some searching around to see whether anyone has done the work on this already.

[Jdiesel 1114]

Have you tried using "/dev/dri/card0" instead of "/dev/dri/renderD128"? I recall when I set up HW acceleration I had trouble getting renderD128 to work but Card0 did work. It may note be related or make a difference but I thought I'd mention it. 

[dcrdev 251]

Have you tried using "/dev/dri/card0" instead of "/dev/dri/renderD128"? I recall when I set up HW acceleration I had trouble getting renderD128 to work but Card0 did work. It may note be related or make a difference but I thought I'd mention it. 

 

Yeah it's not that - I believe the issue is that Kaby Lake support in libva was only added very recently.

 

However new problem - having temporarily built libva from git, I'm now getting this error in Emby:

[AVHWDeviceContext @ 0x5b509e0] No VA display found for device: /dev/dri/renderD128.
[vaapi @ 0x312f1e0] Failed to create a VAAPI device

[Andy777 21]

Just checking that you also built libdrm and intel-vaapi-driver?

 

For some stuff (although basic h264 should work without) you need the GPU firmware (GuC HuC DmC) and a very recent kernel.

[dcrdev 251]

Just checking that you also built libdrm and intel-vaapi-driver?

 

For some stuff (although basic h264 should work without) you need the GPU firmware (GuC HuC DmC) and a very recent kernel.

 

^ I did libva-intel-driver is the equivalent of intel-vaapi-driver in CentOS and libdrm is included in the base system. Regarding the firmware, that should be backported to the current RHEl/CentOS kernel for Kaby Lake.

 

On a side note however... hahahahahahahahahahahahahahahahahaha I'm king of the world:

 

 

It boiled down to a number of things in the end:

 

• Firstly the bios for my board was presenting some very weird dmi outputs to the Kernel when enabling the iGPU, resulting in a number of phantom devices. This was fixed in a rather hackish way through setting a jumper on the board and then force enabling the equivalent option in the bios itself. It's hard to explain why that worked, I won't go into it as it's unlikely anyone has my board with the same custom bios that I have.
• Secondly none of the libva or libva-intel packages in RPMFusion, Nux, EPEL or Negativo repos are using versions that are compatible with Kaby Lake. I had backport the packages myself from Fedora, fixing a few dependency version issues and removing wayland support.
• Thirdly and this is rather obvious - can't believe I missed it; ffmpeg has libva as a build time dependency and therefore ffmpeg also has to be built with a compatible version of libva.

Furthermore because this was SUCH a massive pain the arse - for anyone who stumbles across this in the future, below are the fruits of my packaging efforts:

 

RPMS

https://repo.dcrdev.com/el7/x86_64/libva-intel-driver-1.8.3-1.el7.centos.x86_64.rpm

https://repo.dcrdev.com/el7/x86_64/libva-1.8.3-1.el7.centos.x86_64.rpm

https://repo.dcrdev.com/el7/x86_64/libva-utils-1.8.3-1.el7.centos.x86_64.rpm

 

SOURCE RPMS

https://repo.dcrdev.com/el7/SRPMS/libva-1.8.3-1.el7.centos.src.rpm

https://repo.dcrdev.com/el7/SRPMS/libva-intel-driver-1.8.3-1.el7.centos.src.rpm

https://repo.dcrdev.com/el7/SRPMS/libva-utils-1.8.3-1.el7.centos.src.rpm

Edited August 17, 2017 by dcrdev

[mastrmind11 717]

Well done bro... well done!

[BeyondEvil 0]

Just built my new server and am trying to get vaapi working with CentOS 7 - I previously had this working on my old machine with Fedora and amdgpu. This system however will be utilising the Intel graphics controller on my Xeon 1245v6.

 

I installed the following packages -

libva
libva-utils
intel-libva-driver

I also added the emby user to the video group and configured the transcoding device within Emby as /dev/dri/renderD128, which I believe is the DRM device that corresponds to the Intel chip. However ffmpeg is still doing cpu based encoding. The logs state this: "No VA display found for device" - the same thing happens if I run ffmpeg manually. Also I'm unable to gleam anything useful from vainfo due to it complaining about there being no active X Server, which there wont be considering the server is headless.

 

Has anyone managed to get this working? I'd rather not go down the QuickSync route as I don't want to have to maintain a patched kernel.

 

I'm really hoping you will be the hero I so desperately need!

 

I'm running <a competitor> on an old Mac mini (2011) with an old Sandy Bridge CPU with an onboard Intel® HD Graphics 3000 GPU. https://ark.intel.com/products/53449/Intel-Core-i5-2415M-Processor-3M-Cache-up-to-2_90-GHz

 

And whenever I enable hardware acceleration I get horrible artifacts.

 

w/o HW acc:

 

w/ HW acc:

 

And I need HW acc to work, because w/o it my CPU goes haywire with +300% load, which means I can barely transcode one stream.

 

The machine is now running CentOS 7 with the latest kernel available from them: Linux 3.10.0-693.21.1.el7.x86_64

 

From what I've been able to gather, the issue likely lies somewhere around kernel/intel driver/vaapi, but I'm just a dummy with a keyboard...

 

What can I do to get this working?

 

Thanks a million!

Edited April 3, 2018 by BeyondEvil

[Luke 37119]

And the ffmpeg log?

[BeyondEvil 0]

And the ffmpeg log?

 

Not sure I can get hold of it, since <the competitor> doesn't seem to use the mainline ffmpeg (whatever that means). What else can I provide and/or do while transcoding is happening?

 

I'm happy to install ffmpeg https://linoxide.com/linux-how-to/install-ffmpeg-centos-7/ if that can aid in troubleshooting independently from the competitor. Maybe the issue doesn't even lie with my hardware/setup?

Edited April 3, 2018 by BeyondEvil

[Luke 37119]

Sorry I thought this was about using it with Emby.

[BeyondEvil 0]

No worries, totally reasonable assumption to make.

 

My question is really directed at dcrdev. Maybe I should've PM'd him instead...

[Luke 37119]

You may want to just open a support topic in the other community.

[BeyondEvil 0]

You may want to just open a support topic in the other community.

 

I have and I've gotten a lot of help. But we're stuck. Hence the desperation. I don't think the issue lies with that product, but rather my system, and it seems like dcrdev faced and overcame something similar and seems to be really knowledgeable about the moving parts involved. So, with a ton of luck, he'll swoop in here and save the day.

[dcrdev 251]

My issue stemmed from the fact that CentOS doesn't have a version of the libva drivers that are compatible with Kaby Lake, I had to compile my own and then compile a version of ffmpeg with vaapi support against those drivers. With the introduction of the self contained packages for Emby, this is no longer necessary and hence I removed them from my repo.

 

Essentially all I did was grab the latest libva, libva-intel-driver source rpms from Fedora - strip out the wayland bits and then compile with Mock targeting epel-7.

 

Edit: Oh and actually - you're on Sandy Bridge, so it's not going to be hardware support like it was for me. Since the competitor your referring to maintains their own fork of ffmpeg, I'd be inclined to ask for support over there. 

Edited April 3, 2018 by dcrdev

[BeyondEvil 0]

My issue stemmed from the fact that CentOS doesn't have a version of the libva drivers that are compatible with Kaby Lake, I had to compile my own and then compile a version of ffmpeg with vaapi support against those drivers. With the introduction of the self contained packages for Emby, this is no longer necessary and hence I removed them from my repo.

 

Essentially all I did was grab the latest libva, libva-intel-driver source rpms from Fedora - strip out the wayland bits and then compile with Mock targeting epel-7.

 

Edit: Oh and actually - you're on Sandy Bridge, so it's not going to be hardware support like it was for me. Since the competitor your referring to maintains their own fork of ffmpeg, I'd be inclined to ask for support over there. 

 

Thanks for getting back to me, I really appreciate it!

 

So, like I wrote earlier, I have reached out to them - and they've been a tremendous help. But the issue is still unresolved and it looks like the issue isn't really with them but rather with my hardware and/or choice of OS.

 

Basically the working theory is that the CentOS distributed kernel doesn't have the proper drivers (vaapi? intel? libva?).

 

So, scouring the web, I stumbled in here and what you did - and from the looks of it you seem to really understand how it all fits together so maybe you would be willing to spread the knowledge a little bit? Basically I either want to fix it - or reach the conclusion that in my case (combination of hardware and OS) it is unfixable. At least within reason.