Do DirectShow filters ever return S_FALSE from ReceiveCanBlock?

Question

All of the standard Microsoft system filters appear to return S_OK from IMemInputPin::ReceiveCanBlock to say that they can block. Even the system Null renderer filter returns S_OK to signify that it can block - of all filters surely this is the least likely to block since it just discards samples?

Do any filters not block on their input pins? What does "blocking" in this context really mean?

That a filter might hold onto a sample indefinitely until the sample's presentation time (which might be a long time if playback is paused)?

That a filter might take a non-negligible amount of time to process a sample before returning to Receive?

That a filter will process the sample on the same thread as it was received?

Even if a filter process input samples on a worker thread, most will use some sort of queueing mechanism with a finite capacity which could end up blocked if the downstream filter blocks.

The default behaviour in the baseclasses seems to be that a filter blocks unless it has at least one connected output pin and all of the connected output pins are connnected to non-blocking IMemInputPin pins. If there are no non-blocking renderers then how can any other filter be non-blocking?

Answer 1

The whole idea is documented as ability to report upstream that next sample will be accepted without blocking. Which in turn takes place when filter queues samples and fetches them asynchronously. BaseClasses use this in COutputQueue class to decide whether queue should just skip queuing and deliver directly (if no blocking behavior is guaranteed). A filter would not start a worker thread and save certain resources.

I suppose filter don't use this, with possibly rare exceptions. A filter that does not block, which I can think of, is not a renderer (even though Dump/Null filters do not block), it is rather a transformation filter which - for its own reasons - processes using worker threads, e.g. it queues data on the input because processing takes place by thread pool, and a thread would pick the same from the queue once its in idle state and ready for next piece of data.