On 3/11/21 2:39 PM, Derek Lesho wrote:
On 3/11/21 3:33 PM, Zebediah Figura (she/her) wrote:
On 3/10/21 1:33 PM, Derek Lesho wrote:
Signed-off-by: Derek Lesho dlesho@codeweavers.com
dlls/winegstreamer/Makefile.in | 1 + dlls/winegstreamer/decode_transform.c | 301 +++++++++++++++++++ dlls/winegstreamer/gst_private.h | 2 + dlls/winegstreamer/mfplat.c | 1 + dlls/winegstreamer/winegstreamer_classes.idl | 6 + include/mfidl.idl | 1 + 6 files changed, 312 insertions(+) create mode 100644 dlls/winegstreamer/decode_transform.c
This patch is just mfplat code, so I'm not particularly qualified to review it.
It might make sense to prepend "mf" or "mfplat" to "decode_transform", though, maybe shortening it to "mfplat_decoder". We may want to introduce a DirectShow filter (see e.g. bug 34744), which can also be said to be a decoder transform.
Hmm, from what I've read on the MSDN many transforms share the same code, exposing themselves as both a directshow filter and a MFT. Would we want to replicate this? For what it's worth, I don't plan on looking into this any time soon, so maybe for now mfplat_decoder is better and it could be renamed to something more appropriate if/when somebody took this up.
MSDN is kind of fudging the truth, what these transforms are actually exposing is not a native DirectShow filter but rather a DirectX Media Object (DMO), which can be wrapped by DirectShow. Still, you have a good point, we may likely want to use a combined object here.