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

[Zebediah Figura (she/her)]

On 12/2/20 3:07 PM, Derek Lesho wrote:
> 
> 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. 

I'm not sure I understand; what do you mean by this?

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

It would be nice to confirm whether this is the case.

> In practice, what this means is that without PCM<->Floating
> Point capabilities, Borderlands 3 doesn't work.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x0D9D358A07A17840.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201202/ccf9b4fb/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201202/ccf9b4fb/attachment.sig>