[PATCH v2 1/4] winegstreamer: Introduce audio conversion transform.

[Derek Lesho]

On 12/2/20 4:01 PM, Zebediah Figura (she/her) wrote:
> On 12/1/20 2:06 PM, Derek Lesho wrote:
>> On 12/1/20 3:00 PM, Zebediah Figura (she/her) wrote:
>>>> +static HRESULT WINAPI audio_converter_ProcessMessage(IMFTransform
>>>> *iface, MFT_MESSAGE_TYPE message, ULONG_PTR param)
>>>> +{
>>>> +    FIXME("%p, %u.\n", iface, message);
>>>> +
>>>> +    return S_OK;
>>>> +}
>>> Why S_OK?
>> Because the media session sends some messages to the transform such as
>> MFT_MESSAGE_NOTIFY_BEGIN_STREAMING and fails to play if S_OK isn't
>> returned.  I take it you'd like me to actually implement this method
>> instead.
> Not necessarily, but if nothing needs to be done, then presumably there
> shouldn't be a FIXME either, and it's not obvious to me what needs to be
> done. Sorry, I guess that comment should have been more specific.
FWIW I've already sent a patch "implementing" this function in v3? 
Should I remove it and just switch to a trace or just keep it as is?  I 
think it may be better to keep it as is, since some messages not being 
implemented may cause real problems.
>
>>> Why not CLSID_CResamplerMediaObject? In fact, we already have one
>>> application that needs it (bug 47781).
>> The only reason I didn't expose it as CLSID_CResamplerMediaObject is
>> that I didn't want to imply that I was basing the interface and types
>> supported off of that specific object.  For instance, that object, from
>> what I can see on the MSDN, doesn't support PCM<->Float conversions, and
>> vice versa.  Is this not a big enough deal to keep it separate?
>>
> Do we need to support integer/float conversion?
Yes, from what I've seen the SAR usually only supports one or the other, 
at-least on wine.  Exposing a PCM and Float type from the source doesn't 
solve this either, as the application doesn't have to specify 
ENUMERATE_SOURCE_TYPES when loading the topology, and in practice, 
rarely does, so the topology loader is forced to work with whatever the 
default type happens to be.  It may be that on windows the decoders 
almost always expose both a PCM and floating point type, but currently, 
we are not using decoder MFTs in wine (and instead decoding in the media 
source).  In practice, what this means is that without PCM<->Floating 
Point capabilities, Borderlands 3 doesn't work.