Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DarkArc opened this issue Sep 28, 2022 · 28 comments
Closed

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

DarkArc opened this issue Sep 28, 2022 · 28 comments

Comments

@DarkArc
Copy link

DarkArc commented Sep 28, 2022

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

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

@DarkArc DarkArc changed the title Mesa w/ h264, h265, and vc1 decoding support [Fedora 37] Mesa w/ h264, h265, and vc1 decoding support Sep 28, 2022
@Eonfge
Copy link

Eonfge commented Sep 28, 2022

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
Copy link
Member

kwizart commented Sep 28, 2022

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
Copy link
Member

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
Copy link
Member

kwizart commented Sep 28, 2022

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
Copy link
Author

DarkArc commented Sep 28, 2022

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

@kwizart
Copy link
Member

kwizart commented Sep 28, 2022

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
Copy link
Author

DarkArc commented Sep 28, 2022

Fair enough

@xinyazhang
Copy link

xinyazhang commented Sep 28, 2022

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
Copy link

I would like to repeat @kwizart's point on the IRC regarding rpmfusion/ffmpeg#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
Copy link

vwbusguy commented Sep 29, 2022

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
Copy link

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
Copy link

xsrvmy commented Sep 30, 2022

How would this interact with secure boot?

@Cacodemon345
Copy link

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

@xsrvmy
Copy link

xsrvmy commented Oct 1, 2022

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

@orowith2os
Copy link

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
Copy link

lordofpipes commented Nov 11, 2022

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
Copy link

paveloom commented Nov 16, 2022

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
  1. Swap the mesa-va-drivers with mesa-va-drivers-freeworld:
rpm-ostree override remove mesa-va-drivers --install mesa-va-drivers-freeworld
  1. Install additional packages:
rpm-ostree install gstreamer1-plugin-libav gstreamer1-plugins-bad-free-extras gstreamer1-plugins-bad-freeworld gstreamer1-plugins-ugly gstreamer1-vaapi

@kwizart
Copy link
Member

kwizart commented Nov 16, 2022

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
Copy link

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
Copy link
Author

DarkArc commented Jan 3, 2023

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
Copy link

GregDuhamel commented Jan 3, 2023 via email

@DarkArc
Copy link
Author

DarkArc commented Jan 3, 2023

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
Copy link

thestonewell commented Jan 3, 2023

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
Copy link

GregDuhamel commented Jan 3, 2023 via email

kwizart added a commit that referenced this issue Jan 8, 2023
@romulasry
Copy link

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
Copy link

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

@romulasry
Copy link

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

@romulasry
Copy link

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

@rpmfusion-infra rpmfusion-infra locked as resolved and limited conversation to collaborators Jan 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests