16:10 green Bar on right side

[skunk-funk]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your issue described in the documentation?

• [ ] I have read the documentation

Is your issue present in the latest beta/pre-release?

• [ ] This issue is present in the latest pre-release

Describe the Bug

When streaming a 16:10 host to a 16:10 client, sunshine does not send the full screen and puts a thick green Bar about the right-hand side of the client. Have tried at various resolutions and various clients and several sunshine versions.

Expected Behavior

No response

Additional Context

No response

Host Operating System

Linux

Operating System Version

Ubuntu 22.04

Architecture

32 bit

Sunshine commit or version

23

Package

Linux - deb

GPU Type

AMD

GPU Model

Rx 580

GPU Driver/Mesa Version

whatever's in 22.04

Capture Method (Linux Only)

pipewire

Config

output_name = 0
channels = 5
adapter_name = /dev/dri/renderD128

Apps

No response

Relevant log output

None

[phamaralbr]

I have the same problem. Seems like it's a problem with ffmpeg. An easy workaround for now would be using H264 instead of HVEC.

[skunk-funk]

Should this be an issue in ffmpeg instead?

I don't have the chops to translate this to that world.

[gschintgen]

Thanks for reporting the issue. I don't think the architecture is 32-bit and I highly doubt the capture method is the (unreleased) pipewire capture method. Logs are always appreciated even if nothing is "relevant" in an obvious way.

That being said it's a known issue with AMD cards: The h265 encoder works in blocks of 64x16 pixels. This clashes with Apple's vendor-specific resolutions (other resolutions may also be affected). Unfortunately those non-aligned resolutions aren't handled correctly by mesa / ffmpeg. There's a comment on stackexchange detailing what needs to be done (in general) to get this fixed:

1. On the mesa / radeonsi / libva side of things the API is been enhanced to provide a means so that drivers can inform other layers of the stack of the pixel alignment required by the hardware. Apparently this should be ok with recent mesa versions.
2. On the ffmpeg side these alignment values must be retrieved and handled correctly.

Sunshine uses its own ffmpeg build as a build dependency. This ffmpeg is built (on purpose, for compatibility reasons) against a rather old libva version. Consequently the ffmpeg patch that is available can't work correctly. But we have confirmation that hardcoding the required alignment values in sunshine's ffmpeg copy does indeed fix the issue (if the rest of the host system is recent enough).

One possible solution might be to modify the ffmpeg patch so that it does not try to retrieve the correct alignment values from libva but to "simply"(?) check if the GPU vendor is AMD and use the 64 by 16 alignment in that case. (It would probably still require up-to-date libva/mesa on the host system, since other alignment/padding related changes have also been made.)

An alternative could be to investigate the possibility of using a patched ffmpeg in the AppImage since that build is more self-contained and uses an up-to-date libva.

PRs are welcome :-)

[gschintgen]

Note also that on the screenshot there is not only a green bar to the right but also a small black bar at the bottom. Probably 8 pixels to make it a multiple of 16.

I recently streamed h265 to an older 1600x900 laptop (software decoding) and there was also a small black bar at the bottom and the image was a bit blurry since moonlight scaled it down to fit the screen. (Must have been 912 rows instead of 900.)

It may be this issue on ffmpeg's bug tracker: https://trac.ffmpeg.org/ticket/8506 We should probably build the latest ffmpeg from source and report the findings upstream if it's still reproducible from the CLI.

It's peculiar though that I can't seem to remember moonlight ever reporting 1088 for FullHD in its overlay, but for the 1600x900 case it did indeed report a larger row number. (More testing needed, as always...)

[matte-schwartz]

Note also that on the screenshot there is not only a green bar to the right but also a small black bar at the bottom. Probably 8 pixels to make it a multiple of 16.

I recently streamed h265 to an older 1600x900 laptop (software decoding) and there was also a small black bar at the bottom and the image was a bit blurry since moonlight scaled it down to fit the screen. (Must have been 912 rows instead of 900.)

It may be this issue on ffmpeg's bug tracker: https://trac.ffmpeg.org/ticket/8506 We should probably build the latest ffmpeg from source and report the findings upstream if it's still reproducible from the CLI.

So my findings when working off of that bug report ticket are as follows:

Without the patch, my results match up perfectly with the original issue and misaligned video sizes.

With this patch: https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]/ applied on top release/6.1 (it doesn't apply cleanly to ffmpeg-git anymore), my output video size is the proper 1920x1080 using the exact same commands as before the patch so it no longer matches the issue report. The size is also accurate for 1600x900 and 3440x1440 videos.

May take me a bit to figure out how to test this within Sunshine so we can know for sure whether the patch does or does not work.

I was not aware of this thread before filing this Mesa bug, but I've kept it open for now since that's the best way I've found around this issue on my own 7900xtx setup: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11491

[cordlord]

I have the same problem. Seems like it's a problem with ffmpeg. An easy workaround for now would be using H264 instead of HVEC.

Just to chime in as I had this issue today, disabling HVEC support fixed this immediately for me on version 0.23.1.

I'm running Ubuntu 24.04, with kernel 6.8 CPU is AMD Ryzen 7 5700U (16) @ 4.37 GHz GPU is AMD Lucienne [Integrated]

[phamaralbr]

Seems like a fix was merged but unfortunately the issue still persists for me.

As you can see there is still a green bar on the right side of the screen while using HEVC:

I'm on the latest sunshine pre-release: Version v2024.1005.14704

[matte-schwartz]

The fix technically does work, but because of the way build-deps get created in the CI, it uses libraries that are too out-of-date when building ffmpeg for Sunshine specifically. Should hopefully be fixed if/when the way build-deps get compiled changes.

[phamaralbr]

Would it be too difficult to apply this patch ourselves until this is fixed?

[ReenigneArcher]

This should be merged soonish https://github.com/LizardByte/Sunshine/pull/3263

[matte-schwartz]

@ReenigneArcher is the runner also getting changed with this? otherwise I'm worried it'll have the exact same issue. I remember when making my .spec package, I had to recompile the build-deps individually on my own Fedora system and then put them in that tarball to use during the build rather than the CI artifacts because Ubuntu LTS did not ship one/multiple libraries in the build-deps runner.

[ReenigneArcher]

Oh... I understand your statement now. The runner did not change. We're building on ubuntu 22.04 for now.

[cgutman]

Don't we actually need to set log2_alignment on our side for the FFmpeg patch to have any effect?

[matte-schwartz]

I had a fully working build without patching sunshine and just using the rebuilt build-deps with the existing patches.

[2024:07:12:18:23:01]: Debug: [hevc_vaapi @ 0x34dc09c0] Using customized alignment size [64x16].

https://discord.com/channels/804382334370578482/1246074499234009148/1261493805522354196

[cgutman]

Ah yes, I missed that hwcontext_vaapi sets it.

[cgutman]

@matte-schwartz Can you try with the build-deps from this run? https://github.com/LizardByte/build-deps/actions/runs/11209095043?pr=363

[matte-schwartz]

@cgutman looks good on my end with that run, just dropped the Linux-x86_64 folder into place of the included one and re-compiled on Arch, no green line is present and logging looks good.

2024-10-06 23:21:34.214]: Info: vaapi vendor: Mesa Gallium driver 24.3.0-devel for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.12.0-rc1-5-cachyos-rc-lto-test)
[2024-10-06 23:21:34.214]: Debug: [AVHWDeviceContext @ 0x7552e0b5b0c0] VAAPI driver: Mesa Gallium driver 24.3.0-devel for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.12.0-rc1-5-cachyos-rc-lto-test).
[2024-10-06 23:21:34.214]: Debug: [AVHWDeviceContext @ 0x7552e0b5b0c0] Driver not found in known nonstandard list, using standard behaviour.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Input surface format is p010le.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using VAAPI profile VAProfileHEVCMain10 (18).
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using VAAPI entrypoint VAEntrypointEncSlice (6).
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using VAAPI render target format YUV420_10 (0x100).
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using CTU size 64x64, min CB size 8x8.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] RC mode: CBR.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Block Level bitrate control: OFF.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] RC target: 100% of 30988000 bps over 8 ms.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] RC buffer: 258233 bits, initial fullness 193674 bits.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] RC framerate: 120/1 (120.00 fps).
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Driver does not report any additional prediction constraints.
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using intra and P-frames (supported references: 1 / 0).
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] All wanted packed headers available (wanted 0xd, found 0x1f).
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using customized alignment size [64x16].
[2024-10-06 23:21:34.214]: Debug: [hevc_vaapi @ 0x7552e0baeec0] Using level 5.1.

some additional validation from others would be good just in case

[gschintgen]

some additional validation from others would be good just in case

I'm a bit out of the loop here since I didn't use Sunshine for a few months but I know I even helped with the initial investigation of this issue.

Anyway, I currently have incoming HEVC streams with a resolution of 1920x1088 instead of the expected 1080 (as per the 1st line of Moonlight's OSD). Consequently everything is a bit blurry client-side due to the necessary scaling. Also on my older Intel-based Mini PC Moonlight no longer can keep up with 120fps rendering, possible due to the additional scaling step (decoding is still fine at 120Hz). Due to my prolonged hiatus (and all of the fiddling around that I did previously) I can't state with absolute certainty that this behaviour is a regression but I do think it's possible. The blurriness when using Sunshine as remote-desktop is quite obvious. And I often had the stats screen open with the stream's resolution in plain sight. (Then again, I also used x264 sometimes since h264 on AMD always led to strange artifacts after some time.)

I guess my question is: Is it sufficient to have an up-to-date sunshine or does the fix depend on various other parts of the system?

The host is running Ubuntu 24.04 (mostly defaults, except for kisak-mesa) and Sunshine v2025.122.141614 (the .deb from github). The GPU is an AMD RX6650. The issue is present when streaming HEVC. (I can't say for h264.) I don't think the clients matter much (1x notebook on Arch, 1x mini PC on Ubuntu 24.04, both with Intel iGPU, the notebook receives a 10bit stream, the mini PC 8bit.)

(Time permitting I might try older Sunshine versions, as long as they are compatible with 24.04... But previously I was on 22.04 so a lot of libraries have changed as well. And also the Moonlight versions changed.)

[ReenigneArcher]

@gschintgen see https://discord.com/channels/804382334370578482/1313221611381325844