On Thu Apr 2 06:57:06 2026 +0000, Conor McCarthy wrote:
With everything being interdependent, it's difficult to make gradual changes without breaking tests or adding code which is similar to existing code. However, I found it goes much more smoothly if I start with indirect connections, which is basically the reverse of what I had before. I pushed a new set of commits. Well I think we can fix things without duplicating the indirect connection logic. The code here even has a TODO indicating that the video processor is supposed to go through MFTEnumEx, while removing the logic that was doing exactly that. I understand that we might want to change some cases to use color converter instead, but that doesn't require duplicating the entire indirect connection logic.
The fact that native doesn't use MFTEnumEx for color converter / resampler could be interesting to note but IMO there's not much justification doing the same unless some application really depends on that. MFTEnumEx can already be instructed to select the color converter when needed through the enumerated category (it is under VIDEO_EFFECT while the video processor is under VIDEO_PROCESSOR). What the tests really indicate is that there actually is a deeper media type enumeration going on, probably to try harder to match types between upstream and downstream nodes, when we only currently try our luck optimistically. This can be added while keeping the rest of the logic mostly unchanged. The type_enumerator is also very difficult to understand, as it squeezes together all possible cases (when there's a current type and where there is not) when they should be made more obvious by keeping the cases clearly separate in the code. It is already done in `topology_branch_connect`, and could be done the same for downstream type enumeration. I've implemented this here: https://gitlab.winehq.org/rbernon/wine/-/commits/wip/topology-loader, fixing most of the tests. There's only a handful and harmless todo_wine remaining after these changes, a couple of successful connections when we should fail, and one failure that returns a different error. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10009#note_135274