https://bugs.winehq.org/show_bug.cgi?id=50779
--- Comment #29 from Zeb Figura z.figura12@gmail.com --- https://gitlab.winehq.org/wine/wine/-/merge_requests/1424/diffs helps share the message thread, although I don't remember if that was even a problem here (but my guess is yes, it's kind of the default behaviour.)
We could probably do something similar for the read thread? Or at least throw that into a thread pool.
The streaming threads are already created on pause/stop.
That leaves GStreamer's streaming threads. The problem is that in order to get rid of those, we have to start and stop the filter, and that's actually expensive (not so much because typefinding is expensive, but because prerolling is.) That was one of the motivations for 90107bba9, besides the code cleanup. I don't think there's any way to have it both ways, not within the design of GStreamer. (IIRC typefind doesn't do it since it won't demux.) Maybe we can get away with just letting WoW64 support handle this? It's still not great, not all of that memory is going to be unused, but maybe it's enough, and this is definitely the less common case anyway.