I did see some other DMO tests under `mf/tests`, but it didn't feel right to me to put DMO tests there given DMO and MF are different technologies. But I guess they do have a lot of overlap, so the tests (and implementation) for one can be leveraged for the other. I'm happy to move it there if you think that's the right place.
We have already several DMO tests for the decoders there, it may seem that they are different APIs but for DMO/transforms it's actually much more intertwined, and some objects which implement both have a behavior that pretty much depends on that dual nature (and mixing calls between both interfaces is even possible). Also, for the purpose of running tests (locally for instance), it's much much simpler to have a single executable to run to cover as much surface as possible, rather than having to list every possible module out there. MF tests already span across 4-5 different modules, I think it's better to avoid adding tests in every separate component module or they will likely be overlooked.
The implementation I currently have on my local copies the `IMediaSample` data to a `IMFMediaBuffer` and uses the `IMFTransform` interface of the MF color converter, but I thought it might be better to use `IMediaBuffer` to wrap the `IMediaSample` and hence use the `IMediaObject` interface. So not really a big deal if I do use the `IMFTransform` interface.
There are MF functions for interop but usually it's the other way around (and that's because dual MF transforms are basically implemented by wrapping the DMO calls). I'm not sure how easier or more difficult it is to wrap `IMediaSample` / `IMediaBuffer`, but I feel that because they are from the same era it might be easier to go this way rather than through MF?
I think for now I might go with option 2. The only benefit to using the `IMediaObject` interface was less data copies; but this is an older API, so I don't think I need to worry about 4k/60fps video.
It depends on how much data copy we mean. We should be able to avoid copying the actual data in all cases, or we will likely have some issues anyway. These games usually don't have so large videos but they may still suffer from playback issues if video conversion is too slow. And regardless, we should simply avoid copying frame data around unnecessarily. Fwiw we have / had (that should improve with new wow64 mode) plenty of playback problems with games using wmvcore, because color conversion performance in Gstreamer 32bit ORC was terrible. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10709#note_137194