From: "Zebediah Figura (she/her)" Subject: Re: [PATCH 4/5] winegstreamer: Register WMA decoder transform stub. Message-Id: <2f2454f2-825a-5cd9-0cea-9d942d44fea8@codeweavers.com> Date: Fri, 21 Jan 2022 12:31:27 -0600 In-Reply-To: References: <20220120104152.2236851-1-rbernon@codeweavers.com> <20220120104152.2236851-4-rbernon@codeweavers.com> <2d892439-0926-6669-11b6-4c6c8aa1d105@codeweavers.com> <669bfe25-49ec-a509-b999-b6d23c9948e7@codeweavers.com> <600afee8-6b14-4bb0-5bda-8a70a0e20ec2@codeweavers.com> <3ec19c73-6caf-15b5-e1cb-544c9bfb3f4f@codeweavers.com> 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...]