Ah! Thanks, that's interesting. So it looks like autoplugging is the big problem. I'm a bit confused about "no-more-pads", since at least here, decodebin will actually emit no-more-pads before resolving the state change, but maybe that's different in different versions? Or did you mean prerolling?
I actually meant the part after the state change, where we wait for no-more-pads and for the stream duration. So that probably involves some prerolling yes.
How do you push data after initialization, i.e. while streaming?
The same way. Get the read position, read and push data until we get the samples we want. We don't need a thread here, especially not in MF case where everything is or can be done asynchronously already, including the reads.
Ah, sure, but we also don't *need* to autoplug immediately. I don't know if I described this idea before, but what we can do is defer stream autoplugging to later. This should be quite simple, just a matter of moving some code from pad_added_cb() to a function lazily called by wg_parser_stream_enable() or wg_parser_stream_get_preferred_format() [I think those are the only places that matter].
More importantly, though, if we're going to be outputting compressed formats for those videos that need fast media source initialization, then we don't even need to worry about autoplugging overhead, because we won't need to autoplug. Currently we do anyway, in order to support toggling at runtime between encoded and unencoded video, but I have my doubts about the utility of that feature.
We still need it because we put everything in the same pipeline. Building the pipeline lazily by adding some decoding elements later will require it to be stopped and started again. This adds even more complexity to wg_parser only for the purpose of making it optionally do something simpler. Instead, we should do always something simple, by decoupling the demuxing from the decoding, like it's also supposed to be.
Sure, that's understandable. But the right thing to do isn't always the least risky thing to do. I think in this case the right thing to do is keep the wg_parser interface, making incremental changes to it and its backends if necessary.
I'm not saying that the wg_parser interface is perfect and doesn't need changes, far from it. There are things I don't like about it currently, though I haven't yet come up with a satisfactory way to improve them. But those changes can be done without rewriting the whole thing.
Maybe it's not satisfactory because it tries to do everything at the same time. I don't think that's a good idea, and instead we should compose simple elements together. For MF, the composition is already done on the PE side because we needed it, so now it's just a matter of implementing the simple demuxer element.