#404 Workstation's default video player (Totem) requires gstreamer1-vaapi for video acceleration
Closed: Won't fix a year ago by catanzaro. Opened a year ago by jrelvas.

First issue! Let me know if I'm doing something wrong :)

Fedora Workstation ships Totem as its default video player. Totem uses gstreamer for its video playback, which implements video acceleration through the gstreamer-vaapi library. Unfortunately, Fedora Workstation does not include this package in default installations, meaning that its default video player is left without video acceleration, even with the codecs that Workstation is shipped with.

This library is already packaged by Fedora gstreamer1-vaapi, so the only change required is to include it as part of the default installation. Doing so would enable video acceleration on Totem (and every other program which uses gstreamer for video playback) for all codecs which Fedora ships.


Hi, we intentionally do not include gstreamer1-vaapi because it is deprecated and likely to break video playback. Its developers have been warning people not to use it for several years now. E.g. Historically, installing it has been a great way to seriously break WebKit. So I'm going to decline this request; even though it might work well for you, it's not a suitable default for Fedora.

But good news! GStreamer 1.24 should have accelerated video decoding working by default via GstVA. So hardware decoding should become available in a future Fedora release, and sooner rather than later. In the meantime, you can test the new elements using the environment variable GST_PLUGIN_FEATURE_RANK=vah264dec:MAX,vah265dec:MAX,vampeg2dec:MAX,vavp8dec:MAX,vavp9dec:MAX to uprank the element and test to make sure you don't find bugs.

We also need to actually provide VA-API drivers as well. Intel graphics users will need #209 fixed. AMD users are already good because that is covered by mesa. NVIDIA users are probably out of luck?

Finally, note we'll of course only support unencumbered codecs. For decoding encumbered formats, you can investigate RPM Fusion.

Metadata Update from @catanzaro:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

a year ago

I wasn't aware of gstreamer1-vaapi's deprecation, thanks for the information. It does seem unsuitable for inclusion in that case.

In any case, gstreamer 1.24 supporting decoding by itself is good news and makes the gstreamer1-vaapi requirement obsolete. I'll give the env variables a try and see if I run into any issues.

Looks like GstVA is only included in gstreamer1-plugins-bad-free-extras, which initially threw me off.

Nevertheless, I can confirm that video acceleration via GstVA is up and running! Successfully tested it with both gst-play and totem.

Looks like GstVA is only included in gstreamer1-plugins-bad-free-extras, which initially threw me off.

Good catch. That's a problem, actually. We need to fix that because -extras is where we relegate elements that we don't want installed by default.

Before I forget, here's a confirmation that video acceleration seems to be working OOTB now on Fedora 40/41.

One small caveat - nvcodec/cuda plugins are preferred over va, meaning that totem's using my dgpu to decode h264, h265 and av1 instead of my igpu. But that's an orthogonal issue. Things should be working as expected for everyone who doesn't have a nvidia hybrids graphics laptops, or in other words, most people. Disabling nvdec with GST_PLUGIN_FEATURE_RANK allows totem to decode using the igpu as expected.

Using va over nvcodec is something that would probably be solved upstream, so no further action needed from Fedora Workstation :)

Log in to comment on this ticket.

Metadata