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.
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? 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. 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?