AVStream vs USBVideo.sys

The more I understand, the less I know…

We are developing a custom medical video device which will run over USB. What I can glean so far is that, if the hardware guys were to develop the device according to the Video Class document available at USB.ORG, then the device will magically work (and woudl be accessible thru DirectShow calls)

Question 1: Is that correct?

I do not understand what AVStream is. It seems to be a superset of USBVideo.sys. There also seems to be an analogous construct for 1394, though I may be mistaken.

Question 2: If one has all of these specific constructs, for audio and video, for 1394 and for USB, what is the need or desire for AVStream?

Question 3: What would be the situations where someone would write an AVStream minidriver?

Question 4: If I were to write an AVStream minidriver for the device, would this free up the hardware guys to construct the device according to any whim of fancy, or would they still need to comply with the USB Video Device Spec in order to get AVStream to recognize it?

Thanks

Rick B.

> I do not understand what AVStream is. It seems to be a superset of USBVideo.sys.

AVStream (== Kernel Streaming 2.0) is just the kernel’s framework to write the drivers for audio/video capture and playback devices.

Actually, it is kernel-mode DirectShow.

USBVideo.sys, which services the spec-based USB Video class devices, is an AVStream driver.

Question 4: If I were to write an AVStream minidriver for the device, would this free up the hardware
guys to construct the device according to any whim of fancy,

Yes.

or would they still need to comply with the USB Video Device Spec in order to get AVStream to
recognize it?

Not necessary.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

xxxxx@gnotometrics.com wrote:

We are developing a custom medical video device which will run over USB. What I can glean so far is that, if the hardware guys were to develop the device according to the Video Class document available at USB.ORG, then the device will magically work (and woudl be accessible thru DirectShow calls)

Max’s answers were good – I only have a couple of things to add.

Do you expect your users to use DirectShow to access your device? I
happen to be a huge DirectShow fan, so I would certainly advocate for
designing a video-like device that worked in DirectShow, but if most of
your users will be writing custom applications where they just need to
access frames now and then under external stimuli, then it might suit
you better to design your own custom interface with a custom DLL to
implement it. DirectShow and AVStream are cool, but there are simpler
ways to design highly custom interfaces.

Question 1: Is that correct?

I do not understand what AVStream is. It seems to be a superset of USBVideo.sys. There also seems to be an analogous construct for 1394, though I may be mistaken.

As Max said, USBVideo.sys is an AVStream driver, as is USBAudio.sys.
It’s not that AVStream is a superset, it’s that AVStream defines an
interface, and USBVideo.sys happens to implement that interface.
AVStream is a driver model.

Question 2: If one has all of these specific constructs, for audio and video, for 1394 and for USB, what is the need or desire for AVStream?

There are lots of ways to build video devices other than USB. There are
still many PCI and PCIExpress video capture boards, and all of those
need custom drivers.

Question 3: What would be the situations where someone would write an AVStream minidriver?

Well, there is lots of hardware in the world that does not meet one of
the hardware specs with in-the-box driver support. Plus, the USB Video
Class spec lagged several years behind the wide availability of USB, so
many web cam families were designed that do not meet the spec.

Question 4: If I were to write an AVStream minidriver for the device, would this free up the hardware guys to construct the device according to any whim of fancy, or would they still need to comply with the USB Video Device Spec in order to get AVStream to recognize it?

If you write the driver, the hardware can look like anything. You just
need to write the AVStream callbacks that get the data into the system.

Note, however, that you can no longer get a Windows logo for a USB-based
video device that does not work with USBVideo.sys. If the logo is
important to your marketing department, then Video Class compliance
becomes a key design point for your hardware team.


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

Max, Tim:

Thanks for the reply. Much clearer.