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).