‍多媒体处理,不可避免地要解决音视频的同步问题。DirectShow是怎么来实现的呢?我们一起来学习一下。

大家知 道,DirectShow结构最核心的部分是FilterGraphManager:向下控制Graph中的所有Filter,向上对应用程序提供编程接 口。其中,FilterGraphManager实现的很重要一个功能,就是同步音视频的处理。简单地说,就是选一个公共的参考时钟,并且要求给每个 Sample都打上时间戳,VideoRenderer或AudioRenderer根据Sample的时间戳来控制播放。如果到达 Renderer的Sample晚了,则加快Sample的播放;如果早了,则Renderer等待,一直到Sample时间戳的开始时间再开始播放。这 个控制过程还引入一个叫QualityControl的反馈机制。

下面,我们来看一下参考时钟(ReferenceClock)。所 有Filter都参照于同一个时钟,才能统一步调。DirectShow引入了两种时钟时间:Referencetime和Streamtime。前者是 从参考时钟返回的绝对时间(IReferenceClock::GetTime),数值本身的意义取决于参考时钟的内部实现,利用价值不大;后者是两次从 参考时钟读取的数值的差值,实际应用于FilterGraph内部的同步。 Streamtime在FilterGraph不同状态的取值为:

1.FilterGraph运行时,取值为当前参考时钟时间减去FilterGraph启动时的时间(启动时间是通过调用Filter上的IMediaFilter::Run来设置的);

2.FilterGraph暂停时,保持为暂停那一刻的Streamtime;

3.执行完一次Seek操作后,复位至零;

4.FilterGraph停止时,取值不确定。

那么,参考时钟究竟是什么东西呢?其实,它只是一个实现了IReferenceClock接口的对象。也就是说,任何一个实现了 IReferenceClock接口的对象都可以成为参考时钟。在FilterGraph中,这个对象一般就是一个Filter。(在GraphEdit 中,实现了参考时钟的Filter上会显示一个时钟的图标;如果同一个Graph中有多个Fiter实现了参考时钟,当前被 FilterGraphManager使用的那个会高亮度显示。)而且大多数情况下,参考时钟是由AudioRenderer这个Filter提供的,因 为声卡上本身带有了硬件定时器资源。接下来的问题是,如果FilterGraph中有多个对象实现了IReferenceClock接口, FilterGraphManager是如何做出选择的呢?默认的算法如下:

1.如果应用程序设置了一个参考时钟,则直接使用这个参 考时钟。(应用程序通过IMediaFilter::SetSyncSource设置参考时钟,参数即为参考时钟;如果参数值为NULL,表示 FilterGraph不使用参考时钟,以最快的速度处理Sample;可以调用 IFilterGraph::SetDefaultSyncSource来恢复FilterGraphManager默认的参考时钟。值得注意的是,这时 候的IMediaFilter接口应该从FilterGraphManager上获得,而不是枚举Graph中所有的Filter并分别调用Filter 上的这个接口方法。)

2.如果Graph中有支持IReferenceClock接口的LiveSource,则选择这个LiveSource。

3.如果Graph中没有LiveSource,则从Renderer依次往上选择一个实现IReferenceClock接口的Filter。如果连 接着的Filter都不能提供参考时钟,则再从没有连接的Filter中选择。这一步算法中还有一个优先情况,就是如果FilterGraph中含有一个 AudioRender的链路,则直接选择AudioRenderer这个Filter(原因上面已经提及)。

4.如果以上方法都找不到一个适合的Filter,则选取系统参考时钟。(SystemReferenceClock,通过CoCreateInstance创建,CLSID为CLSID_SystemClock。)

我们再来看一下Sample的时间戳(TimeStamp)。需要注意的是,每个Sample上可以设置两种时间戳:IMediaSample:: SetTime和IMediaSample::SetMediaTime。我们通常讲到时间戳,一般是指前者,它又叫Presentationtime, Renderer正是根据这个时间戳来控制播放;而后者对于Filter来说不是必须的,Mediatime有没有用取决于你的实现,比如你给每个发出去 的Sample依次打上递增的序号,在后面的Filter接收时就可以判断传输的过程中是否有Sample丢失。我们再看一下 IMediaSample::SetTime的参数,两个参数类型都是REFERENCE_TIME,千万不要误解这里的时间是 Referencetime,其实它们用的是Streamtime。还有一点,就是并不是所有的Sample都要求打上时间戳。对于一些压缩数据,时间戳 是很难打的,而且意义也不是很大(不过压缩数据经过Decoder出来之后到达Renderer之前,一般都会打好时间戳了)。时间戳包括两个时间,开始 时间和结束时间。当Renderer接收到一个Sample时,一般会将Sample的开始时间和当前的Streamtime作比较,如果Sample来 晚了或者没有时间戳,则马上播放这个Sample;如果Sample来得早了,则通过调用参考时钟的IReferenceClock:: AdviseTime等待Sample的开始时间到达后再将这个Sample播放。Sample上的时间戳一般由SourceFilter或 ParserFilter来设置,设置的方法有如下几种情况:

1.文件回放(Fileplayback):第一个Sample的时间戳从0开始打起,后面Sample的时间戳根据Sample有效数据的长度和回放速率来定。

2.音视频捕捉(Videoandaudiocapture):原则上,采集到的每一个Sample的开始时间都打上采集时刻的 Streamtime。对于视频帧,Previewpin出来的Sample是个例外,因为如果按上述方法打时间戳的话,每个Sample通过 Filter链路传输,最后到达VideoRenderer的时候都将是迟到的;VideoRenderer通过QualityControl反馈给 SourceFilter,会导致SourceFilter丢帧。所以,Previewpin出来的Sample都不打时间戳。对于音频采集,需要注意的 是,AudioCaptureFilter与声卡驱动程序两者各自使用了不同的缓存,采集的数据是定时从驱动程序缓存拷贝到Filter的缓存的,这里面 有一定时间的消耗。

3.合成(MuxFilters):取决于Mux后输出的数据类型,可以打时间戳,也可以不打时间戳。

大家可以看到,Sample的时间戳对于保证音视频同步是很重要的。VideoRenderer和AudioRenderer作为音视频同步的最终执行 者,需要做很多工作。我们或许要开发其它各种类型的Filter,但一般这两个Filter是不用再开发的。一是因为RendererFilter本身的 复杂性,二是因为微软会对这两个Filter不断升级,集成DirectX中其它模块的最新技术(如DirectSound、DirectDraw、 Direct3D等)。

最后,我们再来仔细看一下LiveSource的情况。LiveSource又叫Pushsource,包括 Video/AudioCaptureFilter、网络广播接收器等。FilterGraphManager是如何知道一个Filter是 LiveSource的呢?通过如下任何一个条件判断:

1.调用Filter上的IAMFilterMiscFlags::GetMiscFlags返回有AM_FILTER_MISC_FLAGS_IS_SOURCE标记,并且至少有一个Outputpin实现了IAMPushSource接口。

2.Filter实现了IKsPropertySet接口,并且有一个Captureoutputpin(Pin的类型为PIN_CATEGORY_CAPTURE)。

LiveSource对于音视频同步的影响主要是以下两个方面:Latency和RateMatching。Latency是指Filter处理一个 Sample花费的时间,对于LiveSource来说,主要取决于使用缓存的大小,比如采集30fps的视频一般采集完一帧后才将数据以一个 Sample发送出去,则这个Filter的Latency为33ms,而Audio一般缓存500ms后才发送一个Sample,则它的Latency 就为500ms。这样的话,Audio与Video到达Renderer就会偏差470ms,造成音视频的不同步。默认情况下, FilterGraphManager是不会对这种情况进行调整的。当然,应用程序可以通过IAMPushSource接口来进行Latency的补偿, 方法是调用IAMGraphStreams::SyncUsingStreamOffset函数。FilterGraphManager的实现如下:对所 有实现IAMPushSource接口的Filter调用IAMLatency::GetLatency得到各个Source的Latency值,记下所 有Latency值中的最大值,然后调用IAMPushSource::SetStreamOffset对各个Source设置偏移值。

这样,在SourceFilter产生Sample时,打的时间戳就会加上这个偏移量。RateMatching问题的引入,主要是由于 RendererFilter和SourceFilter使用的是不同的参考时钟。这种情况下,Renderer对数据的播放要么太快,要么太慢。另外, 一般LiveSource不能控制输出数据的速率,所以必须在Renderer上进行播放速率的匹配。因为人的听觉敏感度要大于视觉敏感度,所以微软目前 只在AudioRenderer上实现了RateMatching。实现RateMatching的算法是比较复杂的,这里就不再赘述。

看到这里,大家应该对DirectShow是如何解决音视频同步问题的方案有一点眉目了吧。深层次的研究,还需要更多的测试、Baseclass源码阅读,以及DirectShow相关控制机制的理解,比如QualityControlManagement等。