On 1/21/22 12:19, Rémi Bernon wrote:
On 1/21/22 19:03, Zebediah Figura (she/her) wrote:
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.
All the games I've seen which required the MF transforms (H264 and AAC) are instantiating them by their class id.
FAudio does it too for the WMA decoder, and although it could use MFTEnum I don't see how easier it would make anything else, we'll still need that WMA decoder class, or a class which can decode WMA.
For now it's the only class there is so it's named wma_decoder, but could easily be renamed later if it matches some other codec.
Okay, if there's no known application that uses MFTEnum() then I guess there's not much point in creating a generic transform instead of the WMA object.
[Seems like a huge step back from the era of DirectShow. I guess this is what happens when you make APIs much harder to use...]