WMPTalk.com

Jeremy Noring · Guest

Please excuse the posts to multiple groups--not sure which group this really
falls into, so I picked the two best fits.

I have a custom DirectShow source filter that reads samples off of the
network via an RTP stream. The source filter is derived from CSource, and
CSourceStream for the output pin.

When I use this filter, the graph looks like so:

Custom Source Filter -> WM DMO Decoder -> Video Mixing Renderer 9

The problem I'm having is that sometimes the call to Deliver() in my custom
source filter returns VFW_E_WRONG_STATE. The SDK indicates that this means
"the operation could not be performed because the filter is in the wrong
state." However, I haven't called Stop() on the graph, nor have I asked the
graph to "change state" at all--so what does this message mean?

I suspect that it means I'm handing samples to the Windows Media DMO Decoder
filter too fast and it's still processing the previous sample, but it's hard
to say...is there anyone here (someone from MSFT would be really, really
ideal, but beggars can't be choosers) who can give me a more precise
interpretation of this error for this particular scenario?

--
Where am I going?
And why am I in this handbasket?

Jeremy Noring · Guest

Does anyone have any information on this?

--
Where am I going?
And why am I in this handbasket?

Thore Karlsen [MVP DX] · Guest

On Thu, 16 Sep 2004 09:07:30 -0600, "Jeremy Noring"
<somewhere@thenet.com> wrote:

Jeremy Noring · Guest

Geraint Davies · Guest

wrong state is normal when the graph is stopping (since downstream filters
will be told to stop first, you are bound to be delivering when they are no
longer happy to receive). So normal, in fact, that if you just ignore it you
will behave like everyone else.

Why does the graph stop? Is it possible that a repaint has occurred when the
graph is stopped? This will cause the graph to pause and then stop again.

"Jeremy Noring" <somewhere@thenet.com> wrote in message
news:OUY8kdBnEHA.2552@TK2MSFTNGP11.phx.gbl...

Jeremy Noring · Guest

I figured out the solution--it was (as usual) something dumb that I'd done.
I had a loop with a hardcoded timeout running around in a circle collecting
samples from the network, and whenever I hit the timeout (rarely, but enough
to drive me nuts because the app would fail every hour or so) I'd end up
passing a bunk sample via the call to Deliver().

However to my credit (and if anyone from microsoft is listening), the error
being returned to me is totally worthless for troubleshooting the problem.
It'd be nice if more precise errors could be returned so one could get a
better idea of what the problem is. Had the error been VFW_E_INVALID_DATA
or VFW_E_BAD_SAMPLE, it would have been a lot easier to figure out.
Instead, I get some vague, fairly worthless return code that doesn't tell me
much.

This problem was clearly my fault--but it sure would have been nice to have
a more helpful return code. Maybe it would have been a couple hours instead
of a couple days of my time.

--
Where am I going?
And why am I in this handbasket?

	WMPTalk.com Forum Index -> SDK	All times are GMT
Page 1 of 1