On 1/21/22 11:41, Rémi Bernon wrote:
On 1/21/22 18:23, Zebediah Figura (she/her) wrote:
On 1/21/22 02:57, Giovanni Mascellani wrote:
Hi,
Il 21/01/22 02:44, Zebediah Figura (she/her) ha scritto:
Is there an application that requires this, other than FAudio?
I don't know, but notice that Mono ships a copy of FAudio, so if we want to patch FAudio, we have to patch that one as well.
And if not, can we instead try to change FAudio to not require specific decoders?
Even if the current user is just FAudio, wouldn't it better to implement properly CWMADecMediaObject anyway? This way you automatically catch all future users of it. Why is CWMADecMediaObject something that we might not want to implement?
We will need some way to decode arbitrary data via IMFTransform objects, but it seems preferable to avoid having to implement more objects than we need. E.g. trying to catch as many as possible via a generic decoder seems like a good idea. In that case we'd want to use MFTEnum() in FAudio instead of hardcoding the CLSID.
From the few early tests I've made each transform seems to have its own behavior and some games heavily hardcode their logic around it.
I think catching everything behind a generic decoder is not a good idea in that situation, and it makes the code harder to understand as the specific logic that needs to be implement to satisfy each game and each corner case is interleaved together.
I'm not necessarily arguing for keeping *everything* behind a generic decoder, but it'd be nice to catch everything that doesn't otherwise care. Sure, some applications are going to depend on idiosyncratic behaviour, but the hope is that most are more well-behaved and don't care, especially if they're using MFTEnum() rather than hardcoding CLSIDs in the first place.
I don't really why it would be so bad to keep them split for now until we have a better view of how different they are. If there really is so many of them and if they really are similar, it'd be simpler to refactor things later when we now what we need to cover. But I don't think it's going to be the case.
I think most of the transform code is going to be very simple anyway, and just a matter of validating media types and a bit of sequence logic, the meat of the decoding is delegated to Gstreamer.
Simple, sure, but even as stubs it's over 300 lines. Seems like the kind of thing it'd be nice to avoid if possible.