We don't currently support VA-API for encoding, but it's a valid feature request, thanks.

@kisak-valve, are you saying hardware encoding is supported on this card? Perhaps by some means other than VA-API?

It do have it enabled in the settings. I have not seen any report of any Linux user having hardware encoding working on any AMD GPU, so have assumed it is not supported. Which is consistent with Plagman's comment, unless perhaps it's supported with the proprietary drivers or something. I asked about the requirements for it at http://steamcommunity.com/groups/homestream/discussions/0/1842367319523385800/ and heard nothing.

It sounds like that for now that support is limited to there being a tantalizing checkbox which does nothing. ;)

I look forward to that checkbox being wired up to enable actual hardware encoder support code at some point in the future.

That checkbox does enable other backends such as NVENC, but nothing that currently works on Mesa to my knowledge.

Can anyone enumerate the roadblocks for this feature here?

I see the same behavior on an AMD Radeon R9 Nano with the current AMDGPU-Pro drivers. It also supports H.264 encoding via VA-API:

~$ vainfo
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

When using the "beautiful" option in FullHD, the PC I want to use it on, reports a load of 300 %. This means that the CPU resources of my Phenom II X6 1090t get cut in half:

The significantly increased power consumption of the software encoding causes more noise output. My PC screaming after me impairs the success of Steam Link of moving away from it. To me, this makes Steam Link kind of pointless.

In the performance overlay on the Steam Link, I the frame rate drop from 60 to 30 or even lower when much of the screen content changes quickly. When I start a 3D game, it runs fine if at only 30 FPS on the host PC, but Steam Link sees 1 % packet loss, which results in 40 % frame drops and is obviously unplayable. Steam Link estimates the bandwidth of my Gigabit switch at up to 68 MBit/s, so that does not seem to be cause of the the issue.

The massive benefit enabling hardware video encoding under Linux would have for users like me can be seen in the response to enabling it under Windows for AMD cards:

https://steamcommunity.com/app/353380/discussions/0/451852225141685452/#c365163686049333645

@kisak-valve On what you mentioned, what kind of support do AMD-gpu's (using mesa) have?

All @kisak-valve was saying is that this issue is not specific to the rx480 as the title says.

All AMD GPUs on mesa use VA-API for hardware encoding and steam doesn't support VA-API for encoding at the moment.

@plagman should there perhaps be a seperate issue created to feature request VA-API encoding support?

I asked because there is also vdpau encoding, and maybe that is supported.

I do agree on creating a separate, or rather renaming this issue, specifically for VA-API.

Has there been any update on this issue recently?

That is, are we close to being able to use hardware encoding on AMD hardware yet?

I'm trying to get hardware encoding on a Ryzen 2200G under Ubuntu 18.04 with the 4.16.12+ kernel from here and MESA drivers from here. I installed the necessary :i386 packages, but only have stuttering software encoding. vainfo tells me VA-API 1.1 is installed and H264 Main/High are available... Anything I could try?

@HorstBaerbel You might want to read the ticket more thoroughly, particularly https://github.com/ValveSoftware/steam-for-linux/issues/4890#issuecomment-362106453 . All AMD GPU owners (that includes Ryzen+Vega combo) are currently out of luck, until Steam devs implement support for them.

This is really annoying honestly. I just finished setting up my streaming network and this encode issue has been a pain in the butt.

Same issue, was testing streaming and noticed the substantial CPU usage, looked in to it and no hardware encoding was being performed on a Vega card, which was a bit wtf'ery, then found this issue. Why on earth would a proprietary useless one like NVENC be built in but the linux standard(s?) VA-API not being supported is a bit astounding... >.>

Yup, it's definitely a glaring outstanding feature in an otherwise great offering. It would be great to see some progress in this area. I'm sure there are many of us AMd users in the community who would be glad to help out.

@karpal You might be right, but what confused me is that VA-API is already being used for hardware decode (on my Laptop with an Intel HD 620 iGPU though), so having VA-API support for encoding too only seemed logical...
The issue is a year old and probably relevant much longer already. If the client (sans the DRM/protection parts) would be open-source, somebody would have fixed it already. But using Github to open a bug tracker without any source in it feels a bit half-hearted to me anyway...

Btw: Is it possible to render games on one GPU and use an extra (e.g. cheap Nvidia) GPU for encoding?

Btw: Is it possible to render games on one GPU and use an extra (e.g. cheap Nvidia) GPU for encoding?

Hmm, this is an interesting idea. Some searching online shows that it is somewhat doable with an AMD primary, then adding an nvidia card and installing the drivers with the --no-opengl-files option which should make sure it isn't overwriting anything display related. That said, this info is generally for people doing compute-type work. We would have to check if this would install NVENC and make it usable.

It then depends on how steam detects encoding options. It all might be for nothing if it only checks the current display GPU then falls back to software.

I don't have any nvidia GPU available at the moment, but I'll poke around on ebay etc to see if I can find something for cheap.

Sounds good! Searching Wikipedia tells me that all Nvidia chips from the Kepler (GKxxx) generation on should support NVENC. These are used in the Geforce 600 and Geforce 700 series.
In theory a cheap Kepler GT 630/730 should thus suffice, but be aware that there are Fermi GT 630/730 models too (wtf actually)! Getting a GT 740 or GTX 650/750 might actually be the safer bet as there seem to be no Fermi versions of them. Will try to get my hands on a GT 630 (hopefully Kepler) card next week and will try this out too.

But that means the image must go through the PCIe bus for each frame?

Yeah the way they re-branding of mid and low-end GPUs is pretty frustrating [AMD do it as well].
Interestingly, it appears that the GT 710 is an actual Kepler core and is still available in many stores brand new for very cheap.

But that means the image must go through the PCIe bus for each frame?

Yep, that's my concern as well. I don't know enough about how GPU encoding takes place. How does NVENC perform perform the encoding? Does the encoding take place with the data directly from the frame buffer [or, from somewhere on the same graphics card]?. If so, we're going to be sweet out of luck.

But that means the image must go through the PCIe bus for each frame?

I know what you mean: (GPU->RAM->GPU->RAM->CPU->Network) instead of GPU->RAM->CPU->Network. Ideally DMA should take care of that, but tbh I have no idea how this works internally.

Does the encoding take place with the data directly from the frame buffer [or, from somewhere on the same graphics card]?. If so, we're going to be sweet out of luck.

Well, all the GPU drivers/software allow for some form of hardware-accelerated transcoding through the driver/software. So encoding must be possible w/o having data "in the framebuffer" / on the display (supposedly it is much cheaper to encode what's already in VRAM though, s.a.). Where the driver / card stores inter-frame information etc. for encoding I have no idea.

I guess we need to try it or Valve to enable VA-API for AMD. Whatever happens first... ;P

I'm not actually sure DMA works between PCI-E nodes? Really though, VA-API should be used as it should support everything now (not just AMD but also Intel, some add-in cards, and it 'should' support nvidia as well depending on their driver quality, which is questionable as of late).

+1 for VA-API support for encoding. My CPU would definitely enjoy this.

The GT 630 I got was a Fermi version so no testing atm :(

Would love to see VAAPI support. As mentioned this would benefit more than just AMD.

Any update on this? This is sorely needed as the software encoding eats a considerable amount of CPU even on a higher end machine.

Same here. With the introduction AMD Raven Ridge we have a perfect in-home streaming client platform but without the proper hardware support on the Steam side it just sits there using software encoding. The APU in my living room machine would like to have something to chew on, properly :)

VAAPI support +1

If VA-API isn't supported at all, Steam does not use hardware encoding with Intel graphics cards either, does it?

If VA-API isn't supported at all, Steam does not use hardware encoding with Intel graphics cards either, does it?

Correct. Steam only implements the proprietary nVidia protocol instead of the openly supported (by nVidia as well) protocol.

Can we please get a response from Valve on this?

Is hardware encoding going to be supported on Linux for AMD users or not?

@kisak-valve

AMF (h264) now on Linux via Vulkan: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/releases

AMF (h264) now on Linux via Vulkan: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/releases

Requires Pro stack though... https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/130#issuecomment-419309783

@timknab So close yet so far away :disappointed: (That's my issue)

@timknab So close yet so far away 😞 (That's my issue)

Yeah, on Arch here too. Not sure the Pro stack is worth the effort/frustration, hopefully someone can get it working on the open driver or VA-API gets implemented soon.

I thought the Pro stack had its development mostly halted and all new features and development were going into the open source amdgpu driver now? Why would they require the pro driver?!

@kisak-valve Any news on this ?

I guess this is a duplicate of https://github.com/ValveSoftware/steam-for-linux/issues/4119 and can be resolved in the same way?

See comment at https://github.com/ValveSoftware/steam-for-linux/issues/4119#issuecomment-370708401 : http://voltaicforge.com/linux/steam-vaapi-fix-linux/

This isn't a duplicate of #4119 - That's hardware decoding.
This is about hardware encoding. Currently unavailable because amdgpu lacks the driver support to do it.
The pro stack has not long released AMF support via Vulkan, still unsupporterd by Steam and nothing yet for the open source driver. Hopefully AMF encoding will be made available to amdgpu in due course.

@Holston5 What exactly is unavailable because of missing support in amdgpu? The start post even mentions that hardware encoding is supported since at least March 2017. In fact, I am actively making use of it with libva and gstreamer on my AMD R9 290 (with amdgpu).

@sejikun Are you absolutley sure? I have a 380 and like many others the hardware encoding tickbox in steam does nothing. Encoding is still done in software. In FFMPEG Our cards are supposed to have vaapi support, but it doesn't work because b-frames are not supported in the driver.
You can test this using the ffmpeg snap package
ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi -b:v 5M ~/output.mp4

@Holston5 Well that the hardware tickbox in Steam does nothing is to be expected. This is what this bug is all about: Valve not making use of vaapi in the first place. But the support from the driver-side is there. Valve only needs to use the API.

FFMpeg never worked for me with vaapi. Neither on AMD nor Intel graphics cards.
With gstreamer however, I am able to encode HEVC in FullHD good quality with negligible CPU-usage and something in between of 30 to 60fps on a new (mobile) Vega 8 - and h264 with my R9 290, so I'm pretty sure it works.

Here is the cli I use (captures a FullHD video from the desktop and encodes it to h264):

gst-launch-1.0 -ev ximagesrc use-damage=0 endx=1919 endy=1079 ! video/x-raw,framerate=60/1 ! videoconvert ! video/x-raw,format=NV12 ! vaapih264enc quality-level=3 rate-control=2 ! "video/x-h264,profile=baseline,stream-format=byte-stream,framerate=60/1" ! h264parse ! mp4mux ! filesink location=test.mp4

But you indeed are right, B-Frames seem to be not supported by the card-firmware that AMD made available, even though the hardware should support it since VCE2.0.

Inspecting the resulting file per ffprobe -show_frames /tmp/test.mp4 | grep pict_type from the cli above shows that there are no b-frames.
But do we need B-Frames for Steam streaming? ffmpeg can properly display the file that I created with gstreamer, so the receiving end should be no problem.

@seijikun this is invaluable information, thank you

@seijikun this is invaluable information, thank you

@Holston5

Is there any way to use this information to enable hardware encoding in Steam with an AMD card right now?

@timknab
Unfortunately not

Has there been any news on this front? Would love to be able to use hardware encoding, especially since the API to do so is already there, ready to be used :)

But do we need B-Frames for Steam streaming?

No.

Not only are they unnecessary, but because they depend on both the previous and next I/P frames, B-frames add both latency and encoder/decoder complexity. Thus, when low latency is desired, B-frames are typically not used.

so still only support for nvidia for encoding. software encoding KILLS game performance, and is such a waste of gpu or quicksync acceleration support on the hardware

With Steam Link Anywhere, this issue becomes even more relevant. Would be nice with hardware encoding support!

@kisak-valve or anyone else able to comment on if this is being worked on or not?

Software encoding is such a huge drain of my resources [currently using 4/8 cores for it] which are better used to run the game itself. There is also the extra latency which software encoding adds which arguably is the bigger issue for many games.

Also, is there any way we can help? Is there an API or something in steam we can use to hack our own solution together?

I would love to have hardware encoding for amd, currently losing a lot of performance when streaming to my laptop

I recently tried out hardware encoding on an RX 470 via FFmpeg and tried recording gameplay using OBS (which uses VAAPI via FFmpeg). TL;DR: AMD's hardware encoder is not very useful on Linux because when the GPU is near 100% utilisation, the encoder chokes and drops 99% of frames, resulting in a slideshow recording. The cause is most likely that the ability to control the speed/compression tradeoff is either not implemented or not functional on Linux and the encoder defaults to the maximum compression ratio, which for whatever reason craps out when other parts of the GPU are under intense load.

This has also been documented to happen on Windows in a hardware encoder investigation done by GameSpot's Tim Schiessert:

AMD’s encoder is even worse in that when your GPU utilization is up near 100%, the encoder completely craps its dacks and can’t render more than about 1 frame per second, which wasn’t an issue with the Nvidia cards.

I was able to get the encoder working with a frame limiter enabled, which brought GPU utilization down to around 60% in Forza Horizon 4, but even with the ‘Quality’ encoding preset, the quality Vega 64 produced was worse than with even Nvidia’s Pascal cards.

I also saw a user report about this on Reddit. Apparently OBS has an option on Windows to change the compression efficiency from "best quality" (which is the default) to "balanced" which fixes the framedrop issue, so the feature definitely does exist. It's just not available on Linux for whatever reason. Not even FFmpeg is able to use the feature: it would evoked with the -compression_level switch, but this shows the error [h264_vaapi @ 0x5642618e45c0] Quality attribute is not supported: will use default quality level.

This is probably why AMD's hardware encoding isn't yet supported for In-Home Streaming on Linux. It's not very useful to add even preliminary support when you can't guarantee it's going to work properly.

If anyone knows or has suggestion as to where the root cause of this bug should be reported to (or if it has been already), please tell so we can track it.

[h264_vaapi @ 0x5642618e45c0] Quality attribute is not supported: will use default quality level.

This is probably why AMD's hardware encoding isn't yet supported for In-Home Streaming on Linux. It's not very useful to add even preliminary support when you can't guarantee it's going to work properly.

If anyone knows or has suggestion as to where the root cause of this bug should be reported to (or if it has been already), please tell so we can track it.

The AMD va-api driver is part of Mesa. Maybe start with the Mesa users mailing list.

This is probably why AMD's hardware encoding isn't yet supported for In-Home Streaming on Linux. It's not very useful to add even preliminary support when you can't guarantee it's going to work properly.

Since when was everything in Steam guaranteed to work properly? ;) There's already a check-box for hardware encoding in the GUI, just leave it disabled by default if it's flakey.

It's been widely reported that Google's new game streaming service is running AMD GPUs on Linux, so the capability exists in some form, somewhere.

Valve has AMD driver developers on staff. They have made other improvements in AMD drivers, and I expect they could implement the necessary quality preset code as well if it were a blocker to getting hardware encoding working.

IMO AMD has more to gain than Valve from Steam supporting their GPUs for hardware encoding (how many people on this thread will buy Nvidia next time?) and should work together with Valve to get this feature implemented.

@veikk0 and @toojays : Apparently it works through gstreamer, but not through FFmpeg.
The test didn't bother testing more than one game on AMD, plus someone in the comments mentioned it: Why not use the Vendor-specific tools to test this too? I'd blame it on driver issues or OBS not doing the right thing. That aside: That was Windows, not Linux, so almost entirely a different thing.
It might be that on Linux the driver, MESA or VAAPI is not yet up to snuff, but I'd just call it a beta, add a disclaimer and be done with it.

@kisak-valve Any news on this ?

After over two years with no action on this bug, I've finally gone with the expensive workaround of swapping out my RX480 for an Nvidia card (GTX 2060). I'm now comfortably streaming the Witcher 3 (under Proton) to my Steam Link at 1080p, with the streaming frame rate between 45-60 FPS, and my i5 CPU showing about 30% idle. I would much prefer using an AMD card due to the free drivers, but in this one area it just can't meet my requirements. Hopefully the situation is different by the next time I need to buy or recommend a GPU.

As far as I can tell, even with Nvidia, Steam's in-home streaming still copies each frame from the card over the PCI bus to the CPU, then sends it back to the card for encoding. I.e. the Nvidia technologies which are supposed to avoid this (NVFBC and NVIFR) aren't wired up to Steam on Linux. This suggests to me that there should be no disadvantage to @HorstBaerbel's suggestion of dropping in an older Nvidia card and doing the rendering on the AMD card but the encoding on the Nvidia card. Assuming it works. Sorry, I've already packed up my RX480 to sell, so will not be trying this experiment.

@slouken any update?

@kisak-valve Hi guys, thanks for all your work.

I'm a new AMD GPU owner and would like to know if VAAPI hardware encoding is anything to hope for sooner rather than later?

Oh look now I can remote stream and yet I still can't encode or decode with VAAPI. Hurts performance on both ends.

Seriously, is this never going to be fixed?

I'm fortunate enough as to where I only need video decoding from amdgpu since I'm using a Windows host, and my CPU can easily decode a 1080p stream for now. I'll add myself to the list of people wanting this since it has helped my display latency in the past

Kudos to Valves commitment to OS OSes <3. Why not celebrate that by implementing an VA-API hardware encoding backend? ;P

Very annoying that the do not support this!
Come on Valve!

Pretty please!

Is there an ETA, is it at least on the roadmap? I'd like to get an AMD card for my new build, not least because Valve has done so much work on them (ACO etc.), but I don't want to risk a hit on in-home streaming performance, as I play most games on the projector.

The Android Steamlink App seems to have problems with libx264 encoded streams on certain devices. On my device connected to the TV, I have an unusable experience when streaming from AMD based Linux host using libx264 ("slow decoding" errors). Hardware accelerated h264 or h265 streams are working fine. Thus I would be extremely happy, if Valve could implement VAAPI :)

+1 for VAAPI encoding support

At least support AMF on amdgpu-pro for play games with encoding in linux

So we are few days ahead of the third birthday of this issue, it would be a great gift if we get a fix for hardware encoding in AMD hardware 😃

My CPU is still crying

TFW VA-API is 12 years old, but you backed the wrong horse

I can confirm that sticking in an additional, nvidia-based gpu enables NVENC right out of the box. Quality is awesome and latency seems fine for a phone.

Obviously, I support this issue and would rather not do this... However, this is pretty much the last thing I need Windows for. If I was desperate to make the switch this would be a solution, but I will probably stick with Windows for now as running another gpu seems absurd.

Continue to using Windows as primary desktop by this issue, pls support vaapi on amd encoding.

Any updates on that topic? Hardware encoding works very well as you could see by trying either ffmpeg manually to convert videos or use recent versions of OBS. Quality is fine and CPU load is very low. Any updates on that topic?

For some games my 3570K@4,4Ghz + RX480 8GB is very fine playing directly on the desktop but the performance gets abysmal while using inhome streaming due to missing hw encoding.

PS: Is it possible to use the HD4000 of the processor for encoding and the RX 480 to render the game?

+1 from me too to please support this. OBS, for example, can use the hardware encoder on my RX580 on Linux just fine.

I mean, isn't Steam already using ffmpeg/libav for this? If so, then... How is it much more code than this, for example?
https://github.com/obsproject/obs-studio/blob/master/plugins/obs-ffmpeg/obs-ffmpeg-vaapi.c
Someone, please, just shovel this in there somewhere, and let us be finally happy...
I personally wouldn't even mind if it wouldn't be adaptive, or configurable, or anything like that, I'd like to just have it work in any way at all...

Fun fact: Valve is pushing the FOSS Mesa driver stack for AMD/Intel but does not make us of it's capabilities aka hardware encoding.

Maybe you can snatch some implementation details from Mozilla / Firefox. They finally have decoding running on X11. Yay.

The decoding is already accelerated by VA-API in Steam, as far as I can tell.
But that's only one half (and the less useful one If you ask me) of the story...

The decoding is already accelerated by VA-API in Steam, as far as I can tell.
But that's only one half (and the less useful one If you ask me) of the story...

Yes, I know. It was more of a tounge-in-cheek comment. Else than that it is probably the more useful half, because more people use it.

The decoding is already accelerated by VA-API in Steam, as far as I can tell.
But that's only one half (and the less useful one If you ask me) of the story...

Yes, I know. It was more of a tounge-in-cheek comment. Else than that it is probably the more useful half, because more people use it.

Not sure about the "more useful", since if a system is only decoding it will most likely not be limited by the CPU. If you play a game and encode some stream having 50% CPU usage just for encoding is too much.

This is the only thing keeping me on Windows for my gaming PC. I often stream to my loungeroom tv and my old quad core CPU can't handle it. On Windows my Radeon 7970 handles the encoding and it works perfectly.
Valve, what can we do to help bump up the priority of this? With all of the great Linux work you have done this is a critical feature to overlook for so long

@Plagman

We don't currently support VA-API for encoding, but it's a valid feature request, thanks.

looks around nervously soooo... does this GitHub issue count as said feature request, or is there somewhere more formal that it should be submitted?

Just wanna make sure we're on the same page here.

Make sure you give the first post a thumbs-up.

From the latest beta update:

pressure-vessel: bring host VDPAU and VA-API drivers into the container

pressure-vessel is an opt-in containerization system for Steam games with advantages for host isolation and dependency management.

This must just be for VA-API's decoding features, then?

Yeah, that's just for games running in the Steam Linux Runtime. It's for keeping older games running on modern systems.

I think the biggest problem here, is that libav h264_vaapi encoder does not support the same set of option as the libx264 encoder. It might be extremely tricky to adapt existing code to such a radical change. That being said, I would not expect this to happen at all.

I disagree, but obviously none of us outsiders sees what's really the issue, since all this is closed-source. :)

I disagree

... because?

Stop spamming, you're not helping. If you care about this issue, subscribe and vote with a thumbs up on the first post. This is not a discussion forum, stop the chat.

I have a RX5700XT, and hw encoding still doesn't work. If i enable it in steam, my phone shows nothing but a black screen for a few seconds and exits. Now I'm forced to use cpu encoding, and it hurts a lot when playing proton games.
vote for HW encoding

I have a RX 5500 XT 8GB and hw encoding isn't working for me here, either. It was working fine for some years with the old 2GB NVidia GTX 650 Ti "BOOST" that I was using prior, so I must confess to being greatly disappointed by this as well. So disappointed in fact, that I signed up to github just to report this.

How is 2021 looking for this issue? Is VA-API on the roadmap?

Crazy that they're rolling out new features like remote play together: invite anyone which pretty much requires this bug to be fixed to work properly for many of us, but they do seemingly nothing on this bug and give us radio silence here for literally years now.

Looks like they've been working on using VA-API decoding on Linux clients, I'm really hoping they also are working on the Linux host encoding as well.

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/3050602228716269850

https://www.phoronix.com/scan.php?page=news_item&px=H264-SVC-Mesa-AMD-VCN

Good times to implement AMD linux encoding? :)

The issue was brought up back in 2017 (!). Valve's silence on this deafening. Would it be possible to get at least some form of communication on this issue? I think the most important questions are:

1. Is implementation of this being considered or do we simply have to accept the fact this is never going to be implemented?
2. If the answer to the previous question is yes, what would a rough timeline be? Are we talking months or years? Something else?

Any sort of information regarding this issue would be much appreciated, so we don't have to go by hope.

Yes it would be nice to get some feedback here. Nvidia owners could rely on NVENC since forever for hosting games over steam remoteplay. Not everyone owns a CPU that has the performance needed for hosting a game via steam remoteplay in way that results in a stable performance and decent quality. H.264 encoding is supported by a huge amount of AMD GPU's. Every GPU utilizing the AMDGPU kernelmodule should be able to make use of it. I have used VAAPI encoding for H.264 with OBS and Shotcut for a while now and it works great. Since steam uses ffmpeg just like these two apps, it should be doable with steam remoteplay too.

It is really quite unbelievable that this feature has not been implemented yet. Take a look at https://github.com/loki-47-6F-64/sunshine for example, which makes Gamestream possible via VAAPI for AMD GPUs. With the Steamdeck coming, this issue is probably going to be fixed sooner or later - or should Steam rely on CPU encoding for Valve's own console as well? It makes absolutely no sense to leave this issue open, if only for that.

Statistics show VA-API encoding when connected via the Steam Link app on Android!

EDIT: I solved it, i just had to install the 32 bit version of VAAPI, i forgot that steam needs 32 bit libraries, now it works

streaming_log.txt
Not working for me, running an RX 480 and still getting
"Game Vulkan RGB + libyuv + libx264 main (4 threads)", i enabled hardware encoding in steam settings and made sure VAAPI is installed

Seems to be working here. Ubuntu 21.10 + rx5500xt. Thanks! :)

Thanks everyone!

it's working on Ubuntu 20.04 LTS + RX 470. thank you very much for your hard work!

... btw, is there any way to select GPU for encoding on multiple GPU machine? ;)

PC1

$ lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev cf)
09:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8)
$ ls /dev/dri/
by-path
card0
card1
renderD128
renderD129

PC2

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)
04:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)
06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev cf)
$ ls /dev/dri/
by-path
card0
renderD128

I quickly tested on Fedora 34 with Radeon 580, it seems to be working. Thanks!

Can't seem to get this working on Kubuntu 21.10. Using the latest Steam beta client, Settings > Remote Play > ADVANCED HOST OPTIONS > "Enable hardware encoding" is enabled.

My streaming client is still reporting the encoder as "Desktop OpenGL NV12 + Libx264 main (3 threads)".

lspci | grep VGA:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7)

vainfo:

libva info: VA-API version 1.12.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.12 (libva 2.10.0)
vainfo: Driver version: Mesa Gallium driver 21.2.2 for Radeon RX 580 Series (POLARIS10, DRM 3.41.0, 5.13.0-20-generic, LLVM 12.0.1)
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
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

I also tried setting exporting LIBVA_DRIVER_NAME as "radeonsi" but that did not make a difference.

Thank you @kisak-valve! Really appreciate the quick response and overall support here. I do have i386 mesa packages installed, but I did not have libva2:i386 installed. Once installed, my streams now show "VAAPI H264" for the encoder.

Question to all testers: Does HEVC (H.265) work or is VA-API support limited to H.264 for now? I have only tested against the Steam flatpak and suspect that it might be a limitation (or missing dependency?) there, but am curious what native users are reporting.

Seems to work with the RX 5500 XT 8GB mostly, but the screen occasionally goes black for a moment. Sometimes every few seconds, sometimes it'll go for minutes at a time with no interruption. It seems like maybe the stream is restarting or something, because sometimes when it comes back up it takes a couple moments for it to come up to full encoding quality. Could it be something weird with the 8GB model or do I need to update the Steam Link I'm using to the beta too? Oh, and I noticed the fast/balanced/beautiful selector in Remote Play client settings doesn't do anything either. Not sure if that's related or not. The quality and latency are both good while it's working.

@falk4243 I'm only seeing it come up in H.264 mode but I don't know how to change it for testing anything else.

Kind of works for me on RX 480 showing VAAPI 264.
But it seems, when the GPU load is high, the game freezes (tested with GRIP: Combat Racing (Coop) and Redout: Enhanced Edition (Coop)). Menus worked fine, but shortly after the races started, the game froze. With a bit of waiting the game continued, until it froze again.
Without GPU acceleration it works without problem.
(There was no obvious problem logged in journalctl.)

@Urfoex This is a limitation of VAPPI with that hardware. The encoder will freeze up if the GPU runs out of resources. If the game is running over 60FPS, capping it with something in game or Mangohud can help lower the usage and get a stable stream.

For those running archlinux based systems, other than installing lib32-libva-mesa-driver (in addition to libva-mesa-driver), you also need to run with the native runtime by installing steam-native-runtime and running steam through the steam-native script.

Works like a charm for me now under Arch Linux. VAAPI picks up the Intel GPU on my laptop and uses the hardware H264 encoder there to provide a hugely improved streaming experience! Thanks!

@ieyi4ooPAig1ui5U Very late answer, but you can change the setting client-side on the iOS and the Android Steam Link app. No support for HEVC when streaming from PC to PC (whether Linux or Windows) it seems.

In the meantime, I tinkered a bit more and could only get h264 encoding to work, which is a shame with AMD hardware since their h265 encoding is better by miles and leagues. Streaming with Sunshine instead (which supports HEVC encoding), the difference is like night and day.

Sadly it's still not working for me on Manjaro. Every time I start the stream steam just crashes and restarts.
About my system: Manjaro with Gnome DE, AMD CPU and GPU.

What I've done:

• I have installed libva and and their 32bit counterparts.
• checked vainfo and vdaupinfo
• set environment variables for LIBVA_DRIVER_NAME and VDPAU_DRIVER
• tested it without hardware acceleration to make sure it is HA

Steam itself gives these logs:

Switching video stream from NONE to Desktop_MovieStream
ffmpeg verbose: libva: VA-API version 1.13.0
ffmpeg verbose: libva: User environment variable requested driver 'radeonsi'
ffmpeg verbose: libva: Trying to open /usr/lib32/dri/radeonsi_drv_video.so
ffmpeg verbose: libva: Found init function __vaDriverInit_1_13
ac: Unknown GPU, using 0 for raster_config
CLIENT: Got control packet k_EStreamControlSetTargetBitrate
CLIENT: Got control packet k_EStreamControlSetSpectatorMode
CLIENT: Got control packet k_EStreamControlSetCaptureSize
CLIENT: Got control packet k_EStreamControlSetTitle
CLIENT: Got control packet k_EStreamControlSetIcon
CLIENT: Got control packet k_EStreamControlSetActivity