Support YUV 4:4:4 streaming

[ns6089]

Add support for YUV 4:4:4 streaming

moonlight-common-c pull request: moonlight-stream/moonlight-common-c#91 merged
sunshine pull request: LizardByte/Sunshine#2533 draft

Todo, in no particular order:

• Add Vulkan headers to CI environment
  • Probably the easiest way is to add them to moonlight-qt-prebuilts submodule, collected from https://github.com/KhronosGroup/Vulkan-Headers
• Test decoding on intel (i)gpus
• Implement "YUV 4:4:4" option on settings page
  • implemented as dumb switch, no intelligent graying out
• Generate and include missing blobs of encoded video data used in decoder availability auto-detection
  • may want to revise the methodology
• Change plvk renderer heuristics to support 10-bit SDR video decoding on SDR displays, currently it tests for VK_COLOR_SPACE_HDR10_ST2084_EXT and it fails when display is not in HDR mode
  • Removed this check altogether, libplacebo might need some reconfiguration to handle tone mapping gracefully
• Investigate and possibly resolve color conversion errors
  • Full Range had issues on sunshine's side, fixed in the same 4:4:4 PR
  • Rec.601 should never be requested on third-party renderers because it has different primaries from sRGB

[ns6089]

@cgutman I probably can't do more on moonlight side (moonlight-common-c included) without feedback. Format selection logic appears overcomplicated to me, so I've probably missed some corner cases, and you might prefer to do some things differently altogether. Also if you prefer, you can simply take this over after 5.1 is released, this may prevent the needless back-and-forth.

[ns6089]

• switched from fork to official moonlight-common-c submodule
• rebased against 6.0 reverting library updates that got rid of vulkan/libplacebo
• added command line option for YUV 4:4:4
• extended 4:4:4 format selection logic to cover forced codecs

[moi952]

Hi @ns6089, this development is planned to be developed on moonlight-android?

[ns6089]

this development is planned to be developed on moonlight-android?

Not anytime soon, no hardware support.

[ns6089]

• rebased against latest master
• added 2x multiplier to default bitrate when 4:4:4 option is enabled

[Decbuan]

• 根据最新的 master 进行重新定位
• 启用 4:4:4 选项时，默认比特率增加 2 倍乘数

Keep it up! Looking forward to the success of YUV444!! For high-end computer users and those with WiFi 6 or above, we hope for higher bitrate requests and better picture encoding and transmission.

[Decbuan]

• 根据最新的 master 进行重新定位
• 启用 4:4:4 选项时，默认比特率增加 2 倍乘数

I have obtained the version you uploaded on AppVeyor, and I know that this requires support for synchronous encoding by Sunshine, which is not currently in effect. What I want to point out is that when I enable the 444 button, my bitrate can only go up to 114mbps. If 444 is implemented, it shouldn't be limited to this range, right?

[ns6089]

• disabled H.264 4:4:4 for now due to lack of hardware decoders and incomplete (at least to my understanding) software decoding support on plvk backend

[moi952]

@ns6089 Thank you for your work !
I see that the application is not building for Windows, is this normal?

[ns6089]

I see that the application is not building for Windows, is this normal?

The repository with binary dependencies needs to be updated, I'm trying to get this sorted out.

[ns6089]

Can't be done before 6.0.1 hotfix goes live it seems.

[moi952]

Even recovering v6 it doesn't build?

[ns6089]

Even recovering v6 it doesn't build?

If you're trying to build outside of CI on your own computer, this PR currently contains commits that revert binary deps to somewhat functional state. But you also need local vulkan headers, with %VULKAN_SDK% env variable pointing at them. installing SDK from https://vulkan.lunarg.com/sdk/home#windows should be enough.