16:10 green Bar on right side

[skunk-funk]

Is there an existing issue for this?

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