CBaseFilter derived class plays video great, but the audio goes silent after a few seconds...

CBaseFilter derived class plays video great, but the audio goes silent after a few seconds...

• ds12will

  Update - I have put COutputQueues on both output pins, but the problem persists (although it the audio does run for a few more seconds than before).

  Question: do I need to implement any frame timestamping / synchronisation in a situation like this

  - Dave

  
  

• Doc Glazer

  Hi Mike,

  Thanks for the reply.

  The video does keep playing after the audio has stopped. However, the graph stop funtion does not work if the audio IO is connected - the graph just hangs. If I just connect the video IO, the graph start / stop functionality works fine.

  No, I'm not using COutputQueue to deliver the samples - I'll try that.

  Also, I'm using the same CCritSec for both the audio and video streams - should I consider using separate ones for the audio and video

  - Dave

  
  

• Tyler Frugia

  Hi Mike,

  thanks for the prompt reply.

  Releasing Samples:
  The InputPin calls release on the IMediasample just after it calls deliver on the output pin.
  Once the output pin has created a new sample and copied the buffers, I call release on the incoming sample.
  I then release the new sample after passing it to COutputQueue::Deliver.
  Is this the right way to do it

  Alternate renderers:
  I tried connecting a Null renderer to the audio output pin - I still only get 8 MediaSamples delivered at my input pin, and the graph still hangs when I press stop.
  i set the dump filter to write a txt file (which came out binary). the output file initially grows to 345kb, after which it stops growing. this I take to mean that the same 8 samples are delivered as before - this is backed up by the debug log output which reports 8 calls on inputPin->Receive. The graph still hangs when I press stop.

  
  CritSecs:
  I have created stream lock critsecs for the audio and video input pins. I lock the recieve methods of the input pins only.

  My filter class inherits from CCritSec - I use this lock at the start of CheckMediaType on each pin. I also call CAutoLock cObjectLock(m_pLock) at the start of the Pause and Run methods.

  
  Pin blocking:
  The input pins don't wait on each other for anything - they just call Recieve on the CBasePin, then Deliver on the output pin (before releasing the sample)

  
  Why oh why isn't there any example source code for a CBaseFilter anywhere!

  Regards, Dave

  
  

• King Gamo

  Errata:

  during debugging today I have noticed that the FGM just stops calling Receive on my Audio input pin after the 8th call. This behaviour is entirely consistant and reproducable. The FGM continues calling Receive on my Video input pin indefinately.

  Does this shed any light on the situation

  - Dave

  
  

• AuzzieFlyBoy

  Huh ...

  Can you confirm that the audio samples are getting released properly

  Does it make any difference if you connect the audio output pin to a different filter (like Null Renderer or Dump filter)

  You should use different critical sections for the two pins. That may be what's causing Stop to hang.

  Do your inputs pins wait on each other (i.e., do you get a video frame, wait for some audio data, and then do some processing with both samples )

  ----------------------------------------------------------------------------
  Mike Wasson, DirectShow SDK Documentation
  This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

  (c) 2006 Microsoft Corporation. All rights reserved.

  
  
  

• SunilKannan

  Does the video keep playing while the audio stops

  Also, are you using COutputQueue to deliver the output samples

  It's relatively easy to hang in a filter with > 1 output pin. This topic has some (very) general guidelines: http://msdn.microsoft.com/library/en-us/directshow/htm/threadsandcriticalsections.asp

  The two calls that block on purpose are IMemInputPin::Receive and IMemAllocator::GetBuffer. You could be hitting a situation where one of them is blocking and then deadlocking another thread. COutputQueue prevents Receive from blocking.

  
  

  ----------------------------------------------------------------------------
  Mike Wasson, DirectShow SDK Documentation
  This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

  (c) 2006 Microsoft Corporation. All rights reserved.

  
  
  

• VOEagain

  You're stumping me. The reasons that I can think why this might happen are:

  1. Someone is blocking inside Receive, either upstream of you or downstream of you.

  2. Samples are not getting released. If a filter is holding onto samples (or just failing to call Release) then GetBuffer will eventually block. It sounds like you're releasing samples correctly.

  3. Deadlock. The fact that Stop hangs sounds like a deadlock. The normal sequence is that CBaseFilter::Stop calls CBasePin::Inactive which unblocks Receive() by decommitting the allocators and making further calls to Receive fail.

  If you override methods like CBasePin::Inactive, call the parent method from inside your method. Also you can set the trace level to LOG_LOCKING in your filter to help debug CCritSec locking issues.

  4. One input pin is waiting on another for data. (But you said that's not the case.)

  5. You return S_FALSE or an error code from Receive, which tells the upstream filter to stop sending data.

  6. Misc weird bugs like, you decommit an allocator during streaming or something.

  Does the filter work if only the audio pin is connected I'm about out of useful suggestions!

  ----------------------------------------------------------------------------
  Mike Wasson, DirectShow SDK Documentation
  This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

  (c) 2006 Microsoft Corporation. All rights reserved.

  
  
  
• CBaseFilter derived class plays video great, but the audio goes silent after a few seconds...