Frame Server Custom Media Source design question

NTDEV
1

Hi,
(be patient - I am a newbie on Windows driver development )

I am trying to expand the SimpleMediaSource sample from the Windows Driver Kit (here), which is a sample implementation of the feature described here Frame Server Custom Media Source

In simple terms, this is an approach to create ‘virtual’ or ‘software based’ camera within Media Foundation.

The design of Frame Server Custom Media Source is such that it has two components:
- an inproc COM DLL that implements a bunch of COM “Media Foundation” interfaces
- a UMDF v2 driver stub that deals with device and device interface creation, and handling of (some) I/O requests.

The sample code creates a virtual camera whose frames are just computed on the fly when requested, and present a moving gradient image (all computed inside of the COM object).

For the purpose of my design question, let’s say that all I want to do is produce frames that have a constant colour, and I want to be able to modify that colour from a standard windows application at any time. Obviously, what I am trying to do is a bit more elaborated than that.

My initial intention was to define some IOCTLs (I come from Linux world after all) that allow me to send commands to the driver to achieve what I want. But, I find, that once the driver receives the IOCTL on its queue (which I can do), I have no ‘pointer’ to the instance of the COM object associated with this device. Hell, I am not even sure in which context that IOCTL is being executed (is it the calling process’ context, is it the one from UMDF Driver Host ?, or something else ?).
Also not 100% sure what the context is for the COM objects. I am assuming is it “UMDF Driver Host”, but not sure at all.

So my question is, what approach do people recommend for solving this.
a) my original approach with IOCTL ? but then how to share data between the driver IOCTL-handling code and the COM objects – are they running in the same context ? can they ‘call’ each other ?
b) use named pipes - which seems to me a bit silly and wasteful (maybe I am wrong… don’t know enough about windows)), as it seems like it is more heavy weight than the IOCTL (it is ultimately using IOCTL or similar on its implementation) , and there is already a ‘meeting point’ defined for devices (\Device\XXXXX) so we are duplicating things…
c) use some other IPC ?
d) something else ?

Thanks for listening and for any input on this.

Raul.

2

For anybody dealing with this:
Whilst prototyping the ‘named pipe’ approach, I found out that the COM objects are being executed from “svchost.exe -k Camera -s FrameServer” process, and not “UMDF Driver Host” as I had originally suspected.
Also interesting is the lifetime of those objects. The service is not always running, but it is rather created when an application accesses the device, and destroyed when the application closes.