On 10/5/20 10:22 AM, Derek Lesho wrote:
On 10/2/20 11:10 AM, Zebediah Figura wrote:
I think it would be far simpler to query the videoconvert element you've actually just added.
I'm not exactly sure what you mean by this. Do you mean querying the caps of videoconvert's source pad and using the formats there to build the descriptor? This seems like it would be approximately as complex as the current solution, but I'll do it that way if you prefer. Or is there some other solution I'm not thinking of?
Essentially that, yes, and ideally querying it after you've connected. This saves you code to retrieve the pad template, for one thing. It's also more conceptually correct—there's no guarantee that a pad will actually be able to produce all of the formats in its template. That probably won't matter for videoconvert in practice, granted, but what will probably matter for videoconvert is the order of formats returned—videoconvert has code in it to prefer "easier" conversions to harder ones.
FWIW, I queried the caps of the videoconvert's source pad just to test, and saw [1], so if taking that route I think I'd have to add something to remove duplicate formats.
Presumably, yes, unless you can get away with just not doing that. I don't know about Media Foundation, but it's not unheard of for quartz filters to report the same format multiple times, and I've yet to see an application break because of it.
Note also that one potential alternative to the approach in this patch is to do what quartz does, and just offer a fixed list of video formats (plus the "default" format that the pad proposes). Both approaches seem architecturally sensible to me, but I'm not immediately sure which one is easier. The quartz approach is likely easier if you ever want to manually prefer certain output formats, though.