In an attempt to simplify the code, this removes the ability to output uncompressed samples—which spans about 70 self-contained lines of code in pad_added()—and replaces it with a whole separate transform per frontend. Why is this an improvement?
It is an improvement because it is how native behaves.
Simply outputting the result of parsebin, with opaque formats, isn't how native behaves either.
The feature is not going to be used by any application and therefore unnecessary.
As shown in 5988, mfplat does not need to use this feature. quartz still does, and wmvcore does too.
Perhaps we should get rid of that in quartz and wmvcore. I would argue that 70 lines of self-contained code is worth it to allow people to play oggs in their Windows media players, but if matching Windows exactly trumps all else, then sure.
Either way, it doesn't justify rewriting and replacing the entirety of wg_parser. If we want to do this, we should just delete the !output_compressed case from the existing wg_parser. That is far, far simpler than any other patch to achieve the same goal.
This removes pull-mode support, which breaks seeking or playback in many demuxers, including demuxers for formats that Windows natively supports.
You've mentioned sfdec and musepack before, these aren't supported by Media Foundation.
Yes. The demuxers I'm referring to are midiparse and avdemux.
Setting aside the above: removing pull mode is done with the express goal of removing the PE-side read thread.
However, removing the read thread can be done without removing support for pull mode, simply by calling wg_parser_get_next_read_offset() from the same thread before pushing.
Decoupling MF from the other frontends makes other things easier to change.
I'm not just concerned about how things are being changed, but also about the end goal here.
Removing the PE-side thread isn't really the goal, making the demuxer calls synchronous is.
What's the point of making the demuxer synchronous as an end goal, if not to remove the extra PE thread?
There's several other reasons to do this, which I've written about in length elsewhere and which I'm not going over again.
I've provided responses to all of those reasons. I haven't heard a compelling reason that we need to make the demuxer synchronous.
Since the plan is to both push and read data from the same thread, how do we make sure we've pushed enough data (to get a sample) without pushing too much (such that pushing blocks due to overflow)?
The answer I've been given is "we always assume that the GStreamer demuxer acts synchronously". This is not guaranteed and may easily be broken by future library changes. The same assumption has already been broken in the transform.
Simplicity cannot come at the cost of removing vital code.
The assumption made for the transform still holds.
Only after disabling a specific GStreamer element that violated it.
Requiring multiple threads to parse a file is even more silly, and it makes our work toward Windows compatibility harder.
It's only a hard requirement because of Wine's unusual architecture.
It's also quite reasonable, actually, because it allows the demuxer to buffer at the same time as individual streams are processing their data.
Also, using a separate thread to read from is *exactly* how DirectShow *and* Media Foundation work, for this very reason. So as long as we're talking about Windows compatibility, this patch series actually makes it worse.
If it ever breaks, we should probably take that opportunity to reconsider the choice of GStreamer as a backend. Maybe I should even start doing that instead of arguing in vain.
If we need a more convenient API, let's talk to GStreamer about creating one. They're really quite amenable to catering to new users.
Does this merge request fix any known application that 5988 does not?