Use latest VAAPI for building ffmpeg on linux (x86, x86_64)

[silenium-dev]

This allows the ffmpeg build to use the latest version of libva. Fixes #1289.

[saudet]

This doesn't work on CentOS 7 though so we can't merge this.

[silenium-dev]

Why is it required to build on CentOS 7? It just results in having to build every dependency from source instead of just installing the packages to have the latest version.

EDIT: I've read the wiki, it's because of the old glibc version.

[saudet]

Why is it required to build on CentOS 7? It just results in having to build every dependency from source instead of just installing the packages to have the latest version.

Yes, if you're willing to give that a try, that's what we would need to do.

[silenium-dev]

I'm going to give it a try, could someone maybe take a look on why the build is failing?
EDIT: Fixed it

[silenium-dev]

I'm now building the libva package from source by taking the old source rpm, replacing the source archive and version and then building it with mock for either i686 or x86_64.

[saudet]

It's probably going to be easier to build from source from the original repository: https://github.com/intel/libva

[silenium-dev]

It is built from this original source, I'm downloading the latest release source tarball, but it happens in the context of rpmbuild, which makes it much easier to build for 32-bit on a 64-bit system.

[streamingdv]

@silenium-dev just curious what's the actual status of this pull request? I encountered some problems in regards of the VAAPI hw decoder on my Linux test machine and I think this is related to the same issue.

[silenium-dev]

@silenium-dev just curious what's the actual status of this pull request? I encountered some problems in regards of the VAAPI hw decoder on my Linux test machine and I think this is related to the same issue.

The actions run successful in my repository (fails on maven publish because of missing sonatype repo credentials, but this isn't important), but the checks are failing, because the fetch of the action is broken (https://github.com/silenium-dev/javacpp-presets/actions/runs/4872749240/jobs/8691383577#step:4:5852). I don't know how to fix this, maybe you have an idea?

Regarding the problems on your machine, it is probably this issue, because every distro, including the latest stable release of Debian, ships a newer library version than what is currently linked against.

[silenium-dev]

Another thing I'm uncertain about is backwards compatibility, how do I ensure that the Java library works on every machine with a libva version older than the latest release (e.g. Debian, Ubuntu, ... almost every stable non-rolling-release distro)?

EDIT: It seems that an older version of ffmpeg that is linked against an older version of libva works with the most recent version of libva as long as both were the same major version.
I've tested this on my Arch Linux workstation, but will probably test it on Debian later.

[streamingdv]

Also no idea unfortunately, pretty new to that awesome repo here to be honest. But maybe @saudet has some inputs about how you can fix that?

[silenium-dev]

I think I got it, it had initialized an empty repo and then fetched the remote, now I'm pulling the repo directly and then doing a checkout on the given sha.

[silenium-dev]

All Linux builds successful, the Windows and macOS builds take even more time for some reason, but shouldn't be impacted, as I've only changed the Ubuntu and CentOS based builds

[saudet]

This looks like a lot of hacking that I don't think we need... Instead of trying to figure this out though, it looks like there are already RPMs available for that here: https://negativo17.org/repos/multimedia/epel-7/x86_64/
Did you try to just use those?

[silenium-dev]

This looks like a lot of hacking that I don't think we need... Instead of trying to figure this out though, it looks like there are already RPMs available for that here: https://negativo17.org/repos/multimedia/epel-7/x86_64/ Did you try to just use those?

I didn't, but it seems that there are only 64 bit builds, but we need 32 bit ones, too.
My bad, I haven't seen them

[saudet]

32-bit builds seem available to me. Did you give it a try and found that they don't work? Just saying that they're not available without actually looking at the files isn't helpful information.

[ ] libva-2.18.0-1.el7.i686.rpm 2023-04-13 20:54 94K
[ ] libva-2.18.0-1.el7.x86_64.rpm 2023-04-13 20:54 95K
[ ] libva-devel-2.18.0-1.el7.i686.rpm 2023-04-13 20:54 683K
[ ] libva-devel-2.18.0-1.el7.x86_64.rpm 2023-04-13 20:54 683K
[ ] libva-utils-2.18.2-1.el7.x86_64.rpm 2023-04-20 12:18 537K

[saudet]

In any case, we won't be able to merge this until all the builds pass, and they are currently all failing. Either get this working the simple way, or please figure out how to make all your hacks actually work.

[silenium-dev]

The problem isn't the libva build, this part is working correctly, but the pipeline doesn't work on pull requests, for some reason it tries to fetch the code again in the pipeline instead of using the already checked out one by GitHub actions. This behavior only exists in the linux pipelines, so I wonder why it hasn't been solved the same way as in the macOS and Windows ones.
For reference, it is working in my repo: https://github.com/silenium-dev/javacpp-presets/actions/runs/4879495831
It's just broken on pull requests.

[silenium-dev]

Ok, I think I solved the issue that was preventing the pipeline from succeeding.
The workflow always used the actions from this repository, so there didn't have to be actions/checkout before. Now, if I want to modify the pipeline and change the action path to be in the repository the pipeline runs in and not a hard-coded path, it requires a actions/checkout before.
This resulted in the workspace directory not being empty and git fetch + git checkout reporting an error. I've replaced the checkout with reset --hard and now it works.
I'm curious if this fixed the issue with the failing pull request checks as well, or if this is another issue.

P.S: I've tried the epel-multimedia repo as suggested, it seems to work, but the pipeline is still running, so we'll see.