xxxxx@hotmail.com wrote:
AVStream is something new for me. I game with it just some days.
Before I build my driver, I do some probes with Avshws example.
But the Architecture isn’t clear enough.
I’ll thank you if you can refer me to any useful docs or book regarding AVSream.
There are no books, as far as I know. The MSDN documentation is pretty
good reference material, but I have never found a good “principles of
design” document.
I will also appreciate you a lot if you can help me with some questions:
- Why I can’t use WDF driver for Video device? I mean, to get logo & certification. that i can’t get if i stay unclassified!
what is the problem with it ?
It is much easier to me to do that by WDF.
Much of what WDF provides is already being provided by the AVStream
framework. It’s already handling the dispatching, and a lot of the PnP
and power management stuff for you. The two frameworks would fight with
each other.
It is certainly possible to write an AVStream driver using KMDF’s
“miniport” mode, where KMDF does not handle PnP and power management.
Some people have done that so they can use the KMDF USB abstraction.
However, the KMDF USB stuff does not handle isochronous pipes, which are
essential to video drivers. Because of that, there’s little point to it.
- It is not clear what is the buffer life cycle. where the buffer allocated? how disalocated?
If the “filter” in the user mode(GraphEdit ) allocates it or the KS ?
How it managed ?
who and when sends the buffer from user mode to kernel?
Which component in the Driver gets the buffer, Filter / Pin ?
In general, you don’t worry about that. It will usually be some
user-mode component in the graph that allocates the buffers, based
partly on the allocation information you provide in your driver. In the
case of DirectShow, it is ksproxy.ax that sends the buffers through
ioctls, and the AVStream framework handles the locking. The “Process”
callback gets the buffers. For a pin-centric filter, it’s the pin’s
Process callback. For a filter-centric filter, it’s the filter’s
Process callback. All of the video drivers I’ve done have been pin-centric.
- Where can i read about IHV plug-in (MFT) ? any example …
IS there something similar mechanizm in Driectshow ?
I’ve been building AVStream camera drivers for a dozen years, and so far
MFT has never been relevant. DirectShow can use MFT transforms. That’s
about all I know.
- Any doc or example to use manual IOCTLs ? what it should be COM object or other ?
Not sure what you mean. If you want to add your own private
capabilities, the right way is to add a custom KS property set. Then,
you can use the standard IKsControl interface to send them to the
driver. You can even add your own proxy plugin, so that your clients
can use a friendly COM interface that you invent instead of sending
IKsControl requests directly.
- Is each filter created in AVStream Driver should create/attach its own pin?
or it possible to create two filters (in AVStrem driver) that attach the same shared pin ?
or it possible to create one Filter attach two different pins (in AVStrem driver) ?
If you understand DirectShow, then the AVStream architecture is much
easier to understand. A filter has 0 or more pins. In the avssamp
sample, for example, the filter has a video pin and an audio pin, for a
camera with a microphone. A pin always belongs to one filter, however.
Sharing doesn’t usually make sense. A camera only has one output
stream, so you’ll have one filter with one output pin. You can have
multiple applications create instances of the filter – each with its
own pin – but only one of them can be streaming at once.
As a AVSream begginer, I should notice that the AVStream Architecture / Mechanizm isn’t intuitive at all. In addition the theme suffers from lack of doc. So I sorry if some questions are strange or seems not reasonable. I’m in learning phase.
Multimedia is complicated, and drivers are complicated. There’s no way
around it. That complexity is what has allowed an architecture that was
originally designed in roughly 1994 to support the vast number of
technology advances that have occurred since then. I stand in awe of
the designers of DirectShow and AVStream; they had some people who
really knew how to think about the future.
If you have experience with DirectShow, then AVStream is much more
intuitive. If you’re just starting in multimedia, then starting in a
driver is probably not the best place. There is actually a large amount
of reference material on AVStream on MSDN, although there’s not a lot of
“how-to” material. For that, you have to start from the samples and
interpolate.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.