I'm asking because my proposal *also* involves making the media source into a "simple demuxer", i.e. outputting compressed formats for applications that care. The language you're using makes me think there's some misunderstanding between us. From my reading, you (and others) seem to *still* be under the impression that I don't want the media source to output compressed formats, despite me trying to state the contrary many times. Let me say it again: yes, I want the media source to output compressed formats, in (at least) all the cases that applications care about.
The only difference I'm trying to discuss here is whether to output compressed formats based on where the element appears to be in the GStreamer pipeline, or based on whether it's a compressed format we know of and know that Windows recognizes. I'm proposing the latter, which is what we already do for the other frontends. That solution addresses points 2, 3, 4, does not need to worry about point 7, and does not preclude independently addressing points 1, 5, and 6. There is more than one way to skin a cat.
Moreover, we already have all the infrastructure in place for it. All we need to do is add missing mappings to mf_media_type_from_wg_format(), and then flip the wg_parser_create(false) to wg_parser_create(true). Am I missing something?
There is a bit of a separate question as to whether we even want to output compressed formats for caps that aren't natively supported on Windows. I would assert that there's no need to. I suspect you see a need to, although I'm not sure what that need is, since no application can possibly depend on them. [Consider that any such application would also be broken for e.g. an uncompressed AVI file—it's not actually true that a demuxer "never outputs uncompressed formats".] I'm not necessarily opposed to it either, but I don't think I see the point of if it doesn't save us any work—and as far as I can tell it doesn't. Like I said, we already have all the infrastructure in place to do it the incremental way; we need the GStreamer -> mfplat compressed media type mappings anyway, and the rest is just a matter of flipping a flag.
To make it abundantly clear, this is not me trying to reject 5615 wholesale, or even any of its constitutent parts; I'm not necessarily opposed to any of them (and I'm still trying to evaluate some of them), but I don't see why any of that is a *requirement* for outputting compressed formats. We already have a way to output compressed formats that requires no extra work.