Strategies for High-bandwidth Isochronous USB with AVstream minidriver

Discussion in 'Windows Vista Drivers' started by Stan Mitchell, Jul 9, 2007.

  1. Hi All,

    I'm trying to implement a video capture pin that uses the Process dispatch
    to queue frame buffers. It then uses a separate thread to take a frame from
    the queue and initiate a frame read into it. The read completion routine
    does a KsPinAttemptProcessing call to keep the leading edge buffers coming.
    The frame buffer queue is 5 deep.

    The pin runs for about 20 frames before the calls to Process start to fall
    behind and there are errors on some of the iso packets. When it reaches this
    "stable" state, Process is called at approx 17ms intervals.

    The iso read is for 14x24K for a full frame so it should occur at 14ms
    intervals.

    Should this approach work?
    What can be changed to make the Process calls come in at a 14ms rate?

    Thanks for any suggestions,
    -Stan
     
    Stan Mitchell, Jul 9, 2007
    #1
    1. Advertisements

  2. I have made some progress on this.
    I believe my emphasis on _not_ making a copy of the incoming video stream
    was part of the problem.

    Now, the input stream uses separately allocated buffers and a queue. So far,
    this continuous reader has no difficulty keeping up with the incoming iso
    data. Ultimately, this data is copied into Avstream's frame buffers.

    However, there is still a mismatch between the incoming data rate and the
    rate at which Avstream calls the pin's Process dispatch. I'll post a new
    subject related to this matter.

    -Stan
     
    Stan Mitchell, Jul 11, 2007
    #2
    1. Advertisements

  3. The last part of my problem has been "solved". Actually, it was more a
    matter of becoming enlightened regarding factors that affect the rate at
    which the pin's Process dispatch is called. I have been using the simplest
    rendering circuit consisting of only the WDM Capture Filter and a DirectShow
    Renderer.

    It was the renderer portion of the circuit that was not able to keep up with
    the capture frames (fields). When the "render pin" command is used in
    GraphEdit, it selects the default Video Renderer which is a VMR that does
    not support hardware features of newer video cards. The current DirectShow
    documentation states that it is a 5 year old design. Instead, I have found
    that the filter graph has to be built manually to use the VMR-9 filter which
    provides the greatest hardware acceleration. With this renderer filter, the
    Process dispatch can easily keep up with iso high-bandwidth data.

    -Stan
     
    Stan Mitchell, Jul 17, 2007
    #3
    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.