I'm not sure how extensively you intend to test it but imo it might be better to use mf/tests/transform.c for that, it already has plenty of utility helpers to check transforms and dmo behavior.
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.
Also, is there any specific reason to implement the dmo side?
I'm implementing the Color Space Converter direct show filter: https://learn.microsoft.com/en-us/windows/win32/directshow/color-space-conve... 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.
Let me know if it conflicts with your plans.
Not at all. I've got options: 1. Implement and use the `IMediaObject` interface in winegstreamer; 2. Stick with the existing `IMFTransform` interface; or 3. Wait for your MR to be merged and use the `IMediaObject` interface there 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10709#note_137191