From: Derek Lesho <dlesho@codeweavers.com>
Subject: Re: [PATCH v2 1/4] winegstreamer: Introduce audio conversion transform.
Message-Id: <6a66b381-3351-6659-7835-d2cb060cfd57@codeweavers.com>
Date: Tue, 1 Dec 2020 15:06:57 -0500
In-Reply-To: <af1527a9-ae03-3c01-0d5e-0ba3d52e7701@codeweavers.com>
References: <20201118205255.539252-1-dlesho@codeweavers.com> <af1527a9-ae03-3c01-0d5e-0ba3d52e7701@codeweavers.com>


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