I think you're taking "decode" in the wrong sense. The way I'm using the term, and I think the use in the name "decodebin", is not meant to be opposed with "demux", but rather with "encode". (I also don't think contrasting decodebin with parsebin in that way makes much sense, since decodebin does everything that parsebin does.)
I'm taking it in the GStreamer sense. "parsebin unpacks the contents of the input stream to the level of parsed elementary streams, **but unlike decodebin it doesn't connect decoder elements**."
If decodebin was meant to be used like that there would be no need for them to offer a separate parsebin.
By the way, I asked earlier in the thread, but I don't think I got an answer: what part(s) of the current code cause wg_parser initialization to be too slow? What are the bottlenecks, so to speak?
I already detailed this previously, but basically everything about it. Its more complicated initialization, pull mode which triggers a very different typefind pattern with a lot of unnecessary reads, auto-plugging which needs to lookup decoders, prerolling.
I'd also like to know how you intend to deal with seeking in a way that avoids this problem, whatever it is; if the problem inheres to having an extra thread (as you seem to suggest) then I believe that the need for seeking will mean that that thread can't just be removed even if we *were* to stop supporting pull mode.
Nothing in seeking support mandates an extra thread. The demuxer sends seek events to the source pad when pushing buffers, and expects the next buffer to be read from the desired offset.
And unfortunately, we can't just get rid of pull mode. While many demuxers and parsers for common formats shipped with GStreamer support push mode, as of 1.20 some do not (sfdec, musepackdec); some support push mode but cannot seek (rmdemux, midiparse, modplug, and any libav-based demuxer), and some support push mode but at the expense of some features (mxfdemux at least, and possibly others).
I suggest we start by implementing the natively supported formats, which applications are using, the right way before worrying about more exotic formats. If these demuxers don't support push mode I'd say it's a bug on their side, and I would agree that *this* is worth trying to fix upstream. Most of these are in the Bad or Ugly plugins, which probably means they aren't very good quality.