DirectShow技术介绍（长篇）-7

3.6. DirectShow中的时间和时钟

     这一节主要概述DirectShow体系中时间和时钟。

3.6.1. 参考时钟

    Filter Graph Manager的一个功能，能够以同一个时钟来同步所有在graph中的filter，称作参考时钟（reference clock）。

     任何暴露了IReferenceClock接口的对象都能够作为一个参考时钟来使用。参考时钟可以由一个DirectShow filter来提供，例如可以直接使用硬件时钟的audio renderer。另外，Filter Graph Manager也能使用系统时间来作参考时钟。

     名义上，一个参考时钟以千万分之一秒的精度来度量时间，但是实际上的精度不会这么高。要取得参考时钟的当前时间，调用IReferenceClock::GetTime方法。由于时钟的基准时间，即时钟开始时的时间计数，是依赖于具体的实现的，因此GetTime的返回值不反映绝对时间，只反映相对于graph开始时的相对时间。

     虽然参考时钟的精度是变化的，但是GetTime的返回值却保证是单调递增的，换句话说，也就是参考时钟的时间是不会回退的。如果参考时钟的时间是由硬件源产生的，而硬件时钟回退了（比如，有一个调节器调节了时钟），GetTime依然返回最晚的那个时间只到硬件时钟追上它。要知道更多的内容可以参考CBaseReferenceClock类（http://msdn.microsoft.com/library/en-us/directshow/htm/cbasereferenceclockclass.asp）。

   

    默认参考时钟

     当Graph运行时，FilterGraph Manager会自动选择参考时钟，选择参考时钟的规则如下：

     ＊如果应用程序指定了一个时钟，则使用这个时钟；

     ＊如果Graph包含了一个支持IReferenceClock的活动源filter（即推模式源filter），则使用这个filter；

     ＊如果Graph未包含任何支持IReferenceClock的推模式源filter，使用任何一个支持IReferenceClock接口的filter，选择的次序是从Rendererfilter开始依次向上。已连接的filter优先于未连接的filter被选。（如果这个graph会render一个音频流，则这个规则通常就会选择audio renderer filter来作为参考时钟）

     ＊如果没有filter支持合适的时钟，则使用系统参考时钟。

   

    设置参考时钟

     应用程序可以在FilterGraph Manager上调用IMediaFilter::SetSyncSource方法来选择时钟，只有在由于你有一个特殊原因想要选择自己的时钟时才需要这么做。

     想要让FilterGraph Manager不使用任何参考时钟，可以调用SetSyncSource，参数为NULL。比如，你需要尽可能快地来处理sample时，就可以这么做。要恢复黑认的参考时钟，在Filter Graph Manager上调用IFilterGraph::SetDefaultSyncSource方法。

     当参考时钟发生变化时，FilterGraph Manager会通知每一个filter调用它的IMediaFilter::SetSyncSource方法，应用程序无需调用filter的这个方法。

   

3.6.2. 时钟时间

    DirectShow定义了两种相关时间：参考时间(reference time)和流时间(stream time)

     ＊参考时间是一个绝对时间，由参考时钟返回

     ＊流时间是一个相对于graph最后开始时的相对时间

     ·当graph处于运行态时，流时间等于参考时间减去起始时间

     ·当graph处于暂停态时，流时间停留在暂停的那一刻

     ·在重新定位后，流时间被重设为0

     ·当graph处于停止态时，流时间无意义

     如果一个媒体样本有一个时间戳t，表示这个在流时间为t时被render，正因为这个原因，因此流时间也被叫做呈现时间（presentation time）。

     当应用程序调用IMediaControl::Run运行graph时，FilterGraph Manager调用每个filter的IMediaFilter::Run。为了补偿消耗在运行每个filter的时间总和，Filter Graph Manager会略微晚一点来定义起始时间。

   

3.6.3. 时间戳

     时间戳定义了媒体样本的起始和结束时间。时间戳有时被称作呈现时间（presentation time）。在阅读余下的文章时，一个必须记住的要点是并非所有的媒体格式都以相同的方式来使用时间戳。举个例子，并不是所有MPEG样本都被打上了时间戳，在MPEG Filter Graph中，时间戳在被解码前并非应用在每个帧上。

     当一个rendererfilter接收到一个样本时，它以时间戳为基准来确定render时间。如果样本来晚了，或者这个样本没有时间戳，那个filter就立刻render它，否则，filter就等在那直到合适的时机。（通过IReferenceClock::AdviseTime方法来等待样本的render时间）

     源filter和语法解析filte使用下列原则，在它们处理的样本上设置合适的时间戳：

     ＊文件回放：第一个样本被打上起始时间戳，为0，后面的时间戳由样本长度和回放速率来决定，这些都由文件格式来决定。分析文件的filter负责计算出合适的时间戳。例子见（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow/htm/avisplitterfilter.asp）

     ＊音视频采集：每个样本都被打上一个起始时间戳，这个时间戳与当它被捕获时的Stream time相同。应注意以下几点：

     ·从预览pin（Preview Pin）出来的样本没有时间戳。因为图像处理的延时，一个打上采集时间的视频帧总是会迟一点到达视频renderer。这会导致在进行质量控制时，renderer会丢弃部分视频帧。关于质量控制，参见（http://msdn.microsoft.com/library/en-us/directshow/htm/qualitycontrolmanagement.asp）

     ·音频采集：音频采集filter使用它自己的缓冲集，而并非使用音频驱动程序的。音频驱动以固定的时间间隔来填充采集filter的缓冲。这个时间间隔由驱动决定，通常不超过10毫秒。在音频样本上的时间戳反映的是驱动填充采集filter时的时间，因此会有偏差，尤其是当应用程序使用一个很小的缓冲区时。不过，媒体时间可以精确地反映缓冲区中音频样本的数量。

     ＊混合filter（Mux filter）：依赖于输出格式，一个muxfilter可能需要由它来产生时间戳，也可能不需要。举个例子，AVI文件格式使用固定的帧率而没有时间戳，因此AVI Mux filter假设那些样本在近似正确的时间内到达。如果样本没有在合适的时间间隔内到达，AVI Mux filter会插入一个长度为0的空样本，来表示一个丢失的帧。在文件回放时，新的时间戳在运行时如前面所述地那样产生。

     要在一个样本上设置一个时间戳，调用IMediaSample::SetTime方法。

     此外，filter还可以为样本指定一个媒体时间（media time）。在视频流中，media time表示视频帧的数量。在音频流中，media time表示包中的样本数量，比如，如果每个包包含以44.1KHz的采样率采集的一秒钟的音频，那么第一个包具有一个为0的媒体起始时间以及为44100的媒体终止时间。在一个可以定位的流中，媒体时间总是相对于流的起始时间，比如，假设你在一个15帧/秒的视频流上定位到2秒这个位置，那么定位后的每一个媒体样本的时间媒为0，但是它的媒体时间为30.

    Renderer和Mux filter能使用媒体时间通过检查是否有缺口来确定帧或样本是否被丢弃了。但是，filter不是一定要设定媒体时间。要设置媒体时间，调用IMediaSample::SetMediaTime方法。

   

3.6.4 实时源（LiveSource）

     实时源，也被叫做推模式源（pushsource），实时地接收数据，比如视频采集和网络广播。通常情况下，一个实时源不能控制数据到达的速率。

     一个filter被认为是实时源需要具有以下几点：

     ＊调用IAMFilterMiscFlags::GetMiscFlags方法时返回AM_FILTER_MISC_FLAGS_IS_SOURCE标记，并且至少有一个输出pin暴露IAMPushSource接口。

     ＊ filter暴露IKsPropertySet接口，并具有一个capturepin（PIN_CATEGORY_CAPTURE）。

   

    延时（latency）

     一个filter的延时是这个filter处理一个样本所需的时间总和。在实时源中，延时取决于保存样本的缓冲区大小。举个例子，假设graph有一个具有33ms延时的视频源和一个具有500ms延时的音频源，那么每个到达视频renderer的视频帧要比与之匹配的音频样本到达音频renderer早470ms，除非graph对这个差别进行补偿，否则音视频将会不同步。

     实时源可以通过IAMPushSource接口来进行同步。FilterGraph Manager并做同步工作除非应用程序通过调用IAMGraphStreams::SyncUsingStreamOffset方法来激活它。如果同步被激活，FilterGraph Manager通过IAMPushSource来查询每一个source filter，如果filter支持IAMPushSource，那么Filter Graph Manager调用IAMLatency::GetLatency来得到filter预期的延时（IAMPushSource继承自IAMLatency）。通过组合的延时值，filter graph manager决定graph中最大的预期延时，然后调用IAMPushSource::SetStreamOffset来给每一个source filter一个流偏移，以后filter会在产生时间戳时加上这个偏移。

     这个方法主要是为了实现实时预览，但是，注意实时采集设备（比如摄像头）的preview pin上是没有时间戳的，因此，要在一个实时采集设备上使用这种方法，你必须在capture pin上进行视频预览。

     通常，IAMPushSource接口被VFWCapture filter和音频采集filter(Audio capture filter)支持。

   

    速率匹配（RateMatching）

     如果rendererfilter和source filter使用不同的参考时钟，那么就会有问题，renderer可能比source要快，这就导致了数据的缺口，或则renderer比source慢，就会导致数据拥堵而样本丢弃。通常一个实时源无法控制速率，因此要求renderer来与source进行速率匹配。

     通常，只有audiorenderer实现速率匹配，因为声音回放的频率比视频更重要。要实现速率匹配，audio renderer必须排除以下几点：

     ＊如果graph没有使用一个参考时钟，那么audiorenderer不会去进行速率匹配（如果graph没有参考时钟，那么样本总是在到达时就被立刻render）。

     ＊另外，如果graph中有一个参考时钟，audiorenderer检测是否有一个实时源在上游，如果没有，audio renderer不进行速率匹配。

     ＊如果有一个实时源在上游，并且这个实时源在它的输出Pin上暴露IAMPushSource接口，audio renderer调用IAMPushSource::GetPushSourceFlags，并寻找以下标记：

     ·AM_PUSHSOURCECAPS_INTERNAL_RM，这个标记表示这个实时源拥有自己的速率匹配机制，因此audio renderer不进行速率匹配。

     ·AM_PUSHSOURCECAPS_NOT_LIVE，这个标记表示source filter并不是一个真正的实时源，即使它暴露了IAMPushSource接口，因此，audio renderer不进行速率匹配。

     ·AM_PUSHSOURCECAPS_PRIVATE_CLOCK，这个标记表示source filter使用一个私有的时钟来产生时间戳。在这种情况下，audio renderer速率匹配与时间戳会有冲突。（如果样本没有时间戳，那么renderer忽略这个标记。

     ＊如果GetPushSourceFlags返回没有标记（0），audiorenderer的行为依赖于graph时钟和样本是否拥有时间戳：

     ·如果audio renderer不是graph参考时钟，并且样本拥有时间戳，那么audio renderer速率匹配与时间戳会有冲突

      ·如果样本没有时间戳，audiorenderer尝试与输入的音频数据的速率进行匹配。

     ·如果audio renderer是graph参考时钟，它与输入的数据速率进行匹配。

     最后一种情况的原因如下：如果audio renderer是参考时钟，并且source filter使用同样的时钟来产生时间戳，那么audio renderer不会与这个时间戳进行速率匹配，因为如果它这样做了，导致的结果是，它等于在尝试与自己进行速率匹配，这将导致时钟偏差。因此，在这种情况下，renderer与输入的音频数据速率进行匹配。