[PATCH v1 1/3] mfreadwrite: Find a decoder in IMFSourceReader::SetCurrentMediaType.

[Nikolay Sivov]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200318/fa6fc2b1/attachment.htm>