Why does GetDeliveryBuffer blocked with an INTERLEAVE_CAPTURE mode AVI Mux?

Question

I'm trying to use a customized filter to receive video and audio data from a RTSP stream, and deliver samples downstream the graph. It seems like that this filter was modified from the SDK source.cpp sample (CSource), and implemented two output pins for audio and video. When the filter is directly connected to an avi mux filter with INTERLEAVE_NONE mode, it works fine.

However, when the interleave mode of avi mux is set to INTERLEAVE_CAPTURE, the video output pin will hang on the GetDeliveryBuffer method (in DoBufferProcessingLoop) of this filter after several samples have sent, while the audio output pin still works well.

Moreover, when I inserted an infinite pin tee filter into one of the paths between the avi mux and this source filter, the graph arbitrarily turned into stop state after some samples had been sent (one to three samples or the kind). And when I put a filter that is just an empty trans-in-place filter which does nothing after the infinite tee, the graph went back to the first case: never turns to stop state, but hang on the GetDeliveryBuffer.

(Here is an image that shows the connections I've mentioned like)

So here are my questions:

1: What could be the reasons that the video output pin hanged on the GetDeliveryBuffer ?

In my guess it looks like the avi mux caught these sample buffers and did not release them until they are enough for interleaving, but even when I set the amount of video buffers to 30 in DecideBufferSize it will still hang. If the reason is indeed like that, so how do I decide the buffer size of the pin for a downstream avi muxer ?

Likely a creation of more than 50 buffers of a video pin is not guaranteed to work because the memory size cannot be promised. :(

2: Why does the graph goes to stop state when the infinite pin tee is inserted ? And why could a no-operation filter overcomes it ?

Any answer or suggestion is appreciated. Or hope someone just give me some directions. Thanks.

Answer 1

Blocked GetDeliveryBuffer means the allocator, you are requesting a buffer from, does not [yet] have anything for you. All media samples are outstanding and are not yet returned back to the allocator.

An obvious work around is to request more buffers at pin connection and memory allocator negotiation stage. This however just postpones the issue, which can very much similarly appear later for the same reason.

A typical issue with a topology in question is related to threading. Multiplexer filter which has two inputs will have to match input streams to produce a joint file. Quite so often on runtime it will be holding media samples on one leg while expecting more media samples to come on the other leg on another thread. It is assumes that upstream branches providing media samples are running independently so that a lock on one leg is not locking the other. This is why multiplexer can freely both block IMemInputPin::Receive methods and/old hold media samples inside. In the topology above it is not clear how exactly source filter is doing threading. The fact that it has two pins make me assume it might have threading issues and it is not taking into account that there might be a lock downstream on multiplexer.

Supposedly source filter is yours and you have source code for it. You are interested in making sure audio pin is sending media samples on a separate thread, such as through asynchronous queue.