ns6089

@mohemohe Much appreciated, there was a redundant check that I missed. Pushed the fix, new CI builds should be ready shortly.

Hmm, it appears we send the right surfaces but then ffmpeg misconfigures the encoder and internal conversion happens. This one is going to be tougher....

@mohemohe I tried to nudge quicksync in the right direction, CI builds are up. If it doesn't work we will have to patch ffmpeg 😞

That's a bummer, but in this case I'm not sure what we can even do with the degree of QSV functionality that ffmpeg exposes. What we need is [MFXVideoENCODE_Query()](https://intel.github.io/libvpl/latest/API_ref/VPL_func_vid_encode.html#id1) >...

I guess we can simply blacklist h.264 and av1 4:4:4 for qsv bypassing ffmpeg entirely, should be enough for a while.

Either way, let's go ahead and merge this in its current state. I will add h.264/av1 blacklist shortly after.

@cgutman Something like this https://github.com/LizardByte/Sunshine/pull/3029 https://github.com/LizardByte/Sunshine/pull/3029/commits/6488a2c323dcd11b13f25a8dabb71dbe0d07fc04

@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...

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

> this development is planned to be developed on moonlight-android? Not anytime soon, no hardware support.