[SOLVED] Slackware64-14.2 i5-7200U hardware video acceleration problem

zdolar · 03-10-2018, 11:55 AM

Hi!

Can not find any tutorial/FAQ about set up hardware video acceleration on integrated video GPU.

My config:

Slackware64-14.2 on Intel i5-7200U (Kaby lake), Intel HD620 GPU.

I installed:
intel-vaapi-driver-2.1.0
libva-2.1.0
libva-utils-2.1.0
libdrm-2.4.90

ffmpeg-3.4.2-x86_64-1alien.txz
vlc-3.0.0-x86_64-2alien.txz

intel-vaapi-driver installed i965_drv_video drivers in /usr/lib64/dri folder
Here are also gallium_drv_video.so gallium_drv_video.la

I'm confused, as in ffmpeg.Slackbuild are statements:

# VAAPI can enable hardware accelerated playback for MPEG-2/4, H.264/AVC
# and VC-1 video on certain graphics hardware.
# The VAAPI support in this ffmeeg package depends on VA drivers that you have
# to install yourself for your specific hardware. The drivers should go into
# directory /usr/lib${LIBDIRSUFFIX}/va/drivers .
# If you install my libva package you can get MPEG-2 hardware acceleration on
# Intel graphics

intel-vaapi-driver-2.1.0 installed in /usr/lib64/dri, above suggests /usr/lib64/va/drivers

Tried symlink intel-vaapi-driver-2.1.0 files from /usr/lib64/dri to /usr/lib64/va/drivers

There is no hardware video accelereation, video is slow with ffplay, for VLC see below error.

Claim from above VLC & ffmpeg packages author:
"I do not have an isue with H.265 video playback here with the vlc-3.0.0-x86_64-2alien package. I downloaded https://s3.amazonaws.com/x265.org/vi...s_400_x265.mp4 to test (note: that file only contains video, no audio) and that video plays back just fine."

But at try to play H.265 video with VLC, I get:
Codec not supported:
VLC could not decode the format "hevc" (MPEG-H Part2/HEVC (H.265))

vainfo response:
root@video:~$ vainfo
libva info: VA-API version 1.1.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_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.1.0
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

ffmpeg response:
root@video:~$ ffmpeg
ffmpeg version 3.4.2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 5.5.0 (GCC)
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/doc/ffmpeg-3.4.2 --mandir=/usr/man --enable-gpl --enable-version3 --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libass --enable-libdc1394 --enable-libfribidi --enable-libgsm --enable-libmfx --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libssh --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libzvbi --enable-postproc --enable-runtime-cpudetect --enable-sdl2 --enable-vaapi --enable-vdpau --enable-pthreads --enable-bzlib --enable-zlib --enable-shared --enable-static --disable-debug --enable-opengl --enable-libpulse --enable-libfdk-aac --enable-openssl --enable-nonfree --arch=x86_64 --enable-pic --extra-cflags='-I/tmp/build/tmp-ffmpeg/ffmpegdeps/usr/include -I/tmp/build/tmp-ffmpeg/ffmpegdeps/usr/include/SDL2 -DRUNTIME_CPUDETECT' --extra-ldflags='-L/tmp/build/tmp-ffmpeg/ffmpegdeps/usr/lib64 -ldl -lssl -lcrypto -lz -lusb -ldrm' --pkg-config-flags=--static
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libavresample 3. 7. 0 / 3. 7. 0
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

As ffmpeg and VLC packages have included h.264 and h.265 codecs (compiled in), I did not installed stand alone h.264 and h.265 packages.

Please help me to achieve hardware accelerated video playback with ffmpeg and VLC.

bassmadrigal · 03-11-2018, 07:49 PM

You may need libvdpau-va-gl, which tranfers the va-api calls from Intel into vdpau calls that many programs need. I'm not sure if vlc has this same limitation, but I do believe mplayer does.

Once you have that installed, try running vdpauinfo and see what you are able to decode using vdpau. I have quite an old card, so it doesn't support any h265 acceleration (listed as HEVC).

Code:

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                    3  9216  2048  1152
MPEG2_MAIN                      3  9216  2048  1152
H264_BASELINE                  41  9216  2048  1152
H264_MAIN                      41  9216  2048  1152
H264_HIGH                      41  9216  2048  1152
VC1_SIMPLE                      1  9216  2048  1152
VC1_MAIN                        2  9216  2048  1152
VC1_ADVANCED                    4  9216  2048  1152
MPEG4_PART2_SP                  3  9216  2048  1152
MPEG4_PART2_ASP                 5  9216  2048  1152
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Also, for any code output, please use [code][/code] tags to make things a bit easier to read

linuxbawks · 03-13-2018, 06:43 PM

With Intel, one is fortunate as there are two native drivers available for use under X.

Please make sure you have installed: xf86-video-intel-git_20160601_b617f80-x86_64-1

Now you have two choices available. You can use this driver or use the modesetting driver which comes in the Kernel itself.

The /etc/X11/xorg.conf.d/10-intel-igp.conf file you will need is as follows:

Code:

Section "Device"
        Identifier      "IGP"
# Change the PCIe hardware address
        BusID           "PCI:00:0X:0"
#       Driver          "intel"
        Driver          "modesetting"
EndSection

bassmadrigal · 03-13-2018, 07:29 PM

Quote:

Originally Posted by linuxbawks

With Intel, one is fortunate as there are two native drivers available for use under X.

This is incorrect. The i915 kernel driver is used in the console to provide proper framebuffer support. Once you start up X, it then uses the "intel" Xorg driver. The KMS driver does not provide proper video acceleration for X. If you want to see what Xorg modules are available for the system, view /usr/lib{64}/xorg/modules/drivers. On my 64bit system, I have the following output:

Code:

jbhansen@craven-moorhead:~$ ls /usr/lib64/xorg/modules/drivers/
amdgpu_drv.la*  ati_drv.la*        cirrus_laguna.la*  i740_drv.la*    modesetting_drv.la*  openchrome_drv.la*  s3_drv.la*             sis_drv.la*     trident_drv.la*  vmware_drv.la*
amdgpu_drv.so*  ati_drv.so*        cirrus_laguna.so*  i740_drv.so*    modesetting_drv.so*  openchrome_drv.so*  s3_drv.so*             sis_drv.so*     trident_drv.so*  vmware_drv.so*
apm_drv.la*     chips_drv.la*      dummy_drv.la*      intel_drv.la*   neomagic_drv.la*     r128_drv.la*        s3virge_drv.la*        sisusb_drv.la*  tseng_drv.la*    voodoo_drv.la*
apm_drv.so*     chips_drv.so*      dummy_drv.so*      intel_drv.so*   neomagic_drv.so*     r128_drv.so*        s3virge_drv.so*        sisusb_drv.so*  tseng_drv.so*    voodoo_drv.so*
ark_drv.la*     cirrus_alpine.la*  glint_drv.la*      mach64_drv.la*  nouveau_drv.la*      radeon_drv.la*      savage_drv.la*         tdfx_drv.la*    v4l_drv.la*      xgi_drv.la*
ark_drv.so*     cirrus_alpine.so*  glint_drv.so*      mach64_drv.so*  nouveau_drv.so*      radeon_drv.so*      savage_drv.so*         tdfx_drv.so*    v4l_drv.so*      xgi_drv.so*
ast_drv.la*     cirrus_drv.la*     i128_drv.la*       mga_drv.la*     nv_drv.la*           rendition_drv.la*   siliconmotion_drv.la*  tga_drv.la*     vesa_drv.la*     xgixp_drv.la*
ast_drv.so*     cirrus_drv.so*     i128_drv.so*       mga_drv.so*     nv_drv.so*           rendition_drv.so*   siliconmotion_drv.so*  tga_drv.so*     vesa_drv.so*     xgixp_drv.so*

There are actually 2 intel drivers in there, however, the i740 is for an AGP-era GPU released in 1998, so only the "intel" driver is used for modern systems.

There is a big difference between a KMS driver and an Xorg driver. They are not interchangeable.

linuxbawks · 03-13-2018, 07:38 PM

PCIe integrated video is suported by the intel driver.

The fb is only part of the modesetting driver. It's not used exclusively.
By default X uses the intel driver. It's possible to preclude this using the conf file posted.
If you doubt this then uninstall the xf86 driver module and reload X using the modesetting driver.

bassmadrigal · 03-13-2018, 09:30 PM

Quote:

Originally Posted by linuxbawks

If you doubt this then uninstall the xf86 driver module and reload X using the modesetting driver.

Yeah, and let me know how well your 3D performance works or if you get hardware accelerated video decoding (I'll give you a hint... the first answer is "crappy" and the second answer is "no").

I implied this with the following line:

Quote:

The KMS driver does not provide proper video acceleration for X.

Considering OPs only problem is with hardware accelerated video decoding, it is likely an issue with the VA-API system, and most of the time that is due to missing the libvdpau-va-gl driver, because many software projects prioritized vdpau and not VA-API decoding. Suggesting OP use a driver that doesn't support hardware accelerated video decoding to solve OP's lack of hardware accelerated video decoding doesn't help the problem.

Please see ppr:kut's post below this one for corrected info.

ppr:kut · 03-14-2018, 06:04 AM

The 'intel' driver is largely considered crap and the general recommendation is to use the 'modesetting' driver instead. However, neither has any impact whatsoever on video acceleration or 3D support. The only benefit of the 'intel' driver over 'modesetting' is a special 2D acceleration that doesn't really work correctly and causes weird issues all over the place. Both still use the intel drm driver.

I switched about 1.5 years ago and have no issues ever since.

When I run alienBOB's vlc with '-v debug' (with an H.264 file) I see

Quote:

avcodec decoder: Using Intel i965 driver for Intel(R) Haswell Mobile - 2.1.0 for hardware decoding

zdolar · 03-14-2018, 07:44 AM

Hi guys!

Thank's for responses.

Meanwhile I found an interesting page regarding Intel graphics:
https://wiki.archlinux.org/index.php/intel_graphics
There you can find:
For the DDX driver (which provides 2D acceleration in Xorg), install the xf86-video-intel package.
Enable GuC / HuC firmware loading

For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.14) not enabled by default.

It is necessary to add i915.enable_guc_loading=1 i915.enable_guc_submission=1 to the kernel parameters to enable it.
I also installed:
libva-2.1.0-x86_64
libva-utils-2.1.0-x86_64
intel-vaapi-driver-2.1.0-x86
original from Slackware64-14-2 is xf86-video-intel-git_20160601_b617f80-x86_64
and for suggested vdpau:
libvdpau-1.1.1-x86_64
libvdpau-va-gl-0.4.2-x86_64
vdpauinfo-1.0-x86_64

/etc/X11/xorg.conf.d/20-intel.conf:

Code:

Section "Device"
  Identifier  "Intel Graphics"
  Driver      "intel"
  Option "TearFree" "true"
  Option  "AccelMethod"  "sna"

I attached:
intel.txt - here you find responses fro vainfo, vdpauinfo and glxinfo
Sum of above responses: vdpau is not appropriate, as almost all video codecs are not supported for Intel GPU.
libvaa in much better about codecs.

messages regarding HW acceleration this lines are important (to me)

Code:

Mar 14 06:15:47 video kernel: [    1.085022] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
Mar 14 06:15:47 video kernel: [    1.095283] [drm] GuC: Loaded firmware i915/kbl_guc_ver9_14.bin (version 9.39)
Mar 14 06:15:47 video kernel: [    1.112552] i915 0000:00:02.0: GuC submission enabled (firmware i915/kbl_guc_ver9_14.bin [version 9.39])
Mar 14 06:15:47 video kernel: [    1.113305] [drm] Initialized i915 1.6.0 20171023 for 0000:00:02.0 on minor 0

Xorg.0.log - for debuging appropriate X configuration

How to find out, if hardware acceleration of video is on duty when play/encode with ffplay/ffmpeg?
I'll use this machine for a video surveillance and ffmpeg is a must (with hardware acceleration).

Further suggestions are most wellcome.

linuxbawks · 03-14-2018, 10:03 AM

You might want to employ the modesetting driver is you're testing a new testing or want bleeding edge support for Intel hardware (video).

The Xorg "intel" is by no means considered crappy. If you want a stable driver then this is the one to use.

The modesetting driver as with all new kernel features tends to be, more often than not, less stable and prone to bugs. This was recently seen in the 4.9,6[2-4] LTS. I have to admit new kernel releases tend to be quite buggy.

Having said, in order to support new Intel hardware (Kaby Lake) your best bet would be trying the modesetting driver first at least if the Xorg driver is not providing the required support necessary. It's fairly easy to determine (subjectively) if HW acceleration is in use. Basically monitoring of the top utility while the hardware is in use will show you that with excessively high CPU usage in one of the programs, or the Xorg process.

bassmadrigal · 03-14-2018, 05:18 PM

Quote:

Originally Posted by ppr:kut

The 'intel' driver is largely considered crap and the general recommendation is to use the 'modesetting' driver instead. However, neither has any impact whatsoever on video acceleration or 3D support. The only benefit of the 'intel' driver over 'modesetting' is a special 2D acceleration that doesn't really work correctly and causes weird issues all over the place. Both still use the intel drm driver.

I switched about 1.5 years ago and have no issues ever since.

When I run alienBOB's vlc with '-v debug' (with an H.264 file) I see

I stand corrected. Thanks for the extra info. I wasn't finding any of that in my searches last night.

Darth Vader · 03-14-2018, 07:14 PM

Quote:

Originally Posted by zdolar

How to find out, if hardware acceleration of video is on duty when play/encode with ffplay/ffmpeg?
I'll use this machine for a video surveillance and ffmpeg is a must (with hardware acceleration).

You are dreaming much, young Padawan?

For your knowledge, you are NOT the first one who have "the visionary idea" to use a cheap box, with CPU on board, to encode 16 video streams to HEVC in real time, using the hardware encoding support. Well, I know some of them even in the real life. Around ten. And all of them failed miserably.

So, I tell you something disappointing: that hardware encoding support is single threaded, then you can encode just ONE stream at a time. IF it works.

Secondly, the hardware HEVC encoding support under Linux is highly, but really highly experimental. If you are kind to wait at least 'til A.D. 2028, that thing may will work, who know...

Long story short: in my humble opinion, you are dreaming with open eyes.

Be kind and do a favor yourself: go and buy a dedicated video-recorder for surveillance; they aren't too much, at around $100 you can buy one with 8 streams recording and web interface. Of course, with no hard drive included.

linuxbawks · 03-15-2018, 08:34 AM

Quote:

Originally Posted by bassmadrigal

I stand corrected. Thanks for the extra info. I wasn't finding any of that in my searches last night.

For the umpteenth time. Don't even know what a tarball is.

orbea · 03-15-2018, 10:38 AM

Quote:

Originally Posted by linuxbawks

For the umpteenth time. Don't even know what a tarball is.

Doesn't know what a Slackware package is.

bassmadrigal · 03-15-2018, 03:55 PM

Quote:

Originally Posted by linuxbawks

For the umpteenth time. Don't even know what a tarball is.

Please have some tact... I was mistaken in regards to the information I posted here and I admitted it (which I am more than willing to do when I am incorrect... it happens to the best of us -- Linux is an ever changing landscape and it can be hard to keep up). But please don't bring discussions from a closed topic in here. Let's keep everything on topic, shall we?

zdolar · 03-16-2018, 03:47 AM

Quote:

Originally Posted by Darth Vader

You are dreaming much, young Padawan?

The term "padawan" appears to originate in Sanskrit and can be understood as “learner"

For your knowledge, you are NOT the first one who have "the visionary idea" to use a cheap box, with CPU on board, to encode 16 video streams to HEVC in real time, using the hardware encoding support. Well, I know some of them even in the real life. Around ten. And all of them failed miserably.

So, I tell you something disappointing: that hardware encoding support is single threaded, then you can encode just ONE stream at a time. IF it works.

Secondly, the hardware HEVC encoding support under Linux is highly, but really highly experimental. If you are kind to wait at least 'til A.D. 2028, that thing may will work, who know...

Long story short: in my humble opinion, you are dreaming with open eyes.

Be kind and do a favor yourself: go and buy a dedicated video-recorder for surveillance; they aren't too much, at around $100 you can buy one with 8 streams recording and web interface. Of course, with no hard drive included.

I'm very sorry about your pathetic post, which is also completely OUT OF TOPIC and wrong also.
Will not discuss with someone so insulting, period!