Missing VA-API in Preferences - HW Accel

[signy13]

This is a new topic based on Avidemux2.7 - Latest dev Version thread

If I look to Preferences - HW Accel there are only VDPAU (NVIDIA) and LIBVA (Intel) options. Both of them produce broken output so I do not use them.

Why didn't you report this right away, at least the libva part? Could you please build Avidemux off the current git master yourself instead of using an appImage and check whether VA-API / libva hw accelerated decoder for H.264 works? If it doesn't work either, please redirect Avidemux stdout and stderr to a file and attach this file to your reply.

It might be better to start a new topic for that.

I thought that VA-API checkbox was removed on purpose. When I start compiling it shows:

Code Select Expand

**************************
***  Optional Library  ***
***      Summary      ***
**************************
*** Video Encoder      ***
    NVENC          No
*** Miscellaneous      ***
    gettext        Yes
    SDL            No
    XVideo        Yes
    VDPAU          Yes
    LIBVA          Yes
**************************
***  Release Build    ***
**************************
Freshly compiled Avidemux 2.7.8 behaves in the same way as the one from appImage - CPU usage and FPS suggest no VA-API.
I ran Avidemux in terminal and copied output to attachment.

[eumagga0x2a]

Thank you. The so-called "direct" way to transfer a decoded picture from a VA-API hardware surface to normal memory – the function vaDeriveImage – is not available on your hardware, so that Avidemux switches to "indirect" (actually, a way faster) path via vaGetImage.

Unfortunately, you have enabled multi-threading which automatically inhibits use of HW accelerated decoding. What happens when you enable libva hw decoding (and disable multi-threading)?

On Intel, I observe a strange problem that this "indirect" transfer method profoundly messes up decoding and results in a crash on closing video. Is it the same with AMD?

A side note: Unless you've purposely enabled post-processing, I would strongly recommend to disable it completely in Avidemux Preferences. If the video is not exactly an ancient blocky divx, post-processing actually reduces both quality and performance (it may increase compressibility, but at a cost).

[signy13]

Thank you for your info :-)

Unfortunately, you have enabled multi-threading which automatically inhibits use of HW accelerated decoding. What happens when you enable libva hw decoding (and disable multi-threading)?

On Intel, I observe a strange problem that this "indirect" transfer method profoundly messes up decoding and results in a crash on closing video. Is it the same with AMD?

Yes, the same: a messed video with the crash on closing Avidemux. I did test 09: lavc threads off, libva on, postprocesing disabled and result is in Test_output_09.txt. The test consumed about 50% CPU with 60-90FPS.

A side note: Unless you've purposely enabled post-processing, I would strongly recommend to disable it completely in Avidemux Preferences. If the video is not exactly an ancient blocky divx, post-processing actually reduces both quality and performance (it may increase compressibility, but at a cost).

Actually I do not know why the post-processing was enabled - I might have switched it on and forgotten it.
I have disabled it and the result was basically the same - exactly the same file size, the same picture quality. I did not find any difference between results.

[eumagga0x2a]

Yes, the same: a messed video with the crash on closing Avidemux.

As feared and expected. Thank you for the log, it looks we should consider a failure of vaDeriveImage a fatal error for libva hw accel for now.

Actually I do not know why the post-processing was enabled - I might have switched it on and forgotten it.

It was enabled by default in Avidemux versions prior to 2.7.6. If you inherited configuration from an older installation, Avidemux won't reset it to the new default on its own.

[signy13]

Yes, the same: a messed video with the crash on closing Avidemux.

As feared and expected. Thank you for the log, it looks we should consider a failure of vaDeriveImage a fatal error for libva hw accel for now.

Well I do not understand things related to HW acceleration, but in case you needed some more test from me, just let me know.
If HW acceleration works, I will be happy.

BTW: I find quite confusing that in the Preferences - HW accel tab are only possibilities for Nvidia and Intel. That was the reason why I thought that HW acceleration with AMD processors does not work on purpose.

Actually I do not know why the post-processing was enabled - I might have switched it on and forgotten it.

It was enabled by default in Avidemux versions prior to 2.7.6. If you inherited configuration from an older installation, Avidemux won't reset it to the new default on its own.

Thank you for your clarification and notice. I have been inheriting configuration for many years...

[eumagga0x2a]

If HW acceleration works, I will be happy.

Improving handling of VA-API in Avidemux is on my todo list as top priority. Hard stuff, however.

I find quite confusing that in the Preferences - HW accel tab are only possibilities for Nvidia and Intel. That was the reason why I thought that HW acceleration with AMD processors does not work on purpose.

Not on purpose but simply due to total lack of hardware to test. For many Linux users like me, AMD graphics cards were for over a decade the symbol of pain and manufacturer's neglect. You don't forget this experience that soon. I still don't own any hardware with AMD graphics, but this may change in the future.

[signy13]

Improving handling of VA-API in Avidemux is on my todo list as top priority. Hard stuff, however.

Thank you very much for your effort :-)

Not on purpose but simply due to total lack of hardware to test. For many Linux users like me, AMD graphics cards were for over a decade the symbol of pain and manufacturer's neglect. You don't forget this experience that soon. I still don't own any hardware with AMD graphics, but this may change in the future.

I see... I bought Ryzen 5 5400G a year after its launch and running Xubuntu 18.04 on it was painful experience - it took me months to find kernel and Mesa version, with which the system was able to last a couple days without a crash. At the beginning the graphics subsystem crashed me at least once in a day.