Build mesa with hardware codec support

After spending a bunch of time enabling hardware encoding support for h264 and h265, I wanted to share it with the folks who are interested. The linked repo contains instructions on building your own mesa, and should be simple to follow.

Disclaimer: It is your responsibility to make sure you are not downgrading your mesa version, if the version is out of date, you would have to find the relevant commit in the tree from the Manjaro repository and patch it accordingly.

EDIT: Disclaimer+: This repository is targeting stable releases only, and the contents may not have been updated for the latest release.

1 Like

Why not use the officially unofficial version: GitHub - mesa-freeworld/mesa-nonfree

This does not require switching to unstable.

For my taste it is better to pull the actual current stable PKGBUILD for mesa. You have to compile anyway, and with this version there wont be any conflicts.
And don’t forget to change your patch in the near future. With arrival of mesa 24 it will be

-D video-codecs=all .

This does pull that exact stable PKGBUILD, you can see the commit id in the 3rd line in the instructions.

Thank you for the heads-up! I will keep that in mind.

1 Like

As of writing this we have 3 different 23.3.x versions of mesa in our branches: Packages. Your repo only has a patch, which works for 23.3.x series. As already mentioned that line will change with 24.0.x series. The unofficial official solution is currently getting the PKGBUILD from the Arch repos and compiles it then against the unstable branch.

Normally if that is all done properly each version uploaded to our gitlab instance need a version tag so scripts can simply check those out and compile against the version found in the branches.

In the end it is all about legal reasons why the official repositories don’t ship with those codecs.

Added a clarification to the original post, since the repository only means to support the stable branch. I’ve run into the unofficial official solution initially, but opted to not go for it, as I experiment on a lot of things in my system, and would prefer to keep the underlying OS on the path most traveled.

Tags would be pretty useful to avoid digging through the commit history to find the PKGBUILD for the current stable release.

Avoiding shipping binaries with patent encumbered codecs is completely understandable, one of the reasons I posted this solution is to possibly reduce the friction around the topic for the more casual user base, who might just drop the distro after running into a few bugs in the unstable branch.