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

[Rémi Bernon]

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

Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>