Re: After running for hours, deadlocks on return m_pInputPin->Receive(pSample)
- From: dude <projeto.manager@xxxxxxxxxxxxxx>
- Date: Sun, 5 Jul 2009 09:03:46 -0700 (PDT)
On Jul 5, 4:52 pm, dude <projeto.mana...@xxxxxxxxxxxxxx> wrote:
On Jun 11, 11:12 am, Mechi <mec...@xxxxxxxxx> wrote:
Hi all!
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!
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.- Hide quoted text -
- 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.
.
- Follow-Ups:
- References:
- Prev by Date: Re: After running for hours, deadlocks on return m_pInputPin->Receive(pSample)
- Next by Date: entertain videos
- Previous by thread: Re: After running for hours, deadlocks on return m_pInputPin->Receive(pSample)
- Next by thread: Re: After running for hours, deadlocks on return m_pInputPin->Receive(pSample)
- Index(es):
Relevant Pages
|
