(re-)decide how to handle VAAPI codecs
Context
Mesa added build-time configuration flags earlier in the year which requires patent-encumbered codecs to be explicitly enabled https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15258/commits and, famously more recently Fedora announced they are not going to enable these drivers any more, based on their internal legal advice and policy on excluding such codecs.
There has therefore been a lot of interest in whether Freedesktop SDK would enable these - the reality is that presently the shipping versions of fd.o SDK already include these drivers from previous Mesa versions where they were enabled by default. The question already surfaced in mesa-git-extension#9 (closed) whether we will explicitly enable these going forwards.
Oddly, fd.o SDK has always been inconsistent here - in as much as we have gone to great lengths to split out the Intel VAAPI drivers, encumbered codecs in our ffmpeg extensions, pull in licensed implementations of OpenH264 when possible, etc - we have also always (since 1.6 days) shipped these *_video.so DRI drivers - whoops?!
(Note just for clarity: although GStreamer VAAPI is also split out into an extension, this is not for any legal reason; per #1152 (closed) it's because historically it hasn't always worked in every app / hardware combination due to driver reliability issues, so GStreamer upstream has been a bit hesitant about whether it should be enabled by default, so the decision has been left to the user - or an app developer can cause it to be auto-installed.)
Description
My concern here is that as the "foundational piece" of most Flatpak runtimes and apps, if we continue to knowingly include these patented VAAPI drivers in the SDK, then any OS vendor, commercial deployment, end user, etc who is concerned about these patent royalties becoming due is unable to rely on / ship most of the software from the existing Flatpak ecosystem, significantly reducing the chance of them using Flatpak at all.
I propose therefore that we should take the opportunity of Mesa splitting this out these build options to handle all VAAPI codecs in the same way as we handle ffmpeg - ie within the SDK we provide an unencumbered Mesa by default, and we provide an extension to upgrade/replace this Mesa with the patented codecs enabled. We can mark that for auto-installation (given the current status quo is that we ship most of this and VAAPI is also auto-installed) and OS images, hardware, etc that needs to avoid it can mask the extension.
mesa-git could probably also enable the them at that point because I am not sure there is audience for "I have very conservative codec licensing requirements" and "I'd like 0-day Mesa".
(I'm not sure how feasible it is, but perhaps we could also consider whether the Intel VAAPI drivers could be rolled into this full-codecs Mesa implementation, so we wouldn't need a separate Intel VAAPI extension point?)