所有标准的Microsoft系统过滤器似乎从IMemInputPin :: ReceiveCanBlock返回S_OK，表示它们可以阻止。甚至系统Null渲染器过滤器返回S_OK表示它可以阻止 - 所有过滤器肯定是最不可能阻止的，因为它只是丢弃样本？
是否有任何滤波器未在其输入引脚上阻塞？什么＆＃34;阻止＆＃34;在这种情况下真的意味着什
过滤器可能会无限期地保留样本，直到样本的呈现时间（如果暂停播放可能会很长时间）？
在返回Receive之前，过滤器可能需要花费不可忽略的时间来处理样本？
过滤器会在接收到的同一个线程上处理样本吗？
即使过滤器进程在工作线程上输入样本，大多数也会使用某种具有有限容量的排队机制，如果下游过滤器阻塞，最终可能会阻塞。
基类中的默认行为似乎是过滤器阻塞，除非它至少有一个连接的输出引脚，并且所有连接的输出引脚都连接到非阻塞的IMemInputPin引脚。如果没有非阻塞渲染器，那么任何其他滤波器如何不阻塞？
答案 0 :(得分：0)
整个想法被记录为向上游报告下一个样本将被无接受地接受的能力。当过滤器队列采样并异步提取它们时会发生这种情况。 BaseClasses在COutputQueue类中使用它来决定队列是否应该直接跳过排队并直接传递（如果没有保证阻塞行为）。过滤器不会启动工作线程并保存某些资源。
我认为过滤器不使用它，可能很少有例外。我能想到的一个不阻塞的过滤器不是渲染器（即使Dump / Null过滤器没有阻塞），它更像是一个转换过滤器 - 由于其自身的原因 - 使用工作线程的过程，例如：它在输入上对数据进行排队，因为处理是由线程池进行的，一旦线程处于空闲状态并为下一条数据做好准备，线程就会从队列中选择相同的数据。