上文介绍了音视频同步，下面介绍一下时间戳、主时钟和如何调整主时钟去处理实时流。
时钟和流时间：
一个filter graph的所有filter，是和同一个时钟（参考时钟）同步的。流时间基于参考时钟，但是相对而言的，根据graph的状态而定。当graph暂停了，流时间是不会继续走的。当进行seek操作，流时间恢复为0。
Dshow有一个基本类CBaseReferenceClock ，提供IreferenceClock接口。这个基本时钟类，提供了2个内部时间：内部私有的时间和参考时间
内部私有时间是由时钟提供的真正的时间，通过GetPrivateTime得到。内部私有时间一段时间后，可以恢复。参考时间是基于私有时间，不能恢复。
filter提供的参考时钟，通常由CbaseReferenceClock类继承。可以重构GetPrivateTime函数，直接返回时间给设备。或者可以通过SetTimeDelta调整流时间，这时它会检查，系统时间和设备时间之间的差异。
CE缺省的参考时钟由音频渲染提供，可使用SetTimeDelta进行流时间的调整。改变filter graph内的参考时钟，filter graph调用ImediaFilter接口判断，然后通过SetSyncSource来改变参考时钟。
所有filter可以访问参考时间和流时间。CBaseFilter基类有个m_pClock成员，参考时间可以通过m_pClock->GetTime得到。流时间通过CbaseFilter一个成员函数StreamTime得到。
时间戳和流时间：
Filter graph传递的sample内，可能有时间戳，记录了媒体sample的开始和结束时间。时间戳用来配合流时间使用的。如果一个sample的时间戳比当前流时间要大，那就是这个sample提前了。如果sample的时间戳比流时间小，它就是延时了。在播放时，通常是splitter为sample加上时间戳。视频渲染使用时间戳，来决定是否开始显示和结束显示。当一个sample到达视频渲染时，可能有以下情况：
1、
2、
3、
参考时钟和音频渲染：
音频渲染提供了参考时钟，它把时间戳和流时间使用在不同方面。参考时钟给音频渲染做流时间的控制，所以参考时钟不会跟随音频渲染而变。
音频渲染收到sample后，准备把sample发送到音频驱动中。如果sample延时了，就会丢弃它。Sample没有延时，而且sample是有效的话，就会马上发送出去。音频渲染不会等到合适的时间才发送，所以媒体的sample不一定是连续的。一个sample的结束时间，可能比下一个sample开始时间要小，那么音频渲染会让驱动静音。总之，音频渲染会尽快的把sample发送出去。
当缺省的音频渲染结束了一个sample的操作，它会读取设备时钟和系统时钟，计算这2时钟之间的差异。但设备时钟是不能直接读取出来的，音频需要使用不太准确的函数amsndOutGetPosition。音频渲染会把时间差累计起来，使用一个低通filter。等到这些差异的平均值到达某一个界限时候，会通过SetTimeDelta函数来调整流时间，所以流时间也不是连续的。其他filter会使用m_pClock->AdviseTime来获取通知，当某一时刻的流时间到了，就能知道是否因为调整时间的动作，导致了流时间的改变。当流时间到了，这些filter会评估这个时间是否它们需要的。
实时采集和时钟保存
如果CE音频渲染不提供参考时钟，接受到sample后会进行写操作。CE中没有自动的slave模式，音频渲染不知道发送下一个sample前，需要等待多久。
对于实时流来说，音频驱动中有一个接口可以让我们调整音频驱动的速度，来配合实时采集。Source filter使用IAudioRenderer->SetDriftRate来控制音频的速度。这时，音频渲染作主时钟。
当音频渲染不能作主时钟时，而是作为音频驱动的一个slave模式的前置filter时。这个filter就需要负责sample的流控，大部分时间都是在发送sample到驱动。
http://blogs.msdn.com/medmedia/archive/2007/10/02/more-about-a-v-synchronization-in-dshow.aspx