[wdmaudiodev] Re: KS STATE PAUSE and Streaming

  • From: AI Developer <developer@xxxxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Fri, 19 Sep 2008 10:27:08 +0530

Very interesting. Something to keep in mind if we get involved with video streaming!

Thanks.
Devendra.

Tim Roberts wrote:
AI Developer wrote:

Are you sure about that? Sounds like a bug in the renderer if it expects a frame in paused state.

I am absolutely positive.  This is a well-known strangeness in DirectShow.  You can check the DirectShow code in CBaseRenderer.  It will not complete the transition to "paused" state until it either receives a frame, or gets an indication that the upstream filter cannot deliver one.

For a KS source, that's done by setting KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY in the the Flags member of KSPIN_DESCRIPTOR_EX:
    http://msdn.microsoft.com/en-us/library/aa509735.aspx

For a user-mode filter, that's done by returning VFW_S_CANT_CUE from IMediaFilter::GetState:
    http://msdn.microsoft.com/en-us/library/ms783300.aspx

As I said, the renderer relies on this behavior to put up a pretty "post" frame while the graph is still preparing.  This was done because of network latency.  When you are streaming a video from a network server somewhere, it makes a better user experience if you can display the first frame of the movie while you pre-fetch enough frames for smooth playback.


Seeing Neetu's later comment about Cancel request handling, could it be that in your case also, a cancel request is not being handled correctly? Perhaps the render is waiting for the request to be cancelled?

Not in the video case.  I guarantee it.


As for danger - yes there is a real danger. A lot of applications submit buffers in pause state, so that the driver has a queue of buffers ready when it switches to run state. Also, this way, the client could ensure that there's going to be enough "backup" of buffers during the time it takes to complete the request and to submit a new one. Reduces chances of buffer underruns.

Yes, but you're talking about "steady state" operation here.  The operation at startup is kind of a corner case.  On the other hand, you have convinced me that I could not possibly have been correct for the audio case.  The video case is different.


And of course, the WHQL tests will fail your driver (I know this as a fact for audio drivers) if you try to stream in paused state!

Yes, it appears that I erred in attempting to extrapolate from the video case to his audio behavior...
-- 
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
  

****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/

Other related posts: