[Fedora 37] Mesa w/ h264, h265, and vc1 decoding support

[DarkArc]

Please describe why this package is not eligible for Fedora ?

Mesa is eligible in Fedora, however recent changes in the ecosystem have prompted Fedora to remove accelerated support for h264, h265, and vc1.

Is this software redistributable ?

Yes

Is this software an alternate version of a Fedora provided package ?

Yes, see above.

Additional context

• https://www.reddit.com/r/linux/comments/xpyggi/fedora_37_drops_vaapi_accelerated_hardware_video/
• https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide

An exact copy of the Fedora RPM spec but with -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec included seems like the "ideal solution" here.

[Eonfge]

At the risk of starting a wave of spam on this topic; I wish to express my support for a mesa-full package.

But where do I come from? Well, for start I'm a Flahub contributor, where I help with CD-rippers and converters. I also maintain a select list of productivity software, and many of the classical Id Software titles.. Besides, I'm a contributor to Fedora Magazine. I've written such beautiful works as "Restarting and Offline Updates" and "Gaming on Fedora".

This last article I wrote about a year ago, when Fedora was really in a great position; Many pieces were falling together, there was enthusiasm in the market, and Linux was going through a wave of press coverage (Thanks Valve and LTTT). But the article also had an interesting problem: It was flying really close to the sun because everything written in it is in the presumption that the user enables RPM Fusion. I could never say so outright, and I chatted with the team behind-the-scenes to find the perfect balance.* Long story short; RPM Fusion is a core of the whole Fedora Desktop experience and as an author I've tried to promote it as much as possible.

That's also why I think it's very important to have an RPM-Fusion edition of the mesa driver stack. I would never ask somebody to do work that I myself would not be willing to do, and I hope that I don't come of as some random person voicing his frustrations. RPM Fusion is an integral part of the thing that makes Fedora worthwhile, and I hope that you have the time and resources to embrace a mesa-full package.

Honestly, if I had the time I would gladly contribute, but In the past three years i mostly focused on Flatpaks so I know little about packaging with RPM, Mock, and the whole Fedora stack. Therefore, allow me to ask first, before I embark on another 3-year journey learning all the ins and outs of a packaging format.

* It did also prompt the whole discussion about Flathub and that pit of legal snakes. In that case, everything worked out and Flathub is now cleared from any legal hurdles. How much one article can do.

[kwizart]

I can't read such "literacy", but to sum-up: anyone is free to contribute to RPM Fusion with a mesa-freeworld package. See also https://rpmfusion.org/Contributors I'm personally not interested in it, myself.

But even more relevant would be a solution that would ask mesa upstream to be able to provide vaapi-backends as a separate dlopenable shared objects instead of building a full mesa package IMO.

As I understand, only AMD users are concerned by this change as Intel users are using a separate userspace backend. Nouveau users aren't relevant as they lack proper firmware support.

[leigh123linux]

But even more relevant would be a solution that would ask mesa upstream to be able to provide vaapi-backends as a separate dlopenable shared objects instead of building a full mesa package IMO.

We can't provide the full mesa package anyway as it would conflict with fedora mesa. I don't think we need to provide the full package, maybe just replacement *_drv_video.so

$ rpm -ql mesa-dri-drivers-22.2.0-3.fc37.x86_64 |grep drv_video.so
/usr/lib64/dri/nouveau_drv_video.so
/usr/lib64/dri/r600_drv_video.so
/usr/lib64/dri/radeonsi_drv_video.so

[kwizart]

Also I don't think nouveau worth to be enabled, so only having radeonsi/r600 can make it (for x86_64 and eventually aarch64).

Edit: and i686 !

[DarkArc]

Does nouveau not have decode support for 9xx cards and h264 -- that sounds like the right vintage where that would still be relevant?

[kwizart]

Does nouveau not have decode support for 9xx cards and h264 -- that sounds like the right vintage where that would still be relevant?

Right, but then that support is more than buggy. (understand, the bugs could be in the outdated firmware).

[DarkArc]

Fair enough

[xinyazhang]

Some additional information: Intel video driver is already handled by rpmfusion. rpm -qf /usr/lib64/dri/i965_drv_video.so shows libva-intel-driver-2.4.1-8.fc36.x86_64, which is already in rpmfusion-free. However i965 video driver file is not shipped by the mesa-dri-drivers package as well.

The current way of avoiding overwriting video driver files from mesa-dri-drivers is to set LIBVA_DRIVERS_PATH environment variable to override the search path.

[robert-scheck]

I would like to repeat @kwizart's point on the IRC regarding https://github.com/rpmfusion/ffmpeg/pull/3 for a complement solution. It seems to be a split out of the relevant freeworld libraries into a separate (new) sub-package which ensures via library loading to be preferred over the Fedora package (if I get it correct).

[vwbusguy]

As I understand, only AMD users are concerned by this change as Intel users are using a separate userspace backend. Nouveau users aren't relevant as they lack proper firmware support.

Wouldn't this also affect Raspberry Pi 4/00's? The effect there might be more significant given the less powerful CPU to fall back on. I imagine Fedora Mobility initiative might be similarly impacted as well.

[BaconCatBug]

I just want to leave a comment hoping that, however it's implemented, a one click Fedy solution is found and would be very much appreciated.

[xsrvmy]

How would this interact with secure boot?

[Cacodemon345]

Secure Boot shouldn't affect this since these aren't kernel modules, but user-space drivers.

[xsrvmy]

Ah I was wondering if this would cause the whole mess with nvidia

[orowith2os]

As I understand, only AMD users are concerned by this change as Intel users are using a separate userspace backend. Nouveau users aren't relevant as they lack proper firmware support.

Wouldn't this also affect Raspberry Pi 4/00's? The effect there might be more significant given the less powerful CPU to fall back on. I imagine Fedora Mobility initiative might be similarly impacted as well.

IIRC the v3d drivers don't yet support video decoding, so it would be an issue anyways. I also think they were using the proprietary Broadcom drivers previously, before v3d came into the picture? Could be wrong on that last part.

[lordofpipes]

This comment is just for googleability, not strictly related to fedy but to help anyone who sees this

Here is a solution that works on Fedora 37.

First, set up RPM Fusion repos:

sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
# nonfree repository is not needed, you can skip this command
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Then install mesa-va-drivers-freeworld and mesa-vdpau-drivers-freeworld

sudo dnf install mesa-va-drivers-freeworld mesa-vdpau-drivers-freeworld

Alternatively, if mesa-va-drivers or mesa-vdpau-drivers are already installed, use swap instead:

sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld

Optional: Installing additional non-hardware codecs

sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video
sudo dnf install @multimedia @sound-and-video ffmpeg-libs gstreamer1-plugins-{bad-\*,good-\*,base} gstreamer1-plugin-openh264 gstreamer1-libav lame\*
flatpak install flathub org.freedesktop.Platform.ffmpeg-full

[paveloom]

Here's a little FYI for Fedora Silverblue 37 users.

This is what I did to make the totem-video-thumbnailer work for my videos on AMD hardware:

1) Set up RPM Fusion repos:

sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

2) Swap the mesa-va-drivers with mesa-va-drivers-freeworld:

rpm-ostree override remove mesa-va-drivers --install mesa-va-drivers-freeworld

3) Install additional packages:

rpm-ostree install gstreamer1-plugin-libav gstreamer1-plugins-bad-free-extras gstreamer1-plugins-bad-freeworld gstreamer1-plugins-ugly gstreamer1-vaapi

[kwizart]

I've created a dedicated page for OSTree at https://rpmfusion.org/Howto/OSTree Also updated

As fedy is concerned, we should still be able to add a swap module for mesa...

[JustPlainGarak]

This comment is just for googleability, not strictly related to fedy but to help anyone who sees this

Here is a solution that works on Fedora 37.

First, set up RPM Fusion repos:

sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
# nonfree repository is not needed, you can skip this command
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Then install mesa-va-drivers-freeworld and mesa-vdpau-drivers-freeworld

sudo dnf install mesa-va-drivers-freeworld mesa-vdpau-drivers-freeworld

Alternatively, if mesa-va-drivers or mesa-vdpau-drivers are already installed, use swap instead:

sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld

Optional: Installing additional non-hardware codecs

sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video
sudo dnf install @multimedia @sound-and-video ffmpeg-libs gstreamer1-plugins-{bad-\*,good-\*,base} gstreamer1-plugin-openh264 gstreamer1-libav lame\*
flatpak install flathub org.freedesktop.Platform.ffmpeg-full

Just to add to this, folks may want to also exclude mesa-va-drivers explicitly in their /etc/dnf/dnf.conf file as well. I just had my mesa driver update error out until I did so because it couldn't install this package due to the conflict with the freeworld packages. You can also manually exclude the package in an update command by appending --exclude=mesa-va-drivers to the dnf update command.

[DarkArc]

Just to add to this, folks may want to also exclude mesa-va-drivers explicitly in their /etc/dnf/dnf.conf file as well. I just had my mesa driver update error out until I did so because it couldn't install this package due to the conflict with the freeworld packages. You can also manually exclude the package in an update command by appending --exclude=mesa-va-drivers to the dnf update command.

That shouldn't be necessary at all (and could cause you headaches down the road -- it's a big red flag you've done something wrong as well). If you use the swap command as the other commenter (that you're quoting) stated, the meas-va-drivers package should be uninstalled and replaced by the freeworld package.

[GregDuhamel]

Hey, I did the swap but the latest mesa update keep asking me to upgrade mesa-va-drivers package, did I miss something ?

---

De : Wyatt Childers @.> Envoyé : Tuesday, January 3, 2023 4:19:14 PM À : rpmfusion-infra/fedy @.> Cc : Gregory Duhamel @.>; Manual @.> Objet : Re: [rpmfusion-infra/fedy] [Fedora 37] Mesa w/ h264, h265, and vc1 decoding support (Issue #110)

Just to add to this, folks may want to also exclude mesa-va-drivers explicitly in their /etc/dnf/dnf.conf file as well. I just had my mesa driver update error out until I did so because it couldn't install this package due to the conflict with the freeworld packages. You can also manually exclude the package in an update command by appending --exclude=mesa-va-drivers to the dnf update command.

That shouldn't be necessary at all (and could cause you headaches down the road). If you use the swap command as the other commenter (that you're quoting) stated, the meas-va-drivers package should be uninstalled and replaced by the freeworld package.

— Reply to this email directly, view it on GitHubhttps://github.com/rpmfusion-infra/fedy/issues/110#issuecomment-1369890022, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABBHXXFWLEBMLQEHO4UXTCDWQQ7PFANCNFSM6AAAAAAQXKGPTI. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[DarkArc]

Hey, I did the swap but the latest mesa update keep asking me to upgrade mesa-va-drivers package, did I miss something ?

@GregDuhamel @JustPlainGarak the latest sudo dnf update --refresh -y goes through without fanfare for me (as it should for you). If you're having this problem, dnf should tell you what package is trying to require mesa-va-drivers, which is important information. It's possible you have something -- somewhat obscure -- that's explicitly requiring mesa-va-drivers.

[thestonewell]

what happens is that on the update repository we now have:

Available Packages
mesa-va-drivers.i686                                                        22.3.2-1.fc37                                            updates                
mesa-va-drivers.x86_64                                                      22.3.2-1.fc37                                            updates                

whereas on @rpmfusion-free-updates is still at:

mesa-va-drivers-freeworld.i686                                              22.3.1-1.fc37                                            @rpmfusion-free-updates
mesa-va-drivers-freeworld.x86_64                                            22.3.1-1.fc37                                            @rpmfusion-free-updates

thus, doing an dnf upgrade pulls in mesa-va-drivers as weak dependencies:

============================================================================================================================================================
 Paket                                        Architektur                     Version                                Paketquelle                      Größe
============================================================================================================================================================
Updates:
 mesa-dri-drivers                             i686                            22.3.2-1.fc37                          updates                           18 M
 mesa-dri-drivers                             x86_64                          22.3.2-1.fc37                          updates                           17 M
 mesa-filesystem                              i686                            22.3.2-1.fc37                          updates                           18 k
 mesa-filesystem                              x86_64                          22.3.2-1.fc37                          updates                           18 k
 mesa-libEGL                                  i686                            22.3.2-1.fc37                          updates                          142 k
 mesa-libEGL                                  x86_64                          22.3.2-1.fc37                          updates                          131 k
 mesa-libEGL-devel                            x86_64                          22.3.2-1.fc37                          updates                           21 k
 mesa-libGL                                   i686                            22.3.2-1.fc37                          updates                          187 k
 mesa-libGL                                   x86_64                          22.3.2-1.fc37                          updates                          176 k
 mesa-libGL-devel                             x86_64                          22.3.2-1.fc37                          updates                           35 k
 mesa-libOSMesa                               i686                            22.3.2-1.fc37                          updates                          3.4 M
 mesa-libOSMesa                               x86_64                          22.3.2-1.fc37                          updates                          3.2 M
 mesa-libgbm                                  i686                            22.3.2-1.fc37                          updates                           47 k
 mesa-libgbm                                  x86_64                          22.3.2-1.fc37                          updates                           45 k
 mesa-libglapi                                i686                            22.3.2-1.fc37                          updates                           55 k
 mesa-libglapi                                x86_64                          22.3.2-1.fc37                          updates                           57 k
 mesa-vulkan-drivers                          i686                            22.3.2-1.fc37                          updates                          8.1 M
 mesa-vulkan-drivers                          x86_64                          22.3.2-1.fc37                          updates                          7.5 M
weak dependencies will be installed:
 mesa-va-drivers                              i686                            22.3.2-1.fc37                          updates                          3.6 M
 mesa-va-drivers                              x86_64                          22.3.2-1.fc37                          updates                          3.4 M

The right answer is to wait for mesa-va-drivers-freeworld to be of version 22.3.2-1.fc37 as well. Same for mesa-vdpau-drivers-freeworld

[GregDuhamel]

Oh nevermind, when i attempt it the first time the two packages (freeworld) from RPM Fusion where not there and so one of the package tried to pull mesa-va-drivers.

It's ok now, thanks for your answer !

On mar., janv. 3 2023 at 08:09:30 -0800, Wyatt Childers @.***> wrote:

Hey, I did the swap but the latest mesa update keep asking me to upgrade mesa-va-drivers package, did I miss something ?

@GregDuhamel https://github.com/GregDuhamel @JustPlainGarak https://github.com/JustPlainGarak the latest sudo dnf update --refresh -y goes through without fanfare for me (as it should for you). If you're having this problem, dnf should tell you what package is trying to require mesa-va-drivers, which is important information. It's possible you have something -- somewhat obscure -- that's explicitly requiring mesa-va-drivers.

— Reply to this email directly, view it on GitHub https://github.com/rpmfusion-infra/fedy/issues/110#issuecomment-1369949566, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBHXXHEYR3OIANCEYC7ZVDWQRFLVANCNFSM6AAAAAAQXKGPTI. You are receiving this because you were mentioned.Message ID: @.***>

[romulasry]

Error: Transaction test error: file /usr/lib64/dri/nouveau_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64 file /usr/lib64/dri/r600_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64 file /usr/lib64/dri/radeonsi_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64 file /usr/lib64/dri/virtio_gpu_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64

[romulasry]

Fixed by removing mesa-va-drivers then installing mesa-va-drivers-freeworld and mesa-va-drivers-freeworld.i686.

[romulasry]

I guess it needs mesa-freeworld. I will wait until it get to stable.

[romulasry]

vainfo Trying display: wayland libva info: VA-API version 1.17.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit