After running for hours, deadlocks on return m_pInputPin->Receive(pSample)
Mechi
After running my application for hours with fine video at a good
rate,
video continues streaming (the thread that receives the new frames
keeps on being called with new data) but
"return m_pInputPin->Receive(pSample)"
in Deliver() locks.
Thore Karlsen wrote a few years ago (in this forum):
> Trace even deeper, and see where in the Receive() call it's locked. Tell
> the debugger to use the Microsoft symbol server, and you'll be able to
> see meaningful names for the other functions in the call stack.
I haven't been able to catch it when it freezes. Also, when I did try
to enter the Receive() function, there is no code there that can be
opened.
I would love to write a ReceiveTimeout() function (or maybe someone's
done that already) so that if there's a problem delivering the
buffer,
the pSample would be returned, released and the filtergraph can be
rebuilt (without stopping the streaming from the camera).
> If I were to guess I'd say your timestamps weren't correct, and that the
> renderer is waiting for the presentation time. That's just a guess,
> though. What happens if you null out the timestamps?
I give timestamps in FillBuffer just because that's what Vivek's
example (VCam) does. I really don't need them, since I'm not
interested in playback.
> Or, it could be that you are keeping references to your samples around
> without releasing them, causing an infinite wait for a free buffer. That
> is also something to check out.
I overloaded DoBufferProcessingLoop() as is - just added in some
debugging messages. It's careful to release the buffer in every
situation.
I'd appreciate any other ideas - I've been looking through posts and
I
see other have had this problem - I'd like to hear how it was solved
at the end.
Thanks for any help,
Mechi
PS All the posts in this forum are VERY helpful - thanks again to all
the contributors!
Alessandro Angeli
> I haven't been able to catch it when it freezes. Also,
When it freezes, break all threads in the debugger and look
at the call stacks to find the stuck thread and discover
where it is stuck.
> when I did try to enter the Receive() function, there is
> no code there that can be opened.
Unless the filter the blocks is open source and you have its
source code, Windows and most commercial software is not
open source. At best, with Windows, you can look at the
symbols.
> I would love to write a ReceiveTimeout() function (or
> maybe someone's done that already) so that if there's a
> problem delivering the buffer,
> the pSample would be returned, released and the
> filtergraph can be rebuilt (without stopping the
> streaming from the camera).
IMemInputPin::Receive() is *not* a function provide by
DirectShow. It is a method implemented by each filter's
input pin instead. Unless you have the source code for the
filter and can change its implementation to support a
timeout (which would most likely require a custom interface
to replace or extend IMemInputPin that only your code knows
about), you can not change its behavior.
This kind of blocks is not supposed to happen unless there
is a bug in the pipeline (in your code or in some other
filter) that makes some allocator run out of buffers or the
timestamps to jump far far ahead in the future (or some
internal deadlock).
If you are serious about forcefully unblocking
IMemInputPin::Receive() you should start a timer just before
you call it in your output pin and, if the timer expires
before IMemInputPin::Receive() returns, flush the receiving
pin (IPin::BeginFlush() and so on). Flushing should unblock
the pipeline (unless some downstream filter is deadlocked,
in which case there is nothing you can do), but there is no
guarantee (after all, this is not how flushing is supposed
to be used).
Instead of flshing, you can also notify an
EC_DISPLAY_CHANGED, specifying the receiving pin, so that
the pins are reconnected. Since the default handling
includes a stop of the whole graph, that should unblock the
pipeline.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
dude
You may have a memory leak in the m_pInputPin->Receive(pSample)
function.
Did you open the windows task manager and checked the mem usage of the
process?
If you don't have the source code for that Receive, then you are
screwed. It's better to write your own filter and replace the one with
the leak.
dude
>
> - Show quoted text -
Forget about the memory leak. It would not block receive anyway. But
you still need the source code to insert some debugging message
throughout so you can find out the blocked call.
Mechi
> Instead of flshing, you can also notify an
> EC_DISPLAY_CHANGED, specifying the receiving pin, so that
> the pins are reconnected. Since the default handling
> includes a stop of the whole graph, that should unblock the
> pipeline.
>
> --
> // Alessandro Angeli
> // MVP :: DirectShow / MediaFoundation
> // mvpnews at riseoftheants dot com
> //http://www.riseoftheants.com/mmx/faq.htm
Hi!
Thanks for your answer.
I'd love to understand how to "notify EC_DISPLAY_CHANGED, specifying
the receiving pin" - because this seems to be the way to unblock the
pipeline.
Thanks,
Mechi
Mechi
> Forget about the memory leak. It would not block receive anyway. But
> you still need the source code to insert some debugging message
>
> - Show quoted text -
Thanks for your response.
I know that sometimes the camera may freeze. I would like to put a
timeout and then to "unblock it".
There is no source code for the Receive function.
Any other ideas?
Thanks!
Mechi