Rémi Bernon (@rbernon) commented about dlls/winegstreamer/quartz_parser.c:
+ { + BYTE stream_id; + + if (FAILED(IAsyncReader_SyncRead(filter->reader, 24 + i * 3, 1, &stream_id))) + return FALSE; + + if (!(stream_id & 0x80)) + break; + + if (0xe0 <= stream_id && stream_id <= 0xef) + return FALSE; + if (0xc0 <= stream_id && stream_id <= 0xdf) + return TRUE; + + WARN("Unknown stream type 0x%02x.\n", stream_id); + } I'm sorry to say that but I see several issues with this:
1) this is a workaround, trying to mitigate our use of decodebin which doesn't provide the deterministic behavior we need, it isn't IMO the right way to fix it (*) 2) it only supports a very small use-case, reordering a single audio stream first, we should instead support any scenario, including with more than two streams or with non-audio non-video streams first. 3) it also looks like the beginning of proprietary format demuxing code, I think it opens a big can of worms we probably don't want to get involved with. (*) I've been advocating for, and trying to upstream some work to fix this properly (in https://gitlab.winehq.org/wine/wine/-/merge_requests/3606), using deterministic demuxer elements. I have only been working on the MF side so far but clearly we have that issue everywhere and I would really like this to move forward now that it's getting even more obvious (we now have a MR on the quartz side, and it's also known for a long while that the WM reader suffers from it too). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4601#note_55022