Slackware64-14.2 i5-7200U hardware video acceleration problem
 

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.

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

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

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:

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:

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.

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.

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.

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

Intel GPUspecifics
 

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

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.

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

You are dreaming much, young Padawan? :D

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.

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

Doesn't know what a Slackware package 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?

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!

I think that pathetic is the tentative to encode HEVC with a freaking 15W on-board CPU... ;)

BTW, my post was literally on topic, discussing:

A. The lame state of hardware encoding to HEVC under Linux. Oh, and I do not touched the PATENTS issues. ;)
B. Giving you a realistic suggestion: to buy a surveillance video-recorder, it is cheaper than your computer.

I've tested both above suggestions.
1. xf86-video-intel-git_20160601_b617f80-x86_64-1 - HW acceleration do not work for any video type.
2. modesetting driver which comes in the Kernel itself - tested with kernel 4.15.9, 4.14.17, 4.14.26
The same result with all kernel drivers, X cripled GUI, hardly recognisable icons to skip out from X to text console.

Looks like first variant is the only option.
The machine is playground/testing for Linux video capabilities, in real I will need hardware accelerated ffmpeg for x264 video.

As Linux boxes can decode/encode video with intel GPU help I want to achieve that in Slackware as it's far most stable distro and I play with it for more than two decades.
As Intel develops opensource Linux drivers for its integrated graphic, I believe in success.
Here I add a part of Xorg.log regarding Intel GPU.

Looks like mode Setting driver is active regardles of
placed in /etc/X11/xorg.conf.d/ *.conf file

Looks all good to me, no errors or warnings, hardware acceleration enabled..

Can someone confirm, that the above Xorg.log truly show, that HW acceleration is enabled. If yes, then I have to look for settings in compile/use of ffmpeg and VNC.

I'm aware that encoding HEVC is to much for i5-7200U, was just testing. Read my previous post - I need only x264 decode with ffmpeg that's all.

Regarding custom build surveillance video-recorder - I bought one with camera and I was completely disappointed. Is I have knowledge about computers HW and SW (> 30 years) I Installed Slackware & Zoneminder on an old notebook for test. That's excellent couple and work over a year without interruption.
Afraid of a HW failure and higher demands, I bought an Intel NUC clone without fans to create a production machine. New upcoming version of ZM will better support x264, so I test that right now.. That's for my hobby. (But I could buy an expensive custom made system)

Like I mentioned before, the DDX driver you use has no impact on the hardware video decoding, only the used drm driver does. So whether you use 'intel' or 'modesetting' only impacts your 2d rendering, nothing else.

To check whether video decoding works with VA-API run "va-info". For me this returns:

And then you just need a player that supports VA-API, and potentially find the setting that enables it for that player if it's not enabled by default.

Thank you ppr:kut!

You can see my vainfo output in my very first post.
Looks like my expectations were right. The confguration of the sistem is right, I just have to configure ffmpeg to use HW acceleration.
Is there any special option at configure (pre compile, and at runtime) for Intel HD graphics?
Compile config of ffmpeg from Slackware contributor Eric Hameleers is:
Is there any runtime config of ffmpeg/ffplay, to enable libva and internal Intel HD graphics acceleration?

Normally ffmpeg picks up libvdpau and libva automatically if they are installed on the system, but you can also see in the configure parameters that those are there (--enable-vdpau --enable-vaapi).
From there on it depends on what you want to do.

https://trac.ffmpeg.org/wiki/Hardware/VAAPI should help you figuring out the correct arguments for ffmpeg itself. However, ffmpeg is no media play and ffplay is not a very sophisticated one. Depending on what you want to achieve you might be better off looking at how to configure vaapi for vlc or xine.

Or maybe our BDFL will have mercy for those poor souls who have 15W CPUs and bless them to use MPlayer with VA-API, via https://github.com/i-rinat/libvdpau-va-gl

Excuse me, but the lack of libvdpau-va-gl from Slackware is really ridiculous, in the context where the distro officially ships MPlayer, also VDPAU and VA-API support.

The OP's computer is poster child of that missing/messing feature. NOT everyone have a modern computer driven by a ThreadRipper or a Ryzen with 8 cores and 16 threads, you know... :p

Thank you all, especially ppr:kut !

Realized that the problem is almost sure in ffmpeg, as vainfo and Xorg.log show HW accelerated system.

Darth Vader for your record: Currently I use "Intel(R) Core(TM) i5-3210M CPU" machine for two cameras and take a look at attached picture. It easy cope with demands, max load less than 33%! :) :) So no problem with 25% faster i5-7200U. So don't be insulting and cool please.

Will post here after success with ffmpeg.

advances in a field
 

Hi!

CPU: Intel i5-7200U
OS: Slackware64-14.2
Test video: Tears_400_x265.mp4
Stream #0:0(und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv), 1920x800, 402 kb/s, 24 fps, 24 tbr, 24k tbn, 24 tbc (default)


I found two excellent pages regarding new Intel processors optimizations/settings for video acceleration with internal GPU:
https://gist.github.com/Brainiarc7/a...ad6cdd835efe57
https://gist.github.com/Brainiarc7/9...b2931bed379219

Following the above, I set up all correctly and verified, that HW accleration on my system is working - GuC: Loaded firmware at booting and vainfo output.


ffmpeg - compiled on my system and optimized for libva. Version 3.4.2
BUT, the interesting part are codecs.
From the above it is clear, that ffmpeg can take advantage of vaapi ONLY for encoding, but not for decoding/play.
Test ffplay with Tears_400_x265.mp4 working without HW acceleration, CPU load around 30%.
Is there anybody, that can explain that? Are there any special config options at compile, to enable vaapi capable decoders and not only encoders?

VLC-3.0.1 - compiled on my system and optimized for libva.
VLC is practicaly GUI for ffmpeg. I compiled VLC to include the same version of ffmpeg as above.
BUT I way highly surprised: VLC uses libva and HW acceleration! CPU use less than 5%.
But VLC HW assisted video play output is crippled, colors are distorted.
Take look at a screenshot attachment.
Maybe last line of log above mean something?

So two unresolved questions:

1. Why ffmpeg on its own can't play HW accelerated video, VLC which uses the same ffmpeg as background can?
2. VLC video distortion.

Any ideas? :)

intel driver is being used.
You do have HW acceleration. It works out of the box withtout any special configs.

That's fine, vaapi doesn't have specific decoders you need to select. Instead it works with the -hwaccel parameter (as the wiki page I linked before explains).
The reason you didn't see that in action with ffplay is that even though ffmpeg supports hardware acceleration, ffplay does not.

OK, that explain, why ffplay is slow. But now I'm confused: VLC in its base is ffmpeg GUI. How come it is fast with video play?
Is there any info regarding including HW acceleration in ffplay?

If I'm understanding your question properly, it is because vlc doesn't use ffplay to play videos. VLC provides its own GUI and it uses the libraries provided by ffmpeg (libavcodec, libavformat, etc) to support that hardware acceleration.

VLC uses the QT toolkit.
VLC uses the libavcodec codec but uses its own muxers.

I have only ever used ffmpeg for media encoding. For content consumption MPlayer works best and it has no setup overheads. It's all essentially plug and play.

I prefer using mplayer as well, but VLC is a very popular video player on all platforms (and mpv is a popular alternative to mplayer). Whether one is better than another is based on opinion...

And if you get Eric's restricted VLC, it supports just about everything, which Slackware's mplayer (and ffmpeg if you're running -current) is limited due to patent restrictions in some countries preventing distribution. You'd need to rebuild ffmpeg and mplayer to be able to fully support everything that Eric's VLC provides.

It is MPlayer.

And there would be many people who would disagree with you. As I said, that is your opinion... unless you can somehow prove that mplayer is better than all the other video players out there (good luck).

Shut up.

I didn't have the time to read the whole thread but still what I'm going to say might be of use to the OP:

I'm running Slackware 14.2 on a 2-in-1 laptop with a Celeron N3050 processor. I'm using the i915 kms driver (and Xorg automatically loads the intel driver).

When I compile stuff like mpv or MPlayer they automatically pick up whatever hw support there is, in this case, libva.

The thing is, with the stock Slackware packages, HW acceleration was good enough except when playing 10bit HEVC video (with large frame dimensions). Being upset about this, I started upgrading the stock libva and libva-intel-driver packages to the newer upstream versions as they came out. In the meantime the latter changed its name to intel-vaapi-driver. Especially with the 1.8.x branch things changed drastically and I can play all my videos smoothly now. The current vaapi driver is at the 2.x branch to which I didn't upgrade because I'd have to recompile too many things. But you can use the 1.8.3 version as a drop-in replacement for the stock 1.7.1 package.

Of course, the patches and performance numbers for my chipset may not be too relevant to yours, but if you want to squeeze every bit of performance you get out of the hardware, it might be worth considering upgrading to 1.8.3.

@linuxbawks, this kind of behavior isn't acceptable at LQ. If you'd like to continue participating here, please refrain from it moving forward.

--jeremy

Thank you Ilgar!

Best answer so far. :):):):hattip:

As I wrote, I will use Slackware box exclusively for a video surveillance:
miniPC with i5-7200U, plenty of RAM and large disk for video recording. Its without fans, hidden and also without any iterfaces (monitor, keyboard, mouse), just like mini server.
The video surveillance program (Zoneminder) depends only on ffmpeg. So this is my main focus. As the replies here show, I've done all right and finish that point.
Other video apps are only for my curiosity as a long Slackware user - hobby.


Here I spent most of the time "catching the rabbit".
Finally I discovered:
1. Later Intel CPUs need a "speed up" firmware to be loaded at boot time (previous posts - DMC, GUC, HUC), provided by Intel and not described anywhere in Slackware documentation.
2. Kaby Lake CPU (mine) - libva-1.XX and intel vaapi driver return error on loading. So I tried latest, 2.1 version and worked.
3. as a result of previous point, all video applications compiled for a Slackware64-14.2 I'm using, failed to load. So I was forced to recompile ffmpeg-GIT and VLC-3.0.1 to pick up 2.1 libraries & Intel driver at compilation.

ffmpeg works 100% as verified by this comunity.
VLC (I don't need really) do not. It's fast but video is distorted - screenshot attached in one of my previous post.

I'm interested on mpv. Did you compiled 0.2.8.X? Older versions are not h.265 compatible, but this one require patched ffmpeg (dirty request, i do not like).



Regarding MPlayer:
At their site they state:
Over TWO YEARS OLD - Have not tested obsolete application. Hardware acceleration on modern CPUs for h.264, HEVC, UHD support...
This old one simply can not be the best video application.
But sorry, I might have not found (if any) new page of MPlayer.

And last:
linuxbawks :tisk: :thumbsdown:- sorry, but your account should be disabled by LQ administrator.

That website links to daily snapshots as well as 'old' stable release, it's not mplayer fault you only read the header...

It's more like a multimedia engine, if you want 'video application' there's plenty to choose from...

Grab the snapshot sources from slackware-current repository, I have tested these, compiles with ffmpeg 3.4.2, works fine.

I have ffmpeg 3.4.2, MPlayer-20180208 and mpv-0.27.2 compiled against it. I didn't bother to attempt mpv 0.28.x because I'm satisfied with the current performance. I'm also keeping the libva upgrade on hold, as I have linphone and some other stuff that break with version 2.x. I chose to leave the big overhaul to when Slackware 15 is released.

By the way, I was a little inaccurate when I said mpv and mplayer pick up libva. mpv supports vaapi but MPlayer doesn't, actually that was the reason which forced me to switch to mpv.

To be fair, it was your choice of hardware that forced you into vaapi, because there is hardware that supports only vdpau and not vaapi.
Correct me if I'm wrong, but I've read that vaapi is an effort to bring vdpau support to non-nvidia hardware.

I am certainly not an expert, but what I understand is, it is an effort along the lines you said. I take it as the Intel version of Nvidia's vdpau. It does emulate vdpau but it probably has some intel-specific optimizations, too.

So yes, my vaapi recommendation was meant to be only for those using on-board Intel HD graphics (these days with a dedicated video card, even with the weakest one, one need not worry about video decoding performance). My system is kind of on the low edge, that's why every bit of improvement makes visible difference.

Sorry, was too fast. Noticed snapshots later.
Mpayer works, but bad on my hardware. Tested HEVC UHD video on powerfull i7-6820HQ(4 core, 8 treads) and Windows 10 x64:
Mplayer response: "Your system is too SLOW to play this!" :cry:
VLC - excellent play :cool:
ffplay - play accelerated (high GPU load with max GPU frequency) but high CPU load

As of above, VLC & ffmpeg are both "multihardware", Mplayer ignores Intel. So a lot of users with Intel integrated graphics are deprived.
So instead of investing a money to nVidia, a logical decision is ...

Yes I am aware of that.
As I noted many times in my previous posts, I bought a miniPC (no place to insert additional video card) with modern CPU, capable of HW acceleration (Intel Kaby Lake, vaapi).
Have to point out again, as some do not read or want to understand:
1. I just want to squeeze a maximum from the hardware I have!
2. I need ONLY HW accelerated ffmpeg with my hardware
So please be so kind, to not suggest me other hardware (video cards as nVidia or else) Thank you very much.

As I've got confirmations for 2. above, let me say thank you all for a help.

Not quite. VAAPI is an effort to a hardware acceleration API for video en-/decoding. It's actually closer to nvidia's video codec SDK (NVENC/NVDEC) than it is to VDPAU, since VDPAU is decoding only. Both VAAPI and VDPAU were efforts for a vendor independent API, just with different scope.

Thanks, this explains a lot. I had no need to encode, but decoding is a must (and all I got is geforce hw) so I guess I never had to run anything other than mplayer.

Since mplayer only supports vdpau, you can use the libvdpau-va-gl program I linked to before to allow mplayer to use your card. This program basically sets up a vdpau driver that translates vdpau calls into vaapi calls, which allows your Intel video card to provide proper acceleration. It isn't as good as native vdpau support, but it is much better than no hardware video accerlation (and it should be plenty good for what you're looking for).

But if you want native vaapi support, mpv is a better option for that (mpv is a fork of mplayer, but the developer is a little headstrong and has pissed some people off).

libvdpau-va-gl only supports H.264, nothing else. Won't help with HEVC.

Crap, I didn't realize that. Thanks for the info.

I already tried that. vaapi is better in my case.

Off topic: bassmadrigal would you please reply to my question here:
How to configure fstab and lilo.conf with persistent naming
Thank you.

Done. Hopefully that answer makes sense.

The wiki doesn't notify people of replies, so I'm glad you said something otherwise it probably would've been a while until I saw it.

Our BDFL is aware probably, as I said multiple times, that the Slackware lacks the VAAPI-VDPAU little bridge: https://github.com/i-rinat/libvdpau-va-gl

I asked multiple times for this package, not for my benefits but being aware that many needs it. And until now I was ignored. Feel free to bark too for it... ;)