Here's what the video looks like in DXVK v1.7.1.

So it uses the format YV12 in the WineD3D trace, however we don't support that so it tries to use YUY2 in the DXVK trace.

It seems the YUY2 data that gets uploaded is garbage, same with how it is when replaying the trace on native for me.
Maybe this is a problem in Wine's quartz impl that needs to be looked into, or the game doing something wrong?

Anyway, I've implemented YV12. Please let me know if this works on your end.

Thanks. I built that branch (v1.7.1-2-g7e0bb971). The ConvertFormat warning is gone and the video no longer flickers, however the colors are incorrect and the game's main menu still does not render.

@aeikum Is there anything special I need to do to get the video to play?

I tried in proton_5.0-next and it just skipped over the video and went straight to the main menu (which worked) for me.

So, the main menu worked before the video thing worked.

The problem is you're creating multiple swapchains/surfaces for a window, this is a big no-no in Vulkan, but it should be possible to fix.

Hm, perhaps not. This is happening on another d3d9 instance and another d3d9 device.

The primary vulkan swapchain from the game still thinks everything is okay and it can present and even returns VK_SUCCESS.

I'm not super sure what to do about that given I have 0 information... :-/

Anyway, I fixed the YV12 rendering at least. I'll need to have a think about the swapchain dilemma, I'm not sure if this is something I can work around, or if I can work around it in Wine or maybe the driver is wrong for thinking everything is okay.

Just curious, any further thoughts on this? Do we know where the problem is?

@Joshua-Ashton

I have tested this on Windows with DXVK and it works fine there.

On Windows in D3D9, you can have multiple swapchains on the same window.

The problem is that technically this is illegal in the Vulkan spec -- but it seems to just work on Windows too?

__
In WineX11, I would recommend wrapping the swapchain object, tracking ownership of swapchain->window, and make sure whoeever wants to present at a given time has the ownership. If they don't currently own the swapchain, return VK_OUT_OF_DATE_KHR on present and make them re-make the swapchain (and therefore update the ownership) when that happens.

Whoever creates a swapchain for a window last should be the "owner".

We should eventually write a VALVE extension that we enable all the time to make things spec-positive here. I can take that part once we know this works.

Another game that needs YUY2 in d3d9 path is Mary Skelter: Nightmares. It's using mediafoundation for intro video, with EVR renderer, that goes through dxva2. YUY2 is a main planar format there as I understand, at least for software devices. Winegstreamer is already able to output in YUY2, but that needs a hack to trigger + some smaller patches that are waiting to be included for mainline wine. Let me know if there is interest to test this, I can provide more info then.

As we're getting more videos online, we're running into this problem more often. Any hope of a workaround?

Rémi actually had some fixes for this in one of his trees. We've backported his work to 6.3 and it fixes AOE2 and some other affected games. It works by allowing multiple surfaces & swapchains per window, and rendering offscreen if multiple surfaces are active.

I've pushed this to my repo and it'll be in Experimental soon: https://github.com/aeikum/wine/commit/08db7c206acb691a3f9eb94c46cc3d3342c06a88