Hi,
Il 07/05/21 10:30, Nikolay Sivov ha scritto:
I doesn't seem like a right thing to do. This helper is meant to check if decoder is necessary, for that you only need a subtype test. Admittedly existing naming does not make it obvious.
What should happen in general case:
- check major/subtype to see if decoder is necessary at all;
- if it's necessary, look for the decoder;
- unconditionally compare for format data to see if converter is
necessary, and append one.
According to docs it should support local transforms, so registering local dummy converter (that is only able to negotiate types) for 16 -> 32bit resampling, and trying again could potentially succeed instead where it returns MF_E_TOPO_CODEC_NOT_FOUND now. It's possible that on Windows reader is either confused by raw types source returns and skips that part, or fails to find a converter in first place (or conversion is disabled by default despite what docs say).
I admit my patch is not perfect, but still it seems better than what happens now.
At some point the data in the requested media type must be compared with the native media types provided by the source. Currently this does not happen and if the caller requests a 16 bit format while the source provides a 32 bit format, the source reader will acknowledge the request with 16 bit but return 32 bit audio, which will result in garbled audio.
Also, suppose that a media source exposes both a 32 bit and a 16 bit media type. I expect (and my tests on Windows seem to confirm it) that if you request 32 bit you get the first media type and if you request 16 bit you get the second, even if they both match at the major/subtype level. The current implementation can only match the first one. Since Windows matches the correct one, it seems that Windows does at least one round of matching taking also media type data into account.
According to [1], the search for a decoder only happens if the native type is compressed, otherwise only native media types are allowed. I understand that MSDN can be incorrect, but this seems to align with my (admittedly limited) testing. Do you have evidence of the contrary?
[1] https://docs.microsoft.com/en-us/windows/win32/api/mfreadwrite/nf-mfreadwrit...
Thanks, Giovanni.