I'm in favor of going in the direction of this MR for the following reasons:
- We have quite a few bugs in the MF frontend, which directly emerge from us sending decoded samples into it. For example, some games expect the existence of a H264 decoder, in the frontend pipeline, which normally gets inserted during topology (pipeline) resolving, but in Wine, we just skip this and short wire the source to the sink, because why would you want to decode decoded samples again, right? - I think the Gstreamer pipeline should resemble the frontend pipeline closer, even be mostly constructed by us, not by some code which need many workarounds because it really seems like its purpose is for higher level apps, which we aren't. This not only helps us remove more possible failure points but also, makes it much easier to follow what's happening to our data. The frontend already has a pipeline, so why not use it properly?
However, I don't think that is our goal. As I describe below, I think that we need to put a strong weight on preserving decoding support for *all* containers and codecs, not just the ones Windows supports
Why though? Wine is meant to, well, emulate Windows behavior, having additional features is nice, like you've stated in the talk on the Gstreamer conference, but having a feature, which we actually don't need to support and which blocks actual problems, makes me wonder if it's really worth preserving.
The first problem is that we *already* support any format that the host GStreamer supports. Removing that support would be a regression.
Well, it's not, it just removes a feature which shouldn't be there in the first place. If programs need support for exotic formats, they ship decoding DLLs or programs.
So while getting rid of the read thread would make things simpler in some ways, it seems a questionable benefit to me if we can't get rid of it everywhere.
How about handling this on the quartz PE side?
I think wg_transform is a good example of how most of winegstreamer should look like, concise, and only binding to a simple middle- or low-level GST element. IMHO, we also shouldn't do anything apart from video processing in it. (For example networking for Livestream sources, which will be limited by the fact that Windows supports certain features, which GST simply doesn't have or implements completely different and would just be easier done using winhttp/urlmon - plus, it avoids Unix code)