To AVStream or not to AVStream

Discussion in 'Windows Vista Drivers' started by Tom Udale, Oct 2, 2003.

  1. Tom Udale

    Tom Udale Guest

    I am involved in a USB2 camera project and am trying to decide if it makes
    sense to attempt to fit into the standard Microsoft video framework or to
    use a proprietary approach. A second company is making this camera for me
    and is going to be responsible for the driver. I will be responsible for
    integrating the result into our product. Both of us are broadly (albeit
    somewhat shallowly) experienced with writing KM/hardware driver code but
    have very little experience with the ins and outs of AVStream drivers.

    The camera has programmable image size and frame rate from 640x480 at ~60Hz
    to 640x1 at kHz. There are also much slower rates with integration and
    what-not. Also the pixel bit size can change from 8 to 10 bits depending on
    the pixel clock. There are various other bells and whistles. It is highly
    desirable handle images on a image by image basis in kernel mode for
    realtime processing purposes (this may even be essential at the highest
    frame rates).

    My question is, does it make sense to try and do this via a AVStream/KS1
    style driver or is it better to just create a completely proprietary
    interface to the driver? My gut reaction is to push for a AVStream style
    driver and we have experimented with this some using usbcam2. The problems
    thus far are (from the driver side) dealing with the custom properties for
    the camera and being a kernel streaming (or whatever the AVStream term is)
    server, and (from my client side) being a ks client. On the last point (ks
    client), I understand there is nearly zero documentation. I am prepared to
    hunker down with the docs and try to figure this out and (or) hire a
    consultant but if the answer is going to be "this won't work" then I can cut
    to the chase and just go for a proprietary interface. This would certainly
    be easier in the short run.

    If the answer is to go for the AVStream style device, are there any
    consultants reading this list who are familiar with such a project - both
    from the device driver side and the client side?

    Regards,

    Tom Udale
     
    Tom Udale, Oct 2, 2003
    #1
    1. Advertisements

  2. Tom Udale

    Max Paklin Guest

    My suggestion to you is to shoot for an AVStream driver.
    With the release of DX9 AVStream is well established technology. Many
    drivers I know of have been successfully developed based on AVStream.
    Besides, you get the whole lot of debugging and testing tools that you can
    utilize.

    The drawback of proprietary solution is that you driver won't work with
    anything, but your app.
    Given the device you are designing, I can see how many of your end users
    will try to use it with all sorts of third party apps (Netmeeting, Adobe
    editing stuff and what not).
    With custom driver you will have your users stuck with your app, which is
    almost never a good idea.

    The problem with AVStream driver is that it requires a relatively long
    learning curve.
    There are some people out there who can probably help you out with that.
    Contact me in private and I will try to give you some info on that.

    As for exposing the private guts of your driver and giving yourself a hook
    to customize your hardware, it is possible and frankly quite easy. Writing
    KS-based application (actually DirectShow based application or middleware)
    is also not terribly difficult and well documented. There are numerous
    samples on how it can be done. Take a look at Platform SDK. Samples are
    under $(MSSDK)\samples\multimedia\directshow\capture or
    $(MSSDK)\samples\multimedia\directshow\BDA.

    -- Max.
     
    Max Paklin, Oct 2, 2003
    #2
    1. Advertisements

  3. Tom Udale

    Tom Udale Guest

    Max,
    This is my sentiment also. My main concerns, besides the obvious learning
    curve issues, were primarily technical. Two characteristics of the camera
    in particular concern me.

    1) The frame rates. I really very much would like to have access to *each*
    image as close to the point in time that it enters the host computer as
    possible (i.e. minimal latency). The upper rates for this camera are in the
    2-3 kHz range. While I know that there may be hardware issues that I am not
    aware of, I am assuming that the USB minidriver will have access to these
    image boundries on the microframe time scale (i.e. 125uS). One serious
    concern with the AVStream framework is that additional internal frame
    delays, image queuing, or aggregation may be introduced such that the KS
    client (i.e. my kernel mode sink pin) will see either delayed images or
    groups of images at a lower rate.

    2) The programmability of the image format. The camera has a basically
    arbitrary image format. The frame rate, pixel bit depth, width, and height
    of the image are all programmable (by the way, it is a monochrome image).
    Will it be difficult to represent this in the AVStream framework? I have
    this horrible mental image of having to have a CMediaType for every possible
    combination of width, height, and bit depth and have the user select one
    through some 5000 element list box.

    Hopefully, this is just my ignorance being unable to come up with a work
    around. Although I do wonder, if we have to make a pile of workarounds and
    private interfaces to program the camera, will the utility of the driver to
    third parties not be lessened??
    Thanks. I will do that.

    Actually, I have written a user mode directx "bridge" filter that will sink
    images from a web cam I bought into the rest of my processing pipeline. I
    programatically construct a filter graph and connect my bridge to the
    capture pin of the camera. It all works smashingly.

    I am more concerned with the usb mini-driver (as discussed above), the
    usermode custom interface filter (for custom COM interfaces and property
    sheets), and the kernel mode equivelent to my "bridge" filter.


    Thanks so much for your input.

    Regards,

    Tom Udale
     
    Tom Udale, Oct 2, 2003
    #3
  4. Tom Udale

    Max Paklin Guest

    1) The frame rates. I really very much would like to have access to
    *each*
    AVStream is not standing between you and your hardware. It is a bridge
    between your driver and upper layers. So you will have an access to every
    piece of data delivered by your hardware as soon as it become available to
    the driver. AVStream won't add anything on top of that latency. That said I
    see no difference between proprietary driver model and AVStream.

    Scary thought.
    Check out IAMStreamConfig interface. It gives an application a chance to
    specify format of video/audio stream. Possible formats are represented as a
    range (from min.size to max.size, possible frame rates expressed in terms of
    min and max frame duration and so forth). Similar expression is used on the
    driver side to provide the data about supported formats.

    That's what many do currently.
    Video hardware is frequently customized by means of extensions to standard
    DShow filters. Applications are used to automatically provide those
    extensions (such as property pages) to the user without knowing what those
    page actually represent.

    These questions about extending KSPROXY coming up so frequently that I am
    currently in process of writing a paper and small (set of) sample(s) on how
    to do that.

    -- Max.
     
    Max Paklin, Oct 2, 2003
    #4
  5. Tom Udale

    Max Paklin Guest

    But recall, that in my situation, the immediate driver is being written
    I am not sure I understand what you are talking about here.
    AVStream is actually KS2.0. So it is superset of KS1.0. Whatever was
    supported before is still supported. I see no reason for you to use KS1.0
    kind of communication though.

    You want to talk from USB minidriver to AVStream minidriver or vice versa?
    Then AVStream won't be in your way.
    AVStream will help to represent your driver so that it fits nicely in
    DirectShow and therefore becomes available to applications. It is also a
    convinient framework for you operate in.
    If you want to talk an abitrary driver in the system AVStream won't help
    you, but it won't get in your way either. Just register an interface in
    either of these drivers and have the other one get that interface and
    exchange function pointers for direct communication. After that talking to
    another driver is as simple as calling a function.

    -- Max.
     
    Max Paklin, Oct 3, 2003
    #5
  6. Tom Udale

    Tom Udale Guest

    Max,
    I was not thinking of using KS1. I was just not sure that AVStream still
    had the idea of streaming data in kernel mode. It is clear now that it
    does.
    I see. That is one option for sure. From what you say above (that
    AVStream==KS2), I get the impression that exchanging pointers is not
    neccessary if the communication is simply controlling and getting data from
    the image stream.

    Thanks again. BTW, I sent an email to your hotmail account. Did you see
    it?

    Regards,

    Tom
     
    Tom Udale, Oct 3, 2003
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.