However, the only thing that's been given that it "doesn't need to" be doing is decoding
Functionally, sure, but my impression is that by looping in so many high level g-streamer components, (GstTypeFind, auto-plugging, decodebin in general), we're giving up control on what should be a tightly implemented de-muxing object. So exactly that seems to be the problem: for little funtional benefit (sometimes decoding, no realworld usecase afaik), we have to deal with the slow unwieldy decodebin object. Sure, it could be possible to trim-down the functionality of decodebin to be a demuxer + gst_type_find_helper_for_data_with_extension wrapper, but why, especially when it adds additonal complexity.
I'm starting to feel like I'm repeating myself and not being heard here. I don't know how else to say this.
While I understand and sympathize with this general impression, it's not actually going to help anything. *The complicated parts of wg_parser are not related to decodebin's autoplugging.* The complicated parts are all there for a reason, and that reason does not go away when you replace decodebin with a different element.
The design that I laid out and which is basically implemented now
Sorry if I missed this, but do you mean upstreamed, or is there another MR with this coming?
4592662d4 is the implementation, and 5c24b7e56b5 uses it in DirectShow. Using it in Media Foundation should be similarly trivial.
As far as I looked the current implementation still waits for no-more-pads in parser_connect and has to go through the auto-plugging process.
We will always need to wait for no-more-pads; that's just a consequence of using demuxers that support an arbitrary number of streams.
The current design for outputting compressed samples basically shortcuts the autoplugging process, stopping when we see a known compressed format. Cf. autoplug_continue_cb(). If we're *not* outputting compressed samples, we'll then go ahead and decode that compressed format the rest of the way; cf. stream_decodebin_create() as called from pad_added_cb().
If you mean the possibility for returning compressed types is already there, that still leaves a major benefit of this MR out, which is the speed. Is it still our understanding that in order to accomplish the same speed of this lean wg_source interface, we'd have to introduce a mechanism to restart the pipeline creation process in case an uncompressed type is selected?
Well, most of the slowness is due to autoplugging. By shortcutting the process we'll avoid that. Speeding up typefinding of the source format, which we sometimes already know or have clues towards, will also help. If there's any remaining meaningful difference after that (and I don't remember if there was right now) we should see if that's something we can address in GStreamer before trying to throw anything else out.