Virtual video capture device driver
in [Device Drivers]
|
Prev: about READ_PORT_ULONG
Next: Emulating a WebCamera
From: rep_movsd on 4 Jan 2006 02:44 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
From: Max Paklin on 7 Jan 2006 05:57 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.movsd(a)gmail.com> wrote in message news:1136360649.968577.40770(a)g47g2000cwa.googlegroups.com... > 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 >
From: rep_movsd on 18 Jan 2006 08:43 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?
From: Max Paklin on 19 Jan 2006 18:06 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.movsd(a)gmail.com> wrote in message news:1137591786.377583.66820(a)o13g2000cwo.googlegroups.com... > 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? >
From: rep_movsd on 20 Jan 2006 02:42
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? |