Use latest VAAPI for building ffmpeg on linux (x86, x86_64) #1296
Conversation
silenium-dev
changed the title
|
This doesn't work on CentOS 7 though so we can't merge this. |
|
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. |
Yes, if you're willing to give that a try, that's what we would need to do. |
|
I'm going to give it a try, could someone maybe take a look on why the build is failing? |
|
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 |
|
It's probably going to be easier to build from source from the original repository: https://github.com/intel/libva |
|
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. |
silenium-dev
changed the title
|
@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. |
|
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. |
|
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? |
|
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. |
|
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 |
|
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/ |
|
|
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.
|
|
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. |
|
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. |
|
Ok, I think I solved the issue that was preventing the pipeline from succeeding. 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. |
…o disabled by default (requires --enablerepo to use)
…set it to disabled by default (requires --enablerepo to use)" This reverts commit 0da74f3.
This allows the ffmpeg build to use the latest version of libva. Fixes #1289.