<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 3/18/20 5:53 PM, Derek Lesho wrote:<br>
<blockquote type="cite"
cite="mid:71c83063-599e-12e4-b0f3-28833c03ae73@codeweavers.com">
<blockquote type="cite" style="color: #000000;">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
<br>
offer anything available in this case on Windows and what
happens to current type?
<br>
</blockquote>
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.
</blockquote>
Let's keep it simple and return MF_E_INVALIDREQUEST, with single
enum call.<br>
<br>
<blockquote type="cite">
<blockquote type="cite" style="color: #000000;">
<br>
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.
<br>
</blockquote>
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?
</blockquote>
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.<br>
<br>
<blockquote type="cite"><br>
This should handle a case when output type should be set first.
<br>
Is this ever the case with a decoder?
</blockquote>
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.<br>
</body>
</html>