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