5988 achieves deterministic ordering according to my testing.
I don't know, maybe it does now. Who knows what GStreamer does here anyway, it could very well use threads, or not.
decodebin explicitly exposes pads in a certain order. The only thing preventing that from working in Wine was the appended decoders. So yes, we know what GStreamer does here. GStreamer is making this guarantee just as much as ffmpeg is.
Which deadlocks?
Please, come on, people report them from time to time on IRC, and not so long ago you were even asking them for details...
I'm trying to ask for details because I've seen two reported deadlocks, both of which were application bugs, and according to my analyses, changing the threads we make those requests from isn't actually going to fix anything.
Rewriting an entire component is a waste of time if we don't fully understand a deadlock and why Windows avoids it, and why we can be sure we will also avoid it.
And, again, we *can* change the threads we make read requests from without needing to rewrite anything. You *can* handle pending read requests from the same thread that you call wg_parser_stream_get_buffer() from.
Here's one: Spyro deadlocks with 5988.
The deadlock with Spyro is already fixed by !6444, but thanks for reporting it. I don't know whether that's the same kind of deadlock you're trying to fix here, but if so, clearly we don't need to rewrite an entire component to do it.
Which media files are you seeing this with? I'm seeing creation time under 1 ms with 5988, which is already faster than the time given for Windows, and fast enough to fix the application bugs mentioned.
Nothing special just some locally generated .mp4 file. It takes 35-65ms on my computer to resolve with the current code, takes 2.5-5ms with 5988. In a Windows VM on the same computer takes 0.2-0.5ms.
Some Unreal Engine versions have a race condition that triggers if this takes more than 200ms, which is large compared to the improved results, but still possible on low-end computers, we want to make this as small as possible.
What kind of video file? I'm not seeing 5988 perform any worse than Windows with any video file I can find; often it performs about 50% better.
Even on a slow old laptop (slow enough that it took me hours to compile Wine even with ccache) I'm not seeing any slower than 50 ms. Even if that 200 ms is a constant regardless of processor speed, we're already multiple times faster than we need to be.
Even if ffmpeg resolution can be faster—and there's no inherent reason to assume it can—there's no reason we need to rewrite this code.
In general, using FFmpeg directly also proved to be faster in all decoding scenarios. This is especially true on 32bit where GStreamer ORC color conversion performs badly.
A bug in one component of a library we use is not grounds to rewrite our entire stack to use a different library. What happens when we find a comparable problem in ffmpeg?