Stream quality regression VAAPI Radeon Linux #2864
Comments
|
Working as intended now I'm afraid. The whole point of #2821 was putting bitrate back under control since it was overshooting through the roof. I guess someone can look into extending the NVENC option below into other encoders, but I have absolutely no idea how well it will work for AMD cards, especially through VAAPI. |
|
@ns6089 so this option is not supported by vaapi, is it? |
|
VAAPI can support |
|
I can confirm the strong quality regression. For the last two days I was puzzled why I didn't notice earlier the very mushy blurry forests I was speeding through in Forza Horizon 4. At some point it was really bad and I couldn't clearly make out where I was supposed to head to. At first I thought it was related to the graphical characteristics of the landscape I was driving through or that I wasn't yet accustomed to the stream quality in a game with more realistic graphics (compared to the more artsy styles of the previous games I played.) But I've now compiled sunshine from the very last commit before the AMD bitrate fixes (#2821) were merged and test-drove that build for some 75 minutes. The graphics were gorgeous as ever; like sitting in front of the host PC. I do acknowledge that some people had actual issues with the occasional overly large frames (even going as far as having the stream break down) and I'm very grateful that this issue has been looked into! And fixed. But now the streaming is very degraded for other users as it seems. That's obviously an unfortunate situation. I also admit that my latest "gorgeous" streaming session resulted in the following log excerpt: My point is: I didn't even notice anything special (maybe a few small stutters in an hour long session). So at least for my use case the cure is worse than the disease. This is all with Moonlight configured for 1080p with 60Mbps. The host has an AMD RX6650XT. (Everything wired) Would it be possible to make the buffer limiting optional via the Web UI? (For the time being, or before the next stable release if nothing else changes until then.) I'll gladly help play-testing any potential proof-of-concept patch or PR etc. |
|
Is it possible that changes to ffmpeg are causing this? This was merged 2 days ago: #2843 That update included a vaapi patch to ffmpeg, via LizardByte/build-deps#335 |
|
I can try |
Very unlikely
Looking at ffmpeg code, the initialization process fails when there is no support on the backend. |
|
Also had to revert my sunshine too, RX550 here, and the regression indeed makes sunshine unusable, very blocky and unreadable. Thanks for the commit reference by @neatnoise. For those wanting to revert, the magic commit to checkout was at 5cea1e1 for me. Was a little tricky as I'm on arch (btw), had to grab an older boost-libs, luckily had a copy in my cache at v1.83.0-9.1 which allowed me to compile, that was the only dep change I had to make. To get a successful build, I did disable the docs and tests targets as it still wasn't the right boost-libs to get past all the tests and the docs had references to assets that no longer exist on lizardbyte's servers (logo svgs). Don't forget to reinit your submodules after checking out. |
|
@garza-utsa I have to agree with you unfortunately. In my opinion network little spikes are better option instead of large quality regression. I don't have to downgrade boost libs in my up to date arch system to compile it. I apply this patch in every dev build: |
|
It appears I've opened the same issue here - #3181 Not sure how to consolidate these. I will say, for some reason on intel iGPU this isn't an issue - so if you have an intel processor, use it to get around this! The situation is really making this thing unusable. |
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
I regularly update master git version of sunshine. The latest updates (probably this 38c13c8 ) introduced stream quality regression for VAAPI encoding (RX 580 GPU). The visual quality is much worse. The changed pixels update to achive good visual quality like with 1 second delay. At 25 Mb/s bitrate 1080p 60fps it shows very noticeable compression effects, it stutters, it looks like 5 Mbit bitrate before updates.
Expected Behavior
Nice looking stream at 25 Mbit
Additional Context
No response
Host Operating System
Linux
Operating System Version
Arch linux latest
Architecture
64 bit
Sunshine commit or version
sunshine-git-2024.713.205505.r0.g18e7dfb-1-x86_64.pkg.tar.zst
Package
Linux - AUR (Third Party)
GPU Type
AMD
GPU Model
RX 580
GPU Driver/Mesa Version
latest mesa-git
Capture Method
KMX (Linux)
Config
wan_encryption_mode = 2 cert = x pkey = x output_name = 0 amd_quality = default external_ip = x nv_rc = auto channels = 3 address_family = both resolutions = [ 1280x720, 1920x1080 ] upnp = enabled nv_preset = default fps = [60] qp = -1 encoder = vaapi lan_encryption_mode = 2 amd_rc = auto file_state = xApps
All, desktopRelevant log output
The text was updated successfully, but these errors were encountered: