stream class driver symbolic link for video capture.

Hi friends.

I am trying to write an efficient video capture application that
captures video frames from video conferencing cameras (mostly USB). I
need to support Win2000 and beyond. I found one way to do it using STI
(Still image architecture). But I don’t know if most webcams in the
world support STI. I figured that the safest way to get to the
underlying minidriver is by sending IOCTLs to the steam class driver
(stream.sys). Does anyone know if the stream.sys symbolic link is
exposed or if the interface is documented anywhere ? I know that
stream.sys must be having an interface to talk to because DirectX
filters use it to capture video. I don’t want to use directX for a
myriad of reasons.

Can anyone suggest if I am on the right track ? If I can get pointers to
some documentation other than the DDK (or specific documentation within
the DDK) that would be very useful. Also please feel free to let me know
if I am wasting my time looking for the stream.sys interface.

Thanks a lot.

Amitabh Mathrawala wrote:

I am trying to write an efficient video capture application that
captures video frames from video conferencing cameras (mostly USB). I
need to support Win2000 and beyond. I found one way to do it using STI
(Still image architecture). But I don’t know if most webcams in the
world support STI.

The vast majority of the webcams I’ve worked on support STI. There
isn’t much required of a driver to support it.

I figured that the safest way to get to the
underlying minidriver is by sending IOCTLs to the steam class driver
(stream.sys).

I don’t think you really want to do that. What IOCTLs do you plan to send?

I don’t want to use directX for a myriad of reasons.

In my not-very-humble opinion, you should rethink that decision.
DirectShow is incredibly flexible, and not all that hard to use.
There’s a fair amount of boilerplate code, but it’s all cut-and-paste.
With CComPtr and CComQIPtr, COM is pretty darned easy to do. I’ve
worked on a couple of cameras that do not have stream-class drivers, but
that support DirectShow via a user-mode source filter. Your solution
would miss those.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks for this info Tim. This was exactly the kind of info I was
looking for. The kind of IOCTLs that I was planning to send were the
same ones the directshow filters send down to stream.sys namely
SRB_SET_DEVICE_PROPERTY, SRB_GET_STREAM_INFO, etc. The push to not use
directshow comes from another department of the company who don’t know
the intricacies of not supporting directshow. Thanks for pointing those
out.

Amitabh Mathrawala | Senior Software Engineer | Server Group |
xxxxx@viack.com | 425 605 7483

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, June 03, 2005 12:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stream class driver symbolic link for video
capture.

Amitabh Mathrawala wrote:

I am trying to write an efficient video capture application that
captures video frames from video conferencing cameras (mostly USB). I
need to support Win2000 and beyond. I found one way to do it using STI
(Still image architecture). But I don’t know if most webcams in the
world support STI.

The vast majority of the webcams I’ve worked on support STI. There
isn’t much required of a driver to support it.

I figured that the safest way to get to the
underlying minidriver is by sending IOCTLs to the steam class driver
(stream.sys).

I don’t think you really want to do that. What IOCTLs do you plan to
send?

I don’t want to use directX for a myriad of reasons.

In my not-very-humble opinion, you should rethink that decision.
DirectShow is incredibly flexible, and not all that hard to use.
There’s a fair amount of boilerplate code, but it’s all cut-and-paste.
With CComPtr and CComQIPtr, COM is pretty darned easy to do. I’ve
worked on a couple of cameras that do not have stream-class drivers, but

that support DirectShow via a user-mode source filter. Your solution
would miss those.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@viack.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I went ahead and tried to use STI to capture video by getting the
symbolic link (port name) of the underlying driver using
IStillImage::GetDeviceInfo.
According to the DDK I can use the port name inside the
STI_DEVICE_INFORMATION structure returned by IStillImage::GetDeviceInfo
to create a handle to the device and then send IOCTLs to the device get
raw video data. In my case, the port name that I am getting is “AUTO”
and that does not work with CreateFile (I tried “\.\AUTO”, “AUTO”,
“AUTO\0”).
Does anyone know what the port name of “AUTO” mean ? Does it mean that I
cannot open a handle to the device using createfile ?

A followup question that I have is, is there any way I can capture video
data from my USB webcam without using directx, wia, or twain ? I don’t
mind writing a kernel mode driver (filter) if there is documented or
semi-documented way of doing it.

Thanks for any help pointing me in the right direction.

Amitabh Mathrawala | Senior Software Engineer | Server Group |
xxxxx@viack.com | 425 605 7483

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, June 03, 2005 12:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stream class driver symbolic link for video
capture.

Amitabh Mathrawala wrote:

I am trying to write an efficient video capture application that
captures video frames from video conferencing cameras (mostly USB). I
need to support Win2000 and beyond. I found one way to do it using STI
(Still image architecture). But I don’t know if most webcams in the
world support STI.

The vast majority of the webcams I’ve worked on support STI. There
isn’t much required of a driver to support it.

I figured that the safest way to get to the
underlying minidriver is by sending IOCTLs to the steam class driver
(stream.sys).

I don’t think you really want to do that. What IOCTLs do you plan to
send?

I don’t want to use directX for a myriad of reasons.

In my not-very-humble opinion, you should rethink that decision.
DirectShow is incredibly flexible, and not all that hard to use.
There’s a fair amount of boilerplate code, but it’s all cut-and-paste.
With CComPtr and CComQIPtr, COM is pretty darned easy to do. I’ve
worked on a couple of cameras that do not have stream-class drivers, but

that support DirectShow via a user-mode source filter. Your solution
would miss those.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@viack.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Amitabh Mathrawala wrote:

I went ahead and tried to use STI to capture video by getting the
symbolic link (port name) of the underlying driver using
IStillImage::GetDeviceInfo.
According to the DDK I can use the port name inside the
STI_DEVICE_INFORMATION structure returned by IStillImage::GetDeviceInfo
to create a handle to the device and then send IOCTLs to the device get
raw video data.

Where does it say that? I couldn’t find it, and I don’t believe it anyway.

In my case, the port name that I am getting is “AUTO”
and that does not work with CreateFile (I tried “\.\AUTO”, “AUTO”,
“AUTO\0”).
Does anyone know what the port name of “AUTO” mean ? Does it mean that I
cannot open a handle to the device using createfile ?

The port name only meaningful on certain types of busses, to distinguish
devices that might otherwise be confused. Every STI driver I’ve ever
done has declared itself as “AUTO”. If you want a handle you can open
with CreateFile, you will have to use the SetupDi routines to scan the
video device class.

Even with that, though, I don’t know how you are going to fetch video data.

A followup question that I have is, is there any way I can capture video
data from my USB webcam without using directx, wia, or twain ? I don’t
mind writing a kernel mode driver (filter) if there is documented or
semi-documented way of doing it.

Why on earth would you be willing to go to the effort and danger of
writing a kernel driver, but discard the DirectShow approach?
DirectShow is a lot less trouble than a kernel driver. Web cameras are
streaming devices. There are protocols to follow to get them fired up
to the point where you can get frames. DirectShow and kernel streaming
understand that protocol, so you don’t have to.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Amitabh Mathrawala wrote:

This information about doing the createfile using the portname is there
in the 2600.1106 DDK under still image devices section. Look for this
topic to get this info : Accessing Kernel-Mode Drivers for Still Image
Devices.

This is talking about devices that adhere to the USB Still Image Class,
which is intended for scanners and single shot cameras. Such a device
is handled by the standard driver usbscan.sys, and that’s the driver
that responds to those ioctls. Streaming web cameras are not USB Still
Image Class devices, so I don’t think any of this is going to apply.

The reason I am still researching into this is because Directshow did
not ship with a certain service pack of win2000.

That’s not true. DirectX and DirectShow shipped with original Windows
2000, and no service pack ever uninstalled it.

However, it is an optional component. If a user deselected the video
and multimedia option when installing Windows 2000, DirectShow would not
be available. In that case, there are other components missing as well,
including parts of VFW.

The only option to get
video in 2000 seems to be using VFW which is horribly inefficient and
takes up 90% of the CPU on some camera models.

That does not match my experience, unless you are trying to do streaming
video as a series of single frame snapshots. When you do a VFW snapshot
operation on a driver without a native VFW driver, it sets up buffers,
turns on streaming, grabs one frame, turns off streaming, and releases
the buffers. That’s a lot of overhead. However, you can avoid that by
using the VFW streaming APIs instead, and just throwing away the frames
you don’t want.

To get around this
situation I am wondering if I can get video data in some other way. I am
wondering if I can get video data by opening a handle to the video class
driver and sending it the IOCTL_SEND_USB_REQUEST as described by the DDK.

IOCTL_SEND_USB_REQUEST is request for the USB Still Image class driver,
usbscan.sys. Streaming web camera drivers will not respond to this.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.