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.
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... Here's one: Spyro deadlocks with 5988.
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.
This also makes the demuxer usable to implement some specific native behavior. The WM synchronous reader for instance, performs reads from its caller thread, this is simply impossible to implement with GStreamer.
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.