Does a third-party Device MFT (DMFT) for a UVC webcam require WHQL/attestation signing, or is test-signing sufficient?

Barishth 0 Reputation points
2026-09-14T10:36:52.64+00:00

I want to apply a simple horizontal flip to the video stream from a USB UVC webcam (Logitech Brio 100), system-wide, before it reaches any application (Teams, Zoom, Chrome, etc.) — not just as a local preview mirror.

From the docs (Device MFT Design Guide and UVC Camera Implementation Guide), I understand that:

A Device MFT (DMFT) can be supplied as a user-mode COM object in a DLL

It's registered via a custom INF file referencing sections of the inbox USBVideo.INF

This effectively makes it install as a driver package, not just a regsvr32-registered COM component

Questions on installation/signing:

Does installing a DMFT this way require a full WHQL/attestation-signed catalog file (via the Windows Hardware Dev Center + EV code-signing cert), or can it be loaded with Windows in test-signing mode for personal/non-commercial use?

If test-signing is sufficient, are there any additional Frame Server-specific restrictions that would prevent an unsigned/test-signed DMFT from being loaded, separate from standard driver signing enforcement?

Is there a lighter-weight registration path for a DMFT that doesn't require a full INF-based driver package install, given this is a single-purpose transform (flip) rather than a hardware-specific feature?

Questions on implementing the flip itself:

For the actual transform logic — is a horizontal flip best done as a simple row-wise pixel reversal on the raw frame buffer (e.g., for YUY2/NV12/MJPEG formats), or does the DMFT interface expect/prefer this to be done via a specific Media Foundation helper rather than manual buffer manipulation?

Since the camera may expose compressed formats (e.g., MJPEG) on some pins, does the DMFT receive decoded/raw frames, or would I need to decode, flip, then re-encode within the transform itself?

Are there existing minimal/reference DMFT samples (beyond the "green box" Driver MFT sample) that demonstrate a real per-frame pixel transform, ideally with format-agnostic handling?

Referenced docs:

https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/dmft-design

https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-camera-implementation-guide

Windows development | Windows Driver Kit (WDK)
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. MSTF Employee 0 Reputation points Microsoft Employee
    2026-09-16T01:07:32.5366667+00:00

    Short answer: You must ship a DMFT as an INF-installed driver package (not just a regsvr32 COM DLL), so it falls under Windows driver/driver-package installation rules. Test-signing is fine for development and personal testing, but not for production distribution — for broad deployment you should follow the Windows Hardware Developer Center/driver-signing path. Implementation-wise, a DMFT receives whatever mediatypes the KS pin/devproxy exposes, so if the camera exposes compressed MJPEG your DMFT will see that mediatype and will need to decode -> flip -> (re)encode or negotiate an uncompressed input mediatype. For best compatibility, produce NV12 outputs and use Media Foundation allocators and work queues per the DMFT design guidance.

    Concrete points and steps

    • Installation/signing
      • A DMFT is installed via a custom INF that registers the DMFT CLSID under the device key (Device MFT design guide and UVC guide). You can’t rely on a simple global regsvr32 registration for device-wide DMFT behavior.
      • For development/personal use, test-signed driver packages are supported (see Introduction to Test-Signing). Do not use test signatures for production releases.
      • For production distribution follow Microsoft’s driver-signing policies (Hardware Dev Center / EV-code-signing where required) and the Driver signing guidance.
    • Frame-server / Frame-Server-like restrictions
      • The official docs require per-device INF registration and, on some OS builds, both 32-bit and 64-bit DMFT registration for external cameras (see UVC guide). The docs do not state extra "Frame Server only" signing exceptions; assume normal driver-package signing policy applies.
    • Implementing the horizontal flip
      • The DMFT receives samples in the input mediatype the KS pin exposes; input mediatypes must match the driver’s mediatypes (Device MFT design guide). If the pin is MJPEG you will receive compressed MJPEG samples and must decode them to raw (or request the device to output an uncompressed mediatype) before pixel-level flips.
      • For raw formats you can implement a flip by manipulating the pixel rows, but be careful: NV12 is planar (luma plane and subsampled chroma) and must be reversed per-plane with correct chroma handling; YUY2 is packed and requires swapping chroma pairs accordingly. The DMFT design guide requires the use of MF allocator APIs for non-inplace outputs, and recommends NV12 as the preferred output format.
      • You must implement the required DMFT interfaces (IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl, IMFMediaEventGenerator) and use Media Foundation work queues (no custom thread creation).

    Recommended next steps

    1. Implement your DMFT to accept the device’s input mediatypes and produce NV12 output (or negotiate uncompressed input).
    2. For development, test-sign the package and install via INF on your test machine. Validate with apps (Teams/Zoom/Chrome) that use the camera via the capture pipeline.
    3. For distribution, prepare a driver submission and follow Hardware Dev Center signing guidance.

    Two quick questions to focus next advice:

    1. Do you plan to distribute this beyond your own machine(s) (production/other users)?
    2. Which Windows versions/builds do you primarily want to support (Windows 10, Windows 11, specific build numbers)?

    Relevant docs (read first):

    If you want, answer the two questions above and I’ll give a focused checklist (INF directives, exact interfaces to implement, and the minimal set of formats to support for a robust flip transform).

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.