Virtual video capture device driver

[rep_movsd]

Hi
I need to develop a Virtual video capture device, I have so far used a
normal directshow source filter registered under
CLSID_VideoInputDeviceCategory, but several apps fail to recognize it
as a genuine capture device even though AMCAP and WM encoder do so.
So I have decided to write a device driver instead.
Since I have no experience with driver development, I realize that my
best chance of success lies in using the existing samples from MS and
modifying them to suit my requirement.
I have found the following to be viable :
1) The avssamp sample driver
2) The avshws sample driver
3) the TestCap sample

The testcap thing works out of the box simulating a tv tuner, but
theres an awful lot of code in there and it looks forbiddingly
difficult to modify.
The avssamp and avshws seem more manageable , but they register
themselves as "WDM streaming Video Capture" devices and are not
recognized by any app as a capture device, though they work fine in
Graphedit.

Now I have some questions :
1) Can I make the avssamp filter get registered as a normal capture
device?
2) How do i see the output of the DbgPrint and KdPrint functions ?
3) Would it be more simple to write a VFW driver instead?( I read
somewhere that they can be simple user mode DLLs exporting a function
called DriverProc() ) If so where can I get more info on this?(Google
seems to be silent on this one)

Any suggestions are welcome.

Thanks in advance
Vivek

[Max Paklin]

IMO you are better off to use TestCap. In terms of complexity it is about
the same as avshsw, but it is easier to modify to fit your needs.

VFW capture driver might be your best bet as some people advocate.
Personally I don't like it, but many find it much easier to write as opposed
to doing kernel mode work. See Win95 DDK.

Output of DbgPrint or KdPrint can be captured with DbgView (Google it)
however you will have to get familiar with WinDbg if you are to do any
kernel mode debugging and WinDbg captures the output of those routines as
well.
Read WinDbg help on how to set up and use the debugger.

Overall you are up for a lot of reading in the DDK about what KS is and how
to write a Stream Class or AVStream minidriver.
Then arm yourself with the debugger and step through the code of existing
sample TestCap would be my choice and see what it does and how it works.
After that you should be able to customize it for your needs.

-- Max.

"rep_movsd" <rep....@gmail.com> wrote in message
news:1136360649....@g47g2000cwa.googlegroups.com...

[rep_movsd]

Ive made some progress and modified the testcap sample to show only one
RGB output pin on the filter.
Next step was trying to map a shared memory section into which i push
data from a user mode app and which ought to be rendered by the output
pin.
The section is easily created in the HwInitialize() function and Im
able to access the section from user mode, but when I try to read that
memory from the VideoCaptureRoutine() function it BSODs with
DRIVER_IRQL_NOT_LESS_OR_EQUAL.
even if I wrap the memory access in _try except, it still does that.
Is it possible to send a request to a KS driver with DeviceIOControl?
If It is possible , assume the following scenario. App 1 opens the
device and begins rendering the output. From app 2 I open the device
handle and send it an IOCTL. Will the IOCTL go to the instance of the
driver running in App1 or will it go to a separate instance?
How can I achieve this user mode to kernel mode data transfer properly
and easily?

[Max Paklin]

Your crash is probably due to the fact that you setup section in
HwInitialize (which runs in context of system process) and use it in the
context of the calling application.

Your two applications will have access to the same instance of the device
object. If you create another instance of the filter in some other
application, the underlying device object will still be the same.

However I'd argue whether or not you are using the best approach. The
easiest way to do this in WDM world is to submit a bunch of IRPs with the
data from your application #2. In the driver you then pend them, queue them
and complete when you no longer need them.

In KS universe it may not be that easy as you don't open files the way you
would usually do it in WDM.
You normally create an instance of DirectShow filter and access the device
through it. So it is certainly possible to define a custom property set and
then feed your driver with the data through it.

-- Max.

"rep_movsd" <rep....@gmail.com> wrote in message

news:1137591786....@o13g2000cwo.googlegroups.com...

[rep_movsd]

Hi
Yes, I decided to use a custom property set as you suggest, so i can
simply open the DS filter object, get an IKSPropertySet from it and
send the data to it.
However, is it advisable to send large amounts of data through property
sets? Is there a fundamental difference between the CreateFile /
DeviceIoControl way of sending IRPs and using IKsPropertySet::Set to
transfer data in terms of performance?

[Max Paklin]

None.
IKsPropertySet::Set is just a wrapper over DeviceIoControl.

-- Max.

"rep_movsd" <rep....@gmail.com> wrote in message

news:1137742947.3...@g47g2000cwa.googlegroups.com...

[rep_movsd]

Hi
Its all in place now , I have a working solution.
I use IKspropertySet on the capture device filter requesting a custom
property and the driver makes a user mode accessible memory block and
passes it via the property data.The user mode app then dumps data into
it.
I found an old post on this group with a function called
XXX_CreateSection which makes the user accessible memory.
So thanks everyone for all the help !!