Dependency on mfplat.dll (Media Feature Pack)

[Tim Lander]

jpegls_bitmap_frame_encode::WritePixels uses MFCopyImage, which comes from mfplat.dll, part of Media Feature Pack. Not every version of windows will support this out of the box.

I think it would be good to have one less dependency, and it would make the code easier to understand.

The code in question is here:

jpegls-wic-codec/src/jpegls_bitmap_frame_encode.h

Lines 189 to 190 in 575d883

 winrt::check_hresult(MFCopyImage(reinterpret_cast<BYTE*>(destination), static_cast<LONG>(destination_stride), 
                                  pixels, source_stride, static_cast<DWORD>(destination_stride), line_count)); 

and I propose that this be replaced with the implementation that wine uses, found here:
https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2b847f321ad89b2ae4f6f1/dlls/mfplat/main.c#L1510-L1522

I'm happy to submit a PR, if there's any interest in this.

[Victor Derks]

Interesting topic.

According to:
https://docs.microsoft.com/en-us/windows/win32/medfound/media-foundation-headers-and-libraries
mfplat.dll is part of the Windows OS itself. Which version of Windows do you expect don't have this DLL by default?

The main reason for now using it, is that this function is optimized to leverage the MMX, SSE, or SSE2 instruction , when available.

[Tim Lander]

I was testing this code in a Windows 10 Pro N VM. This version of Windows comes without the Media Feature Pack, which includes mfplat.dll.

[Victor Derks]

I did some disassembly on MFCopyImage (to ensure the API docs are correct), but it is using optimized SSE instructions.
As Windows 10 "N" only exist for legal reasons and is rarely used (give the list of things that don't work on it) I think to best solution is add a remark in the README.md about this limitation. With the Media Feature Pack installed (which is a build in option on newer versions of Windows 10 "N") the codec works fine.