On 3/18/20 5:53 PM, Derek Lesho wrote:

Is it really useful to have a second call here? It probably means "any" output type, which could work in some interactive scenario. Does it really
offer anything available in this case on Windows and what happens to current type?

The reason we need the second call is so that we return the correct error code. `MF_E_INVALIDREQUEST` when the type can't be output, and `MF_E_TOPO_CODEC_NOT_FOUND` when a decoder isn't found for a native media type.

Let's keep it simple and return MF_E_INVALIDREQUEST, with single enum call.

Would it help to use IMFActivate instances instead? For example that would be the only way to access local transforms, but I don't know if reader is using them.

I'm also unsure whether the source reader can access local transforms, but it doesn't seem critical to me. Do you think this could instead be added in a future patch?

Definitely. I asked because they moved away from CLSID-based enumeration in later versions of EnumEx and Enum2, and only newer functions give control over returned results.

This should handle a case when output type should be set first.
Is this ever the case with a decoder?

I don't know, it's documented to work one way or another. It's a minor addition if we ever need it, for user transforms for example. If you verified that at least some decoders work like that, no need to change it.