正文
所谓Push模式，即Source filter自己能够产生数据，并且一般在它的Output pin上有独立的子线程负责将数据发送出去，常见的情况如WDM模型的采集卡的Live Source Filter；而所谓Pull模式，即Source filter不具有把自己的数据送出去的能力，这种情况下，一般Source filter后紧跟着接一个Parser Filter或Splitter Filter，这种Filter一般在Input pin上有个独立的子线程，负责不断地从Source filter索取数据，然后经过处理后将数据传送下去，常见的情况如File source。Push模式下，Source filter是主动的；Pull模式下，Source filter是被动的。而事实上，如果将上图Pull模式中的Source filter和Splitter Filter看成另一个虚拟的Source filter，则后面的Filter之间的数据传送也与Push模式完全相同。
那么，数据到底是怎么通过连接着的Pin传送的呢？首先来看Push模式。在Source filter后面Filter的 Input pin上，一定实现了一个IMemInputPin接口，数据正是通过上一级Filter调用这个接口的Receive方法进行传送的。值得注意的是，数据从Output pin通过Receive方法调用传送到Input pin上，并没有进行内存拷贝，它只是一个相当于数据到达的“通知”。再看一下Pull模式。Pull模式下的Source filter的 Output pin上，一定实现了一个IAsyncReader接口；其后面的Splitter Filter，就是通过调用这个接口的Request方法或者SyncRead方法来获得数据。Splitter Filter然后像Push模式一样，调用下一级Filter的Input pin上的IMemInputPin接口Receive方法实现数据的往下传送。
一个DirectShow的应用程序，至少会有两条线程：主线程和Filter用于数据传送的子线程。既然是多线程，就不可避免会出现线程同步问题。Filter的状态改变都在主线程中完成，Filter的数据相关操作都在数据线程中调用。各线程一些主要函数调用参考如下：
Streaming thread(s): IMemInputPin::Receive, IMemInputPin::ReceiveMultiple, IPin::EndOfStream, IMemAllocator::GetBuffer.
Application thread: IMediaFilter::Pause, IMediaFilter::Run, IMediaFilter::Stop, IMediaSeeking::SetPositions, IPin::BeginFlush, IPin::EndFlush.
Either: IPin::NewSegment.
这些函数切忌混合调用，否则会引起线程的死锁。另外值得注意的是，BeginFlush和EndFlush属于主线程调用，而不是数据线程调用。
6. Transform filter和Trans-in-place filter的区别
首先，这两种Filter是有共同点的，因为Trans-in-place filter本身就是从Transform filter中继承过来的。其次，我们要明白的是，Trans-in-place filter“尽力”使自己的Input pin和Output pin使用相同的Allocator，以免去一次Sample数据的memcpy。我们说“尽力”，就是说Trans-in-place filter也未必能够实现它的初衷。（如果Trans-in-place filter使用的Allocator是ReadOnly的，而Trans-in-place filter又要修改Sample的数据，则Trans-in-place filter的Input pin和Output pin将不得不使用不同的Allocator。）
Trans-in-place filter有一个protected的成员变量m_bModifiesData，默认值为true。如果你确信定制Trans-in-place filter不需要修改Sample数据，则将m_bModifiesData赋值为false，这样可以保证Input pin和Output pin使用相同的Allocator。
Trans-in-place filter的实现主要体现在以下三个函数：CTransInPlaceFilter::CompleteConnect、CTransInPlaceInputPin::GetAllocator和CTransInPlaceInputPin::NotifyAllocator。CompleteConnect中进行必要的重连（Reconnect），保证Trans-in-place filter的Input pin和Output pin使用相同的Media type。GetAllocator能够取得Trans-in-place filter下一级Filter的Input pin上的Allocator。NotifyAllocator“尽力”使Trans-in-place filter的Input pin和Output pin使用同一个Allocator。
7. IMediaSeeking的实现
IMediaSeeking的实现在Filter上，但应用程序应该从Filter Graph Manager上得到这个接口。在Filter级别，Filter Graph Manager首先从Renderer filter开始询问上一级Filter的Output pin是否支持IMediaSeeking接口。如果支持，则返回这个接口；如果不支持，则继续往上一级Filter询问，直到Source filter。一般在Source filter的Output pin上实现IMediaSeeking接口。（如果是File source，一般在Parser Filter或Splitter Filter实现这个接口。）对于Filter开发者来说，如果我们写的是Source filter，就要在Filter的Output pin上实现IMediaSeeking接口；如果写的是Transform filter，只需要在Output pin上将用户的接口请求往上传递给上一级Filter的Output pin；如果写的是Renderer Filter，需要在Filter上将用户的接口请求往上传递给上一级Filter的Output pin。
注意：为了保证Seek操作后Stream的同步性，如果实际实现IMediaSeeking接口的Filter有多个Output pin，一般仅有一个pin支持Seek操作。对于你定制的Transform filter，如果有多个Input pin，你需要自己决定当Output pin接收到IMediaSeeking接口请求时选择哪一条路径往上继续请求。
应用程序能够在任何时候（running, paused or stopped）对Filter graph执行Seek操作。但当Filter graph正在running的时候，Filter graph manager会先pause住，执行完Seek操作后，再重新run起来。
IMediaSeeking可以有如下几种Seek的时间格式：
TIME_FORMAT_FRAME Video frames.
TIME_FORMAT_SAMPLE Samples in the stream.
TIME_FORMAT_FIELD Interlaced video fields.
TIME_FORMAT_BYTE Byte offset within the stream.
TIME_FORMAT_MEDIA_TIME Reference time (100-nanosecond units).
但实现这个接口的Filter未必支持所有的这些格式。一般Filter都会支持TIME_FORMAT_MEDIA_ TIME，当使用其它的格式时，最好调用IMediaSeeking::IsFormatSupported进行一下确认。
对于Filter，不赞成使用IMediaPosition接口。IMediaPosition是用以支持Automation的（比如VB里面使用DirectShow），IMediaSeeking不支持Automation。
8. Filter的状态转换
Filter有三种状态：stopped, paused, running。paused是一种中间状态，stopped状态到running状态必定经过paused状态。paused可以理解为数据就绪状态，是为了快速切换到running状态而设计的。在paused状态下，数据线程是启动的，但被Renderer filter阻塞了。
paused与running两者间的状态转换，对于Source filter和Transform filter可以忽略不计，而对于Renderer filter（特别是Video renderer / Audio renderer）情形稍有不同。Renderer首先处理那个paused状态下Hold的Sample，当接收到新的Sample时，判断Sample上的时间戳。如果时间未到，Renderer会Hold住这个Sample进行等待。
Filter graph manager以从下到上的顺序对Filter进行状态转换，即从Renderer filter一直回溯到Source filter。这个顺序能够有效地避免Sample的丢失以及Filter graph的死锁。
Stopped to paused:首先从Renderer开始进行paused状态的转换。这时，Filter调用自己所有Pin的Active函数进行初始化（一般Pin在Active中进行Sample内存的分配，如果是Source filter还将启动数据线程），使Filter处于一种就绪状态。Source filter是最后一个完成到就绪状态转换的Filter。然后，Source filter启动数据线程，往下发送Sample。当Renderer接收到第一个Sample后就阻塞住。当所有的Renderer实现了状态转换，Filter graph manager才认为状态转换完成。
Paused to stopped:当Filter进入stopped状态时，调用自己所有Pin的Inactive函数（一般Pin在Inactive中进行Sample内存的释放，如果是Source filter还将终止数据线程）。释放所有Hold的Sample，以使上一级Filter的GetBuffer脱离阻塞；终止所有在Receive中的等待，以使上一级Filter的Receive函数调用返回。Filter在stopped状态下拒绝接受任何Sample。这样从Renderer filter往上一级一级脱离阻塞，当到达Source filter的时候，可以确保数据线程终止。
9. EndOfStream问题
当Source filter的所有数据都已经发送出去，则会调用下一级Filter的Input pin上的IPin::EndOfStream，直到Renderer filter。当这个Renderer filter的所有Input pin都被调用了EndOfStream，则向Filter graph manager发送一个EC_COMPLETE事件。仅当Filter graph中的所有Stream都发送了EC_COMPLETE事件，Filter graph manager才会将这个事件发送给应用程序。
在我们定制的Filter中，如果接收到了上一级Filter传过来的EndOfStream，则说明上面的数据已经全部传送完毕，Receive方法不须再接收数据。如果我们对数据进行了缓冲，则应确认缓冲中的所有数据都被处理完并往下发送了，然后再往下调用EndOfStream。Pull模式下，一般是Splitter filter或Parser filter发送EndOfStream，而且方向是往下的，Source filter上不会收到这样的通知。
10. BeginFlush、EndFlush、NewSegment问题
典型的情况，当进行MediaSeeking之后，会调用BeginFlush、EndFlush。一般在Input pin上实现这两个函数。
对于Filter开发者来说，Filter在被调用BeginFlush时需要做以下工作：
· 调用下一级Filter的BeginFlush，使其不再接收新的Sample；
· 拒绝接收上一级Filter的数据，包括Receive调用和EndOfStream调用；
· 如果上一级Filter正在阻塞等待空的Sample，此时需要让它脱离阻塞（通过析构Allocator）；
· 确保数据流线程脱离阻塞状态。
Filter在被调用EndFlush时需要做以下工作：
· 确保所有等待缓存的Sample被丢弃；
· 确保Filter上已经缓存的数据被丢弃；
· 清除没有发出去的EC_COMPLETE事件（如果这是一个Rendered input pin）；
· 调用下一级Filter的EndFlush。
还有一点：如果你必须在定制的Filter中为每个Sample打Time stamp，那么记住在MediaSeeking之后出去的Sample的Time stamp应该从0开始重打。
Segment是一段时间内具有相同的Playback rate的一组Sample，以NewSegment函数调用来表示这个Segment的开始。NewSegment一般在开始新的Stream的时候，或者用户进行了MediaSeeking之后，由Source filter（Push模式下）或Parser/Splitter filter（Pull模式下）发起，并往下层层调用，一直到Renderer filter。
在我们定制的Filter中可以利用NewSegment传递下来的信息，特别是对于Decoder。对于Audio renderer也是一个典型例子，它根据Playback rate和Audio实际的采样频率来对声卡产生输出。
11. Quality Control问题
Filter之间的数据传送，有时候过快，有时候过慢。DirectShow使用Quality Control来解决这个问题，即IQualityControl接口的两个函数（SetSink和Notify）。一般，Renderer filter在Filter上实现这个接口，而其他Filter在Output pin上实现这个接口。
上图为一般的Quality Control的处理过程。而能够调整发送速度的IQualityControl接口一般在Source filter（pull模式下为parser/splitter filter）上实现，Transform filter只是将Quality Message往上一级Filter传递。
应用程序可以实现自己的Quality Control Manager，然后通过调用SetSink方法设置给Filter。上述的处理过程就改变了，Quality Message直接发送给自定义的Manager。但一般并不这么做。值得注意的是，具体的Quality Control实现取决于实际的Filter，可能是调整发送速度，也可能会丢失部分数据。所以，请慎重使用Quality Message。
12. 对运行过程中Media type改变的支持
我们可以从CBaseInputPin::Receive中可以看到，Input pin每次在接收Sample的之前，一般都会进行CheckStreaming（如果当前Filter已经Stop或正在Flush或发生了RuntimeError，则拒绝接收Sample），然后将当前的Sample属性保存到protected的m_SampleProps成员变量中。描述Sample属性的是一个AM_SAMPLE2_PROPERTIES的结构，它有一个标记来表明当前Sample的Media type是否已经改变。如果Media type改变了，则进行CheckMedaiType看我们的Filter是否仍然支持它。如果不支持，则发出一个RuntimeError，并发送EndOfStream。
一个健全的Filter应该能够对运行时Media type的改变做出处理。在我们的Receive方法实现中，我们可以通过if (pProps->dwSampleFlags & AM_SAMPLE_TYPECHANGED)来判断Meida type是否已经改变；如果改变，我们需要根据新的Media type进行必要的初始化。
一个典型的案例：当Camcorder输入时，Audio的Media type可能改变。比如，Filter连接时Media type使用了MEDIATYPE_PCM，而在运行时又换成了MEDIATYPE_WAVE；或者连接时Audio的采样频率时44.1K，而在运行时却变成了48K；或者Camcorder的带子上本身保存了混合的44.1K和48K的Audio。