[PATCH 4/5] winegstreamer: Register WMA decoder transform stub.

[Zebediah Figura (she/her)]

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