Strategies for High-bandwidth Isochronous USB with AVstream minidriver

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
Wed Jul 11 08:45:20 CDT 2007

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" <stanlmitchell@NOSPAM.yahoo.com> wrote in message
news:eHdYD7jwHHA.5036@TK2MSFTNGP03.phx.gbl...
> 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
Tue Jul 17 13:48:08 CDT 2007

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" <stanlmitchell@NOSPAM.yahoo.com> wrote in message
news:uHYhdH8wHHA.3816@TK2MSFTNGP05.phx.gbl...
>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" <stanlmitchell@NOSPAM.yahoo.com> wrote in message
> news:eHdYD7jwHHA.5036@TK2MSFTNGP03.phx.gbl...
>> 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
>>
>
>