I think the best way to deal with that would either be to skip adding the preferred format to the list if it's UNKNOWN, or to add a WG_VIDEO_FORMAT_I420_10LE which is translated to P010 in wg_parser_get_preferred_format
I would prefer to keep adding the preferred option (i.e. translate to P010) as this more closely matches Windows behavior (and who knows, some day we may find an application dependent on it).
I don't see how? I'm talking about internals here. Translating I420_10LE to P010 in wg_parser_get_preferred_format() would achieve the same thing on the win32 side, just in a more declarative way.
It sounds like we want to distinguish between the preferred and current formats. So I guess on the unix side, we want to record the format from the decoder and then we would translate that to a supported Windows format GUID and supply that as the _preferred_ format on the DLL side (which up until now has been one-to-one between `GST_VIDEO_FORMAT` and GUID).
Sure. To be clear, "preferred format" is exclusively a winegstreamer concept, not a win32 concept nor a GStreamer concept. It's just the format that GStreamer outputs as a first choice, so we assume it's a format that will require no extra conversion between raw formats, so it's the format we prefer to output if we have the choice. That just means it's the format we enumerate first in win32. In DirectShow, at least, this usually works since applications are less picky about the formats we offer by default. In Media Foundation the same is probably true in general, but unfortunately applications are more inclined to make assumptions and so it's not really a viable strategy.
I also want to understand the role of the `WG_VIDEO_FORMAT` defines. Initially I thought it might be so we didn't need to include the GUIDs on the unix side, but I see we map directly from `GST_VIDEO_FORMAT` to GUID in `subtype_from_gst_video_format`. So I figured maybe it might be for mapping `GST_VIDEO_FORMAT` to a supported `WG_VIDEO_FORMAT`, so that `WG_VIDEO_FORMAT` could then be mapped one-to-one with a Windows GUID. It was this thought that prompted me to map it in `wg_video_format_from_gst`. But it sounds like we want to maintain a one-to-one relationship between `GST_VIDEO_FORMAT` and `WG_VIDEO_FORMAT`; so now I'm not sure of the `WG_VIDEO_FORMAT` defines purpose.
There are a couple reasons that I didn't use GUIDs and still wouldn't change the code to use them:
* wg_* was meant to be a neutral API between the frontends (then quartz and mfplat, and now also wmvcore). mfplat and quartz do not actually use the same GUIDs for video or audio types.
* Moreover, I don't believe that either mfplat or quartz's set actually has all of the formats needed by the other.
* A simple enumeration is just easier to deal with anyway, e.g. it can be switched over.
Under Wine (when using a winegstreamer source), we don't use an MFT to decode, that is done by the media source.
This is pretty much the problem, and it needs to be changed. This is what winedmo does already and I have no objection to make the winegstreamer media source do the same.
Well, I tried...