Latest Steam OS 3.4 Preview breaks hardware decoding

This isn't broken functionality, it's disabled by default. After https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15258, found in mesa 22.2.0, a conscience decision needs to be made to enable these hardware codecs and this will need to go through some kind of legal review before it can be re-enabled.

Fascinating and unfortunate! Thanks for the info!

It's possible that maybe the hardware decoding switch should be... disabled or removed in that case? Or possibly functionality for a royalty free codec for HW encode/decode?

Looks like we will need to start pushing hard for campaigns to eliminate software patents completely, like End Software Patents, Stop Software Patents in Europe and anything similar around the world. And yeah at the same time push hard for expanding the use of existing free/open/unpatented formats/codecs (AV1 for video, Opus for audio).

Is it possible that AV1 Encoding & Decoding could be used instead?

I am unsure if the silicon used in the Steam Deck supports AV1 or not..... So this would be assuming that it did.

If not the alternative is to take the approach that is being suggested by @joeknock90 or @JLP depending how what your views are on this.

Personally I am of the opinion that all of these standards should be forcibly Open-Sourced, because it is logical even in a legal sense to allow a core standard for many industries to be locked behind a paywall that means that it can't be used unless people pay a license cost for it.

These "Licenses" should be paid for by the hardware vendors, and, new standards should be developed by a group that INCLUDES those same hardware vendors so that these types of issues can never occur.

Losing H.264 decoding on video content is a ridiculous situation to be in....

AV1 won't help much here since hardware encoding for it is supported only on RDNA3/7xxx (SD has RDNA2), Intel Arc and GeForce 4xxx so far (and you need it on your host for streaming). Those are and will be out of reach of most Steam users for quite a while. Older gen (like RDNA2 or GeForce 3xxx) only got AV1 decode support.

So while you could stream AV1 to a Steam Deck, most likely host you're streaming from doesn't have a hardware encoder for it.

So.

I just compiled https://github.com/Frogging-Family/mesa-git on my Arch desktop and copied the packages over to my deck, threw steam os into writable mode and installed them.

I have hardware decoding back.

      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

I'm positive this will break something else, and I know it won't survive and update.

But thanks for the PKGBUILD TKG!

I'll update if anything breaks.

Please don't close it if it's not fixed, valve needs to re-enable h264/h265 hardware en/decoding in their packages https://www.reddit.com/r/Fedora/comments/xpt34f/fedora_37_drops_vaapi_accelerated_hardware_video/

Replying to https://github.com/ValveSoftware/SteamOS/issues/903#issuecomment-1312727044

Did you change the config on the package or just built it w/o needing to touch config of the mesa package?

Replying to https://github.com/ValveSoftware/SteamOS/issues/903#issuecomment-1312727044

Did you change the config on the package or just built it w/o needing to touch config of the mesa package?

Just built it with default options on my desktop, copied it over, and installed.

I'm still pretty surprised it worked.

I'm still pretty surprised it worked.

Why wouldn't it work? :D It's a PC after all.

I am concerned about this situation because the devices were purchased as modern PCs with the expectation that they would have decoding functionality that allows for video conferencing, watching video streaming services, etc.

Losing this functionality to decode an 18 year old codec will result in drained batteries from high power consumption, a loud fan and negative customer feedback.

It would likely be best to pay the fee (10 cents?) if there is a demand received to do so and grandfather existing Steam Deck purchasers into a group that can decode and a future group that cannot, or inevitably face a class action lawsuit from the customer side for the after-purchase removal of functionality.

This also breaks the hardware accelerated encoding for what it's worth, for example when using the Deck via Steam Link, i.e. the other way round. Playing games that use lots of resources will struggle getting streamed.

It's pretty trivial to cleanly rebuild the original packages, thankfully Valve provides the source. I did this for the current beta in a chroot and it took about 15 minutes to build them on the Deck itself. Currently thinking of a more automated way to do this. (Using something like the mesa-git packages might break other things, who knows).

But having hardware accelerated H.264 is essential for a device that is already limited by its battery (as much as I love my Deck). If packages can't be offered for legal reasons and no quick solution can be found, maybe a user-friendlier way to replace packages could be provided by Valve where an unofficial repo could install replacements for the truly free libva* packages?

It bears mentioning that Valve is selling this product in other countries besides the USA so customers who are outside the USA are legally exempt from this nonsense.

This also breaks the hardware accelerated _en_coding for what it's worth, for example when using the Deck via Steam Link, i.e. the other way round. Playing games that use lots of resources will struggle getting streamed.

It's pretty trivial to cleanly rebuild the original packages, thankfully Valve provides the source. I did this for the current beta in a chroot and it took about 15 minutes to build them on the Deck itself. Currently thinking of a more automated way to do this. (Using something like the mesa-git packages might break other things, who knows).

But having hardware accelerated H.264 is essential for a device that is already limited by its battery (as much as I love my Deck). If packages can't be offered for legal reasons and no quick solution can be found, maybe a user-friendlier way to replace packages could be provided by Valve where an unofficial repo could install replacements for the truly free libva* packages?

Hi, could you provide a quick tutorial of how to rebuild the package and have back hardware decoding?

any news about this? isn't it possible to turn on again those feature in the driver? i mean it's actually very annoying... ( at least youtube vp9 is supported ..)

This also breaks the hardware accelerated _en_coding for what it's worth, for example when using the Deck via Steam Link, i.e. the other way round. Playing games that use lots of resources will struggle getting streamed. It's pretty trivial to cleanly rebuild the original packages, thankfully Valve provides the source. I did this for the current beta in a chroot and it took about 15 minutes to build them on the Deck itself. Currently thinking of a more automated way to do this. (Using something like the mesa-git packages might break other things, who knows). But having hardware accelerated H.264 is essential for a device that is already limited by its battery (as much as I love my Deck). If packages can't be offered for legal reasons and no quick solution can be found, maybe a user-friendlier way to replace packages could be provided by Valve where an unofficial repo could install replacements for the truly free libva* packages?

Hi, could you provide a quick tutorial of how to rebuild the package and have back hardware decoding?

Quick and dirty (REQUIRES SUDO aka password set on the deck user):

1. Go to desktop mode & Open a terminal
2. git clone https://github.com/Frogging-Family/mesa-git.git (if command is not found, you need to install it which is not possible until one does sudo steamos-readonly disable, and does sudo pacman -Sy to update package cache. You need base devel packages before you can build things so do that with sudo pacman -S --needed base-devel and accept the default all in selection. After which you need to install git via sudo pacman -S git (if for whatever reason the command before did not install it too).
3. cd mesa-git
4. makepkg -si (Will error out if one tries to do it with sudo and will take a while, best to have AC plugged in)

Replying to https://github.com/ValveSoftware/SteamOS/issues/903#issuecomment-1356316735

in game, did you noticed any problem? less fps? stability problem? anything? or just in general?

Replying to #903 (comment)

in game, did you noticed any problem? less fps? stability problem? anything? or just in general?

Not sure as I don't need it due to not using preview build.

I'm not sure if taking a mesa-git package is a great idea, Valve patches these packages heavily themselves (i.e. the latest preview apparently added a fix for the pesky virtual keyboard bug in desktop mode). I used a method that doesn't mess up my installed packages and basically only requires root to replace the libva packages, not the whole mesa package.

This entails creating a chroot (with bubblewrap), then just rebuilding the two packages needed (mesa and lib32-mesa). It's not straight-forward unfortunately, which is why I'm trying to automate this a bit further. Instructions to even get to the point you can compile your own packages can be found here: https://gitlab.com/popsulfr/steam-deck-tricks#create-a-steamosarch-development-root-in-your-home-folder Warning: Do NOT do this if you've never messed with bubblewrap, chroots and the like. This will eat your cat.

This installs fakeroot in a local path (needed for bubblewrap), installs the packages of the current beta branch, then you can download the source packages from here: https://steamdeck-packages.steamos.cloud/archlinux-mirror/sources/jupiter-beta/?C=M&O=D Install the deps for building. Next, modify the PKGBUILD to include the needed codecs. And finally recompile the packages with makepkg, replace just the *libva-* packages. I'll have a week off during the holidays and might at least make this a step by step guide with a few helper scripts.

It's probably best to just wait for preview to become stable, by then this issue will either have been fixed (unlikely since it involves legal things and they probably take ages) or someone will just offer replacement packages which will basically have to be downloaded and installed with two commands.

Pertinent to this discussion, the Khronos group has finalized the Vulkan extensions for accelerated h.264 and h.265 decode:

https://www.khronos.org/blog/khronos-finalizes-vulkan-video-extensions-for-accelerated-h.264-and-h.265-decode

It seems this issue has landed in stable: https://steamcommunity.com/games/1675200/announcements/detail/3646258449514531839

This isn't broken functionality, it's disabled by default. After gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15258, found in mesa 22.2.0, a conscience decision needs to be made to enable these hardware codecs and this will need to go through some kind of legal review before it can be re-enabled.

Can this legal review be escalated? This is a major issue for the Steam Deck as support for streaming from another PC is a very important part of the Deck's functionality. From what I can tell, Steam Remote Play only supports the patent encumbered AVC (H.264) and HEVC (H.265) codecs, meaning that there is no support for the hardware decoded remote play on the Steam Deck. Either support for VP9 and AV1 must be added ASAP, or Valve should pay for the patents.

From what I can tell, H.264 patents cost ~$0.20 and H.265 patents cost ~$1.60. In my opinion, as Valve sold these devices with support for these codecs, Valve should pay the royalty fees for them, which amount to ~$2 per device. Removing support for these codecs will likely lead to lawsuits against Valve for removing functionality from the device after purchase, which could result in large legal costs for Valve.

As this change is now live, Valve needs to perform the legal review and re-enable the codecs ASAP.

Not that I want to push or anything but to add some info.

I am a tinkerer, so my purchase of the Steam Deck was twofold.

1. New hardware.

B. Stream games from my computer while my partner watches garbage reality television.

And

D. Stream from Linux

Forgive the jestful Home Alone reference list, but for these use cases both the Deck and Steam for Linux has fallen short. It seems like every "improvement" comes with a caveat or some other functionality breaking completely.

Just my 2 cents.

Has there been any update on the legal discussions about these codecs or are they just going to be off for the foreseeable future until an alternative can be found?

I'm not sure if taking a mesa-git package is a great idea, Valve patches these packages heavily themselves (i.e. the latest preview apparently added a fix for the pesky virtual keyboard bug in desktop mode).

As long there are the source packages it should be possible to recompile them from valve with decoding enabled again.

As long there are the source packages it should be possible to recompile them from valve with decoding enabled again.

Is there a link to the source packages?

You don't even need to compile anything yourself, you just need a mesa package with support for parent-encoumbered codecs. You could simply use Arch's upstream mesa package.

That's a workaround though, not a solution. It requires you to disable the read-only system and will be wiped upon the next system update. Not to mention such a modification isn't something the wide user-base is able to do.
This is something Valve must fix.

Valve being a US company means it must care about software patent. As much as we wish they wouldn't, that's the reality.

There's hope though as the Deck's SoC is a custom solution from AMD specifically for the SD and that might include a license for the codecs the hardware implements. We'll have to see what Valve's internal legal review will reveal.
As @AlexNPavel said though, there's always the option for Valve to pay for a license for SD users. Perhaps not for h.265 as it's outrageously expensive and intransparent but h.264 might be tenable. H.264 is the most important one because it's widely used and pretty much required for live streaming. H.265 isn't really all that useful outside of tinkerer use-cases and isn't widely used either.

Is there a link to the source packages?

This 'should' work https://linuxconfig.org/how-to-rebuild-a-package-using-the-arch-linux-build-system

then you can edit what you want and rebuild the package but it requires some extra steps for signing and the decks read only mode.

And yes, valve should license the patents for the usage. they are still important and even if they cant or dont like to make it for free, they could add a purchase option and enable it for the device. like raspberri pi sold mpeg2 and vc1

This installs fakeroot in a local path (needed for bubblewrap), installs the packages of the current beta branch, then you can download the source packages from here: https://steamdeck-packages.steamos.cloud/archlinux-mirror/sources/jupiter-beta/?C=M&O=D

It seems that link is 404'ing. :( @bocki

With the release of 3.4 they switched some directories around, this is the new link apparently: https://steamdeck-packages.steamos.cloud/archlinux-mirror/sources/jupiter-rel/?C=M&O=D

I'm at work right now but I'm going to update my Deck tonight, recompile the packages and put them here so we can all fry our Decks together. For someone who can enable root access this is really a 30 second task and a minor nuisance but the bigger issue of how this is solved for everyone remains.