Latest Steam OS 3.4 Preview breaks hardware decoding

[joeknock90]

Your system information

• Steam client version: 1668201961
• SteamOS version: 3.4 Preview
• Opted into Steam client beta?: Yes
• Opted into SteamOS beta?: Yes
• Have you checked for updates in Settings > System?: Yes

Please describe your issue in as much detail as possible:

Latest Steam OS 3.4 Preview breaks hardware decoding in remote play.

Installing libva-utils and running vainfo shows this:

vainfo: VA-API version: 1.16 (libva 2.15.0)
vainfo: Driver version: Mesa Gallium driver 22.2.0 for AMD Custom GPU 0405 (vangogh, LLVM 14.0.6, DRM 3.45, 5.13.0-valve31-1-neptune)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

In case it helps, here's what pacman shows for installed packages for libva-mesa-driver

(deck@KnockDeck ~)$ pacman -Ss libva-mesa-driver
jupiter-beta/lib32-libva-mesa-driver 22.2.0.157819.radeonsi_3.4.0-3 [installed]
    VA-API implementation for gallium (32-bit)
jupiter-beta/lib32-mesa-debug 22.2.0.157819.radeonsi_3.4.0-3
    Detached debugging symbols for lib32-vulkan-mesa-layers
jupiter-beta/libva-mesa-driver 22.2.0.157819.radeonsi_3.4.0-3 [installed]
    VA-API implementation for gallium
jupiter-beta/mesa-debug 22.2.0.157819.radeonsi_3.4.0-3
    Detached debugging symbols for vulkan-mesa-layers
extra-beta/libva-mesa-driver 22.2.1-1 [installed: 22.2.0.157819.radeonsi_3.4.0-3]
    VA-API implementation for gallium
multilib-beta/lib32-libva-mesa-driver 22.2.1-1 [installed: 22.2.0.157819.radeonsi_3.4.0-3]
    VA-API implementation for gallium (32-bit)

Driver seems to be there, but

No VAEntryPointVLD for H264 at all.

Nor HEVC but that's a separate issue I suppose =p

Steps for reproducing this issue:

1. Enable Hardware decoding on Steam Deck as client and enable show Details
2. Start a remote play stream
3. Software decoding is being used.

[kisak-valve]

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.

[joeknock90]

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?

[JLP]

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).

[TOGLK]

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....

[revanmj]

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.

[joeknock90]

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.

[soredake]

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/

[samip5]

Replying to #903 (comment)

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

[joeknock90]

Replying to #903 (comment)

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.

[samip5]

I'm still pretty surprised it worked.

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

[Sunspark-007]

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.

[bocki]

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?

[Sunspark-007]

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.

[vinanrra]

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?

[snakeeater4526]

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 ..)

[samip5]

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)

[snakeeater4526]

Replying to #903 (comment)

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

[samip5]

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.

[bocki]

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.

[Sunspark-007]

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

[samip5]

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

[AlexNPavel]

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.

[joeknock90]

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.

[waspennator]

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?

[nille02]

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.

[ThomasEricB]

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?

[Atemu]

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.

[nille02]

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

[samip5]

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

[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.

[Berobad]

If licencing is an issue shouldn't h264 software decoding be disabled as well on the steamdeck?
Since from a licencing standpoint it doesn't really matter if a device can decode h264 in software or hardware, just it's capability is enough.

[ruineka]

Losing this feature makes this update more of a downgrade than anything. Especially since it broke EAC games like DKO Divine Knockout as well. This update overall just ruined a lot for me :(

[nille02]

i've checked my deck for enable it again and i'm on 3.4.2 but vainfo tells me there is still support there. maybe they just disabled it temporary?

(deck@steamdeck ~)$ vainfo
error: can't connect to X server!
vainfo: VA-API version: 1.16 (libva 2.15.0)
vainfo: Driver version: Mesa Gallium driver 22.2.0 for AMD Custom GPU 0405 (vangogh, LLVM 14.0.6, DRM 3.45, 5.13.0-valve36-1-neptune)
vainfo: Supported profile and entrypoints
      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

[bocki]

Yup this is true, it's also back in the PKGBUILD. Issue solved? :)

-D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \

[ruineka]

Yup this is true, it's also back in the PKGBUILD. Issue solved? :)

-D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \

This would be amazing if this is the case.

[revanmj]

I was kinda wondering if anyone actually checked this after initial 3.4 Preview release or did everyone wait for fix confirmation from Valve :)

[WyvernDotRed]

I was kinda wondering if anyone actually checked this after initial 3.4 Preview release or did everyone wait for fix confirmation from Valve :)

The 3.4 release still lacked the encoding support and 3.4.1 only updated the SD card path so this update was affected too.
I tested this with Steam Link using it's streaming_log.txt as that is the feature I care about, on 3.4 Stable it logged
"CaptureDescriptionID" "Desktop PipeWire NV12 + libx264 main (4 threads)"
and more subjectively, used about 9W CPU power while streaming a game that itself is light on CPU usage.
After updating to 3.4.2, Steam Link now logs
"CaptureDescriptionID" "Desktop PipeWire DMABUF + VAAPI H264"
and this same game streamed using about 0,6W on the CPU, with a noticeably clearer image being received.

So this confirms that per build 20221221.2, a.k.a. SteamOS 3.4.2, hardware encoding was enabled again and more importantly, actually functions too.
Issue solved :)

[mkaatman]

What open encoding standard should we be gently nudging developers towards?

[arazilsongweaver]

What open encoding standard should we be gently nudging developers towards?

I believe the current preference is AV1 from the Alliance for Open Media.

[ThomasEricB]

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

I know how to rebuild the package, I was asking for the link to the source packages that got removed (so I can rebuild them).

[snakeeater4526]

i've checked my deck for enable it again and i'm on 3.4.2 but vainfo tells me there is still support there. maybe they just disabled it temporary?

(deck@steamdeck ~)$ vainfo
error: can't connect to X server!
vainfo: VA-API version: 1.16 (libva 2.15.0)
vainfo: Driver version: Mesa Gallium driver 22.2.0 for AMD Custom GPU 0405 (vangogh, LLVM 14.0.6, DRM 3.45, 5.13.0-valve36-1-neptune)
vainfo: Supported profile and entrypoints
      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 confirm the update 3.4.2 is fixing the issue, I've got all the decoding/encoding back ( had to go back to BETA software, NOT the "latest preview" software. latest preview was stuck on 3.4.0)

[SaltyBet]

FYI, when enabling Hardware Encoding from the host, the Steam Deck client shows libavcodec Software Decoding; this is with Hardware Decoding Enabled on the client:

When using Software Encoding from the host, the Steam Deck client shows VAAPI tiled hardware decoding:

[helliongame]

the issue has reppeated again, chiaki fails again for this issue

streetpea/chiaki-ng#63

[aronsr1]

the issue has reppeated again, chiaki fails again for this issue

streetpea/chiaki4deck#63

I am experiencing the same issue since yesterday. I am on V3.4.6, it was working before. Very frustrating as I only use my steam deck as a streaming device!

[ranger149]

As I don't believe our current issue is related to this past one, I opened up a new issue here: #1014
I'll leave it to the guys with more experience to make the actual determination, however.

[mike-bricknell-barlow]

Can confirm that this issue is still occurring, but only with the version of Moonlight installed via the Discover store.

If it helps anyone else, the work-around that fixed it for me was:

• Uninstall Moonlight via the Discover store
• Go to https://github.com/moonlight-stream/moonlight-qt/releases on your deck
• Download the AppImage version of Moonlight, and run that

[iloveicedgreentea]

Can confirm that this issue is still occurring, but only with the version of Moonlight installed via the Discover store.

If it helps anyone else, the work-around that fixed it for me was:

• Uninstall Moonlight via the Discover store
• Go to https://github.com/moonlight-stream/moonlight-qt/releases on your deck
• Download the AppImage version of Moonlight, and run that

Thanks this worked for me. I am on the OLED model and moonlight from discovery was exiting games, not crashing. I load a game, it works for a few min, then it quits. Uninstalling that and then downloading the appimage (make it executable) and adding it to steam fixed my issue immediately.