Rémi Bernon (@rbernon) commented about dlls/mf/topology_loader.c:
- if (FAILED(hr = MFCreateTopologyNode(MF_TOPOLOGY_TRANSFORM_NODE, &copier_node)))
return hr;- IMFTopologyNode_SetObject(copier_node, (IUnknown *)copier);
- IMFTopology_AddNode(context->output_topology, copier_node);
- IMFTopologyNode_ConnectOutput(upstream_node, upstream_output, copier_node, 0);
- IMFTopologyNode_ConnectOutput(copier_node, 0, downstream_node, downstream_input);
- IMFTopologyNode_Release(copier_node);
- return S_OK;
-}
-/* Right now this should be used for output nodes only. */ -static HRESULT topology_loader_connect_d3d_aware_input(struct topoloader_context *context,
It's not completely obvious to me that moving the copier creation to the branch resolver is:
1) The right thing to do,
2) Is actually what's fixing the issue.
I think the issue is fixed because you're now creating the copier with the same input and output types, using the upstream node output type, instead of querying the, possibly not yet initialized, downstream EVR node media type. I'd believe that a simpler change that only modifies the copier creation logic to ignore downstream type would fix it as well.
It would be nice to add some more tests, I think to `test_topology_loader` with custom D3D aware nodes to try to figure the answers to the following questions:
1) Are copiers really added dynamically to any branch? (Like if you have `non-d3d source -> d3d mft -> non-d3d output`, do you get two copiers?
2) Is the copier output type really initialized to the upstream node output type?