But we are decoding. We're just decoding to specific formats.
We don't want to decode. There's a similar black box element for demuxing only, `parsebin`, which is another hint that `decodebin` should not be used if you don't want to decode. Though `parsebin` suffers from the same issues than `decodebin` and isn't usable for our specific use case.
I don't understand this at all. wg_parser isn't designed around decodebin, and it never has been.
Sure, there are indeed other uses of wg_parser with simple demuxers elements. However, the complexity of the `wg_parser` code is only there because of `decodebin`, because it is best used in pull mode and because it is inherently multi-threaded. It could be much simpler if `decodebin` was not supported.
If you see any problems with wg_parser, can you please share them?
It is (IMHO) unnecessarily complex for a simple demuxing task, requires a separate read thread (which is the main reason it is so complex and prone to concurrency issues), and requires to use pthread condition variables which are broken in Wine.
It is also unable to do typefinding only (which this MR does, though arguably this could be added), to later decide what kind of demuxing element needs to be created.
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.
GStreamer is not meant to implement Windows behavior, Wine is. If GStreamer can be used to implement Windows behavior, great, and fact is, it probably can. It provides enough flexibility to let us decide which pieces to use and we should use the smaller ones as they are more easily combined, not the bigger piece that we have to shoehorn in place.