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/20240321170219.1487-1-Primeadvice@gmail.com/ 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]