On Sun Nov 6 10:42:58 2022 +0000, Rémi Bernon wrote:
It's not completely obvious to me that moving the copier creation to the branch resolver is:
- The right thing to do,
- 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:
- 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?
I agree that added complexity is not obviously helpful. If the real issue is that some types are not configured somewhere, we could fix just that. Regarding adding copiers at any suitable point, it's not hard to test manually I suppose, with topoedit. Some generic solution checking if 'upstream_d3d_aware != downstream_d3d_aware then add copier', but first we need this checked on Windows, and second we will not get in this situation in wine in practice.