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?
As I've tried to explain multiple times (e.g. the first three paragraphs of my first response to this patch series), I am not arguing against decoded sample output. I simply don't think it's necessary to rewrite all (or even any) of the winegstreamer glue to do it, especially not from scratch.
In fact, we already have an internal API for compressed sample output, and we use it in the quartz and wmvcore frontends. It should be quite easy to add that to mfplat as well.
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.
It's not blocking anything. The design that I laid out and which is basically implemented now allows us to output known compressed formats while letting unknown formats still get decompressed to raw. This means that applications which care will get their expected compressed formats, whereas applications which accept arbitrary files can still interpret them.
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?
Well, as I said, I'm not rejecting that design with prejudice, but I'm not convinced it'll be an improvement either.
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)
This is the same high-level perception that's been repeated multiple times over the course of this conversation. As I've said, I understand how wg_parser seems like a large and complex piece of code, and I understand how it seems like it's doing more than it needs to. However, the only thing that's been given that it "doesn't need to" be doing is decoding (viz. in addition to demuxing), and even setting aside whether it's *actually* unnecessary, removing that feature from wg_parser improves very little.
As I've stated, almost all of the complexity of wg_parser (including pull mode) really inheres to the *parser* side of things, and it needs to be there. The logic to handle specific output formats is quite possibly the smallest part of it. It may seem that the existence of this patch series contradicts this statement, but this patch series is cutting out (by rewriting) parts of wg_parser that are there for a reason.