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 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.)
Perhaps more importantly, I've been trying to communicate why decodebin's design makes sense for what we want to do in Wine. The name is only one part of that. The fact that the API for decodebin explicitly has support for stopping at a compressed format suggests to me that outputting compressed formats is completely in line with what decodebin is designed to do.
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),
I've heard mention several times of "threading issues" or "concurrency issues", but I haven't yet heard an explanation of what these issues are. Can you please explain what threading problems decodebin has?
Perhaps more importantly, though, I'm afraid that getting rid of the read thread isn't as simple as avoiding decodebin. In fact, there is no code in decodebin that cares at all about scheduling modes. Rather, that's something that individual demuxers and parsers care about.
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). And that's just elements shipped with GStreamer. A notable feature of the library is its extensibility (which is not just theoretical!), and removing pull support could cripple any number of unknown elements.
And, even if they are functional, I think few if any demuxers are going to be efficient, and likely cannot seek very accurately. [1]
That aside, while our need to support pull mode unquestionably makes the code more complex, I'm not aware of any actual bugs that result from it, or design problems. Can you please clarify what problem you're encountering with pull mode? 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.
[1] Some formats can also put vital metadata at the end of the file. I am aware of one such format that I have seen this happen in practice with, namely QuickTime / MPEG-4. I don't know how GStreamer's qtdemux (or any other elements) deal with this. Do they buffer the entire file? Seek? Neither one is ideal.
and requires to use pthread condition variables which are broken in Wine.
Can you please clarify this statement? In what way are condition variables broken in Wine?
I'm aware that if a thread is terminated while waiting on a condition variable, it will fail quite noisily [2]. I assume this isn't what you mean, though, since a terminated thread doesn't have particularly defined behaviour anyway, and simply printing a few more messages to the terminal before exiting does not seem to be causing any real harm—hence there is not really anything "broken" about condition variables. Perhaps I am wrong about this? Or do you indeed mean some other problem?
[2] https://bugs.winehq.org/show_bug.cgi?id=52213
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.
Sure, and I'm not by any means arguing that any given feature *should* be implemented in GStreamer just because it can. Nor am I taking it as a given that the feature that has been mentioned (file stream order) will be considered by the GStreamer developers to be within its scope. But, like I was saying, I think it very well may be within GStreamer's scope, and if it is, then we should delegate it to GStreamer.
Fundamentally, if I encounter a piece of code that requires us to completely rewrite the way we do something in Wine, but would require a lot less from GStreamer, I'm going to naturally ask myself if that something should be GStreamer's responsibility. Cases like this seem like the opposite of shoehorning.
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?