知了博客

3.2. Filter Graph和它的组件
    这一节描述了DirectShow的主要组件，为DirectShow应用程序和DirectShow Filter开发者提供一个介绍。应用程序开发者可以忽略掉很多底层部分，但是，了解底层对于理解DirectShow架构还是很有帮助的。
3.2.1. 关于DirectShow Filter
    DirectShow使用一个模块化的架构，每个处理过程都由一个叫做filter的COM对象来实现。DirectShow为应用程序提供了一系列标准的filter，开发者也可以编写自己的filter来扩展DirectShow的功能。下面是播放一个AVI文件的各个步骤：
    ＊从文件中读取数据并转成字节流（File Source filter）
    ＊检查AVI头，分析字节流并将它们分离成视频和音频（AVI Aplitter filter）
    ＊将视频解码（不同的解码filter，取决于不同的压缩格式）
    ＊将视频显示出来（Video Renderer filter）
    ＊将音频送入声卡（Default DirectSound Device filter）




    如图所示，每个filter与一个或多个其它的filter相连，其中的连接点也是一个COM对象，称作Pin，filter使用Pin将数据从一个filter转移到另一个，图中的箭头指示了数据流动的方向。在DirectShow中，这一系列连接在一起的filter称作filter graph。
    Filter可能处于有三种不同的状态：运行、停止和暂停状态。filter在运行状态时处理数据，停止状态时停止处理数据，暂停状态则是表示就绪，可以开始进入运行状态。除了极个别的情况，一个filter Graph中的所有filter通常都处理同一个状态下，因此，filter graph也可以称其处于运行、停止、暂停状态。
    Filter可以被分成几个大的种类：
    ＊source filter - filter graph的数据源，这些数据可以来自文件、网络、摄像头或任何其它东西。每一个source filter操纵不同类型的数据源。
    ＊transform filter - 接收数据，处理数据并将它送入下一个filter。编码filter和解码filter都属于这个种类。
    ＊Renderer filter - 处于filter链的未端，接受数据并将其展现给用户。比如，一个视频renderer在显示器上绘制视频图像；一个音频renderer将音频数据送入声卡；一个写文件filter(file-writer filter)将数据存盘。
    ＊splitter filter - 分析输入的数据流并将其分解成两路或多路，比如，AVI splitter分析字节流并将其分解成视频流和音频流。
    ＊mux filter - 将多路输入流合并成一路。比如，AVI Mux正好与AVI splitter做相反的工作，它将视频和音频流合成为一个AVI格式的字节流。
    以上的分类并不是绝对的，比如，ASF Reader Filter同时充当了source filter和splitter filter的角色。
    所有的DirectShow filter都提供IBaseFilter接口，所有的Pin也都提供IPin接口。DirectShow也定义了许多其它的接口以实现特定的功能。


3.2.2. 关于Filter Graph Manager
    Filter Graph Manager是一个用以控制filter graph中的filter的COM对象。它提供了许多功能，包括：
    ＊协调filter之间的状态变化
    ＊建立参考时钟（reference clock）
    ＊将事件返回给应用程序
    ＊提供应用程序建立filter graph的方法
    这里先简单地描述一个这些功能。
    状态变化：filter们的状态变化必须遵照一个特定的次序，因此，应用程序不能将状态变化的命令直接发给filter，而是将一个简单的命令发给filter graph manager，由它来将命令分发给各个filter。定位命令同样使用这种方式，应用程序发送一个定位命令给filter graph manager，由它来分发。
    参考时钟：在filter graph中的所有filter都使用一个相同的时钟,称为参考时钟（reference clock）。参考时钟保证了所有流的同步。一个视频帧或一段音频样本被播放的时间钞称作呈现时间（presentation time）。呈现时间精确地相对于参考时钟。Filter Graph Manager通常选择的参考时钟是声卡参考时钟或系统时钟。
    Graph事件：filter graph manager使用一个消息队列来通知应用程序发生在filter graph中的事件。
    Graph-buliding 方法：filter graph manager提供给应用程序将filter加入到filter graph中的方法，以及将filter与filter连接或断开连接的方法。
    Filter graph manager不提供操纵在filter之间流动数据的功能，这个功能由filter通过pin连接在一个单独的线程中自行完成。
3.2.3. 关于媒体类型（Media Type）
    因为DirectShow是模块化的，因此需要有一个在filter graph各个点之间描述格式的方法。比如说，AVI回放，数据输入时是一个RIFF块的流，然后被分解成视频和音频流。视频流由一个个可能被压缩的视频帧组成，解压后，视频流又变成了一系列未压缩的位图。音频与视频类似。
    Media Type:DirectShow怎样来描述格式
    Media Type是描述数字媒体格式的常用方式。当两个filter连接时，它们需要协商决定同一个Media Type。Media Type标识了从上一个filter递交到下一个filter或物理层的数据流格式。如果两个filter对Media Type不能协商一致，则不能连接。
    对于某些应用程序，你不必去关心Media type，比如文件回放，DirectShow做了所有有关它的事情。
    Media type使用AM_MEDIA_TYPE结构体来定义，这个结构体包含了以下内容：
    ＊Major type：主类型，是一个GUID，定义了数据的整体类型，包括了：视频、音频、未分析的字节流、MIDI等。
    ＊Subtype：子类型，另一个GUID，进一步定义了数据格式。比如，如果主类型是视频，则子类型可以是RGB-24、RGB-32、UYVY等格式，如果主类型是音频，则可能是PCM或MPEG-1 payload等。子类型提供了比主类型更多的内容，但仍未提供完整的格式定义，比如，子类型没有定义图像尺寸和帧率，这些都将在Format block中被定义。
    ＊Format block：格式块，定义了具体的格式。格式块是AM_MEDIA_TYPE结构体中一个单独被分配的内存空间，pbFormat成员指向这块内存空间。因为不同的格式会有不同的格式描述，所以pbFormat成员的类型是void*。比如，PCM音频使用WAVEFORMATEX结构体，视频使用不同的结构体包括：VIDEOINFOHEADER和VIDEOINFOHEADER2。formattype成员是一个GUID，指定了格式块包含了哪种结构体，每一种格式的结构体都被分配了GUID。cbFormat成员定义了格式式块的长度。
    当格式块被定义时，主类型和子类型包含的信息就显得有点多余了。其实，主类型和子类型为识别格式提供了一个便利的方法，比方说，你可以指定一个普通的24位RGB格式（MEDIASUBTYPE_RGB24），而不需去关心VIDEOINFOHEADER结构体中诸如图像尺寸和帧率这些信息。
    下面是一个filter检查媒体类型的例子：

HRESULT CheckMediaType(AM_MEDIA_TYPE *pmt)
{
    if (pmt == NULL) return E_POINTER;
    // 检查主类型，我们需要的是视频
    if (pmt->majortype != MEDIATYPE_Video)
    {
        return VFW_E_INVALIDMEDIATYPE;
    }

    // 检查子类型，我们需要的是24-bit RGB.
    if (pmt->subtype != MEDIASUBTYPE_RGB24)
    {
        return VFW_E_INVALIDMEDIATYPE;
    }

    // 检查format type和格式块的大小.
    if ((pmt->formattype == FORMAT_VideoInfo) &&
         (pmt->cbFormat >= sizeof(VIDEOINFOHEADER) &&
         (pmt->pbFormat != NULL))
    {
        // 现在可以安全地将格式块指针指向正确的结构体。
        VIDEOINFOHEADER *pVIH = (VIDEOINFOHEADER*)pmt->pbFormat;
   
        // 检查pVIH (未展示). 如果正确，返回S_OK.
        return S_OK;
    }

    return VFW_E_INVALIDMEDIATYPE;
}
 

    AM_MEDIA_TYPE结构体还包含了一些任选项，用来提供附加的信息，filter不需要这些信息：
    ＊ISampleSize，如果这个字段非零，表示这是每个sample的尺寸，如果是零，则表示sample的尺寸会改变。
    ＊bFixdSizeSamples，如果这个布尔类型的标记是TRUE，表示ISampleSize有效，否则，你可以忽略ISampleSize。
    ＊bTemporalCompression，如果这个布尔类型的标记是FALSE，表示所有帧都是关键帧。

3.2.4. 关于媒体样本（Media Sample）和分配器（Allocator）
    Filter通过Pin与Pin之间的连接来递交数据，数据从一个filter的输出Pin转移到另一个filter的输入Pin，除了个别情况，实现这种功能通常的方法是调用输入Pin上的IMemInputPin::Receive方法。
    依靠filter，媒体数据的内存空间可以通过多个途径来分配：在堆上、在DirectDraw表面（surface）、在共享GDI内存或使用其它的分配机制。这个负责分配内存空间的对象称为分配器（Allocator），是一个暴露IMemAllocator接口的COM对象。
    当两个Pin相连时，其中的一个Pin必须提供一个分配器。DirectShow定义了一个方法调用序列来决定到底由哪个Pin来提供分配器。Pin还负责协商分配器创建的缓冲数和每个缓冲的尺寸。
    在数据流开始之前，分配器创建了一个缓冲池。在数据流动过程中，上游filter在缓冲中填入数据并递送给下游filter，但是，上游filter递送给下游filter的并不是原始的缓冲区指针，而是一个称为媒体样本（Media Sample）的COM对象，它由分配器创建并用来管理缓冲区，暴露IMediaSample接口。一个媒体样本包含：
    ＊指向下层缓冲区的指针
    ＊时间戳
    ＊各种标记
    ＊可选的媒体类型
    时间戳定义了呈现时间（presentation time），用以让renderer filter确定播放的合适时机。各种标记可以用来指示很多事情，比如，数据在上一个sample后是否被打段过（如重新定位、掉帧）等。媒体类型为流中间改变数据格式提供了途径，通常，没有媒体类型的sample，被认为从上一个sample以来数据格式没有被改变过。
    当filter使用一个缓冲时，它保存了sample上的参考计数。分配器使用参考计数来决定什么时候可以重用这个缓冲，这防止了一个filter在写一个缓冲时另一个filter还在使用这个缓冲，除非所有的filter都释放了这个缓冲，否则sample不会将其返回给分配器的缓冲池。
   
3.2.5. 硬件如何参与Filter Graph
    这一节描述了DirectShow如何与音频和视频硬件交互。
   
     外壳filter(Wrapper Filter)
    所有的DirectShow filter都是用户模式的软件组件。为了使象视频采集卡这样的内核模式的硬件驱动加入到filter graph中，必须使其象用户模式的filter那样。DirectShow提供外壳filter来完成这个功能，这类filter包括：Audio Capture filter、VFW Capture filter、TV Tuner filter、TV Audio filter和Analog Video Crossbar filter。DirectShow也提供一个叫KsProxy的filter，它可以实现任何类型的WDM流驱动。硬件商通过提供一个Ksproxy plug-in来扩展KsProxy，以使其支持自己的功能，ksproxy plug-in是一个被KsProxy聚合的COM对象。
    外壳filter通过暴露COM接口来实现设备的功能。应用程序使用这些接口将信息传递给filter，filter再把这些COM调用转化为设备驱动调用，将信息传递到内核模式下的设备中去，然后返回结果给应用程序。TV Tuner、TV Audio、Analog Video Crossbar和KsProxy filter都通过IKsPropertySet接口来支持驱动的自定义属性，VFW Capture filter和Audio Capture filter不支持这种方式。
    外壳filter使应用程序可以象控制其它directshow filter一样来控制设备，filter已经封装了与内核驱动通信的细节。
   
    Video for Windows Devices
    VFW Capture filter支持早期的VFW采集卡，当一个设备加入到目标系统中支后，它可以被directshow使用系统设备枚举器（System Device Enumerator）发现并加入到filter graph中去。
    音频采集（Audio Capture）和混音设备（声卡）（Mixing Device/Sound Card）
    较新的声卡都有麦克风等设备的插口，而且大多数这类声卡都有板级的混频能力，可单独控制每一个连接设备的音量及高低音。在directshow中，声卡的输入和混频设备被Audio Capture filter封装。每个声卡都能被系统设备枚举器发现。要查看你的系统中的所有声卡，只需打开GraphEdit，从Audio Capture Sources一类中选择即可，每个在这个类里的filter都是一个单独的Audio Capture filter。

    WDM流设备
    较新的硬解码设备和采集卡都遵照WDM规范。这些设备和比VFW设备更强大的功能，以及可以应用于多种系统（winxp,winNT,win2000,win98/me）。WDM视频采集卡支持许多VFW所没有的功能，包括枚举采集的格式、编程控制视频参数（如对比度、亮度）、编程选择输入端和电视调谐支持。
    为了支持WDM流设备，directshow提供了KsProxy filter（ksproxy.ax）。KsProxy被称为“瑞士军刀"，因为它可以做很多不同的事情。filter上pin的数量，以及COM接口的数量，取决于底层驱动的能力。KsProxy不以"KsProxy"这个名字显示在filter graph中，而是使用一个已在注册表中登记的设备名称。要查看你系统中的WDM设备，可以运行GraphEdit然后从WDM Streaming这个类别中选择。即使你的系统中只有一块WDM卡，这块卡也可能包含多个设备，而每一个设备都表现为一个filter，每个filter是实际意义上的KsProxy。
    应用程序使用系统设备枚举器在系统中寻找WDM设备moniker，然后调用moniker的BindToObject来实例化。因为KsProxy能够表现所有类型的WDM设备，因此它必须通过询问驱动来决定哪些属性是驱动所支持的。属性集是一组数据结构的集合，被WDM设备使用，也被诸如MPEG2软解码filter这样的用户模式filter使用。KsProxy通过暴露COM接口来配置自己，硬件商则通过提供插件来扩展KsProxy，插件暴露硬件商自定义的一些接口，用以实现特殊的功能。所有这些细节对于应用程序来说都是不可见的，应用程序通过KsProxy控制设备就象控制其它的DirectShow filter一样。
   
    内核流
    WDM设备支持内核流，在内核流中数据在内核模式下被彻底流化而永远不需要切换到用户模式下去，从而避免了在内核模式和用户模式之间切换的巨大开销，内核流允许高的比特率而不消耗CPU的时间。基于WDM的filter能够使用内核流将多媒体数据一个硬件设备送入到另一个中去，既可以是在同一块卡中也可以在不同的卡中，而不需要将数据拷入系统主存。
    从应用程序的视点来看，数据好象是从一个用户模式的filter传到另一个中去，但是实际上，数据根本就没有传到用户模式下过，而是可能支接从内核模式的设备中传到下一个中去直至被呈现（render）在显卡上。某些情况，比如采集视频到一个文件中去，在某些点上需要将数据从内核模式传入到用户模式，但是，仍然没有必要将数据拷贝到内存的一个新位置中去。
    应用程序开发者通常只需了解一个内核流的背景知识而不需要深究它的细节。



本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/eyes4/archive/2004/10/12/133117.aspx