On the very conceptual level, `decodebin` is a black box meant to create a decoding pipeline. Trying to make it not decode should be a sign that it's not fit. I'm not going to detail the problems once again, you summarized some of them, and I have explained things in length in all the previous discussions.
But we are decoding. We're just decoding to specific formats. Which is exactly what decodebin does; it just decodes to raw formats by default, and we want to not do that, sometimes. It's easy to change the set of formats that decodebin stops at, and Ziqing's patches do exactly that.
Replacing wg_parser makes things easier, because wg_parser is designed around decodebin, and we need a different model. It also allows me to change only one frontend at a time, while keeping it working, as like said, it's going to be a lot of work to make the rest of the playback code work well with encoded buffers, as that use case was never considered before.
I don't understand this at all. wg_parser isn't designed around decodebin, and it never has been. It's designed around a parser, i.e. a demuxer. In fact, from the very beginning it *was* written to support elements other than decodebin, and specifically elements that output uncompressed formats. That's carried over from quartz.
And the support isn't theoretical. There are working applications out there that instantiate a wg_parser containing avidemux, that outputs Cinepak compressed video. Or a wg_parser containing mpegaudioparser, that outputs MPEG-1 compressed audio.
Nor do I see any way in which the wg_parser interface, or even its implementation, is incapable of doing these things. In fact, having written the support to actually *do* it, the only thing it has required is adding another format to wg_format, and filling everything that switches based on format. And the only awkward thing about that has been trying to determine a maximum sample size.
We could even take this approach for new formats—that is, add new members to enum wg_parser_type. I'm not convinced we want to, because there are some drawbacks to it (which I can go into if it'd help), and I think Ziqing's approach is generally better. But it should go to show that it's not obvious that there are any problems with the wg_parser API. If you see any problems with wg_parser, can you please share them?
The objections you've shared have been predominantly along the lines of "X is designed to do Y; we want to do Z instead". And I don't think these objections are specious in principle, largely because I've had similar objections myself; I have often looked at code and found it ugly simply based on high-level design and intention. If this is your only problem with wg_parser and decodebin, I hope I can explain to you my perspective, and why I think that outputting compressed samples, or speeding up instantiation, or providing a specific stream order, is actually perfectly within the design of these APIs.
As an extra note, changing one frontend at a time is a nice bonus, *if* we're going to introduce a new API. But it's not clear at all to me why we do want to introduce a new API.
As a last comment, in general I think we should stop relying on the higher level GStreamer elements. To the contrary to Wine, we don't own its code, and anything complex is likely going to be bogus. Fixing bug in this case is more difficult as it would need to be upstreamed first and then we'd have to wait for it to trickle down.
I understand being frustrated with upstream libraries, and I gather you've had some poor experiences with libraries, but I don't think that this is the right answer. Without getting too philosophical, working in an ecosystem with libraries is something that benefits the entire ecosystem, not just one project. Giving up on libraries, and implementing everything oneself, is bad for Free Software, and quite often results in unmaintainable code. Slower publication of features or bug fixes is a cost of this, but it's a cost well worth paying.
From a less philosophical viewpoint, there may be questions of scope when it comes to specific features. The one that's been mentioned here is the ability to get a file stream order from demuxer elements. I think it's not obvious that this is outside of GStreamer's scope—not least because there's no way for us to get that information without leaning on internals—but discussion with GStreamer developers may lead to the conclusion that it is outside their scope, and if so, we'll do what we can.