On Tue Dec 5 09:58:52 2023 +0000, Rémi Bernon wrote:
I'm sorry to say that but I see several issues with this:
- 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).
1. Directly using mpegpsdemux won't help in this case as it ignores the stream table in the system header and creates its pads in the order it sees the corresponding packets in the file.
2. Supporting more than two streams would require full IAMStreamSelect implementation, as native only creates one output pin per stream type. This can be done in theory by matching mpegpsdemux pads by name to the corresponding stream in the header.
3. I don't see any other option, as GStreamer doesn't currently expose the required information.