On Tue Feb 25 20:12:23 2025 +0000, Brendan McGrath wrote:
The function already has everything needed to support a `MT_AM_FORMAT_TYPE` value of `GUID_NULL`, but it is not being accepted. As you can see in the tests, it should be returning `S_OK` when `MT_AM_FORMAT_TYPE` is `GUID_NULL` (or missing, as `GUID_NULL` is the implied default), but instead it is returning an error (hence the `todo_wine` prior to the fix). The issue is with the following `if` statement:
!IsEqualGUID(&subtype, &MFAudioFormat_PCM) && !IsEqualGUID(&subtype, &MFAudioFormat_Float)it will return an error when subtype is neither PCM or Float. But it should also consider the value of `MT_AM_FORMAT_TYPE` and allow `GUID_NULL` (whether explicitly set or implied by not being set at all). So the I've modified the if statement to allow `GUID_NULL` by saying in addition to subtype being neither PCM or Float, `MT_AM_FORMAT_TYPE` must be explicitly set and must be a value other than `GUID_NULL`. Otherwise we'll allow it. Hence I've modified `MFCreateWaveFormatExFromMFMediaType` to allow `MF_MT_AM_FORMAT_TYPE` to be missing or set to `GUID_NULL`.
I see. So basically this means type could provide MT_USER_DATA or MT_AM_FORMAT_TYPE. MT_USER_DATA prioritized and MT_AM_FORMAT_TYPE(GUID_NULL) is a no-op. In addition to that MT_USER_DATA or MF_AM_FORMAT_TYPE are ignored for MFAudioFormat_PCM and MFAudioFormat_Float (so for any raw format?). Do we know what should happen if MT_AM_FORMAT_TYPE is used with non-zero GUID value? This nesting check looks too complicated and something to be changed completely once we need to handle non-zero guids.