Flash动画由于可以很方便地把用户的想象通过动画显现出来，使原本只属于专业制作人员的动画制作变的异乎寻常的快捷、方便。由于Flash制作的动画在层次、内容、表现形式等诸多方面均比较出色，因此在网络上得到迅猛的发展，更有不少厂商用Flash在互联网上做起了广告和产品演示，效果丝毫不比视频的差，而体积则要小的多。Flash不仅在网络上有广泛的应用，在普通的应用程序中也可以借助Flash实现一些VC、Delphi等编程语言所难以实现的特效，比如在一些演示版的程序中完全可以将程序运行前的闪屏用Flash来制作。本文下面将通过对内嵌资源的动态释放来实现VC对Flash动画的播放，并给出了部分实现代码。
Flash动画在此是作为程序的一个模块，虽然也可以以文件的形式作为一个外部资源来使用，但为了避免因外部模块遗失而造成程序的非正常运行，可将由Flash 5.0预先制作好的swf格式的文件以资源的形式打包到应用程序中去，而在程序运行时再将其从资源恢复到文件，使用完毕再通过程序将其从磁盘删除。
在导入资源时由于swf格式文件并非VC的标准资源，所以在导入时需要在"Resource type"栏指定资源类型"SWF"，特别需要注意的是在此必须要包含引号。加入到资源后可以通过资源视图看到导入的SWF资源是以二进制形式保存的，一但加入就不能再通过资源视图对其进行编辑了。
在使用SWF资源前首先要将其动态从应用程序中释放到文件中才可对资源做进一步的使用。可先通过宏MAKEINTRESOURCE（）将资源标识号IDR_SWF转换成字符串Name，再分别通过FindResource()、LoadResource()函数查找、装载该资源到内存：
CString Type="swf"；
HRSRC res=FindResource (NULL,Name,Type);
HGLOBAL gl=LoadResource (NULL,res);
当资源加载到内存后，还要通过对资源内存的锁定来返回指向资源内存的地址的指针，并籍此实现资源从内存到磁盘的保存，至于存盘的操作则由文件函数CreateFile()、和WriteFile()来完成：
LPVOID lp=LockResource(gl); //返回指向资源内存的地址的指针。
CString filename="Temp.swf"； //保存的临时文件名
// CREATE_ALWAYS为不管文件存不存在都产生新文件。
fp= CreateFile(filename ,GENERIC_WRITE,0,NULL,CREATE_ALWAYS,0,NULL);
DWORD a;
//sizeofResource 得到资源文件的大小
if (!WriteFile (fp,lp,SizeofResource (NULL,res),&a,NULL))
return false;
CloseHandle (fp); //关闭句柄
FreeResource (gl); //释放内存
通过上述代码，可将SWF资源从应用程序中提取并释放到临时文件Temp.swf中，在此后只对此临时文件操作，与程序内嵌资源无关。
swf格式的Flash动画通常主要应用在网页上，也就是说IE浏览器本身可以支持Flash动画的播放。这样就不必再单独编写用于播放swf文件的代码，从而大大减少编程的工作量。在VC ++ 6.0中新增了一个从CView派生的、用于处理网页的视类CHtmlView，由于该类是以Internet Explorer为后台支持，因此在创建工程时只需在最后一步指定视类从CHtmlView派生就可以使程序不编一行代码而具备IE浏览器的网页显示能力。
程序刚生成的时候缺省的连接主页是为微软公司的主页，需要对此修改，使程序在执行时立即显示刚才提取出来的Flash临时文件Temp.swf。显示缺省主页的代码是在视类的初始化函数中进行的：
void CEmbedModuleView::OnInitialUpdate()
{
CHtmlView::OnInitialUpdate();
Navigate2(_T("http://www.microsoft.com"),NULL,NULL);
}
显然要将Navigate2（）函数的第一个参数改成Temp.swf的存放路径。刚才在释放资源到文件时并没有指定绝对路径，因此释放出来的资源文件应当和应用程序处于同一目录。但是在此处如果不写明绝对路径是无法显示该临时文件的。获取该临时文件的绝对路径可用如下方法实现：先获取应用程序本身的绝对路径，然后去处应用程序全名（程序名和扩展名）此时得到的是应用程序和临时文件所处文件夹的路径，最后只需在此基础上加上临时文件的文件名Temp.swf即可得到临时文件的全路径。下面是实现的主要代码：
//获取应用程序的全路径
char exeFullPath[MAX_PATH];
GetModuleFileName(NULL,exeFullPath,MAX_PATH);
//将其格式化为字符串
m_TempFile.Format("%s",exeFullPath);
//去掉应用程序的全名（15为应用程序文件全名的长度）
exeFullPath[m_TempFile.GetLength()-15]='\0';
//得到应用程序所在路径
m_TempFile.Format("%s",exeFullPath);
//得到临时文件的全路径
m_TempFile+="Temp.swf";
最后将得到的临时文件的全路径m_TempFile作为参数传递给Navigate2（）即可在程序运行时把Flash动画作为主页而显示（如下图所示）。
由于临时文件Temp.swf是在程序运行过程中从应用程序的资源中提取出来的，因此在程序退出之前需要将其删除。一般是在消息WM_DESTORY的响应函数里通过DeleteFile()函数来加以实现的。
本文通过对CHtmlView和内嵌资源的动态释放实现了Flash动画在VC程序中的播放，并对资源的动态释放作了较为清晰的描述。通过类似的方法，可以将动态链接库、HTML文件等程序模块作为资源嵌入其中，在使用时再动态释放到临时文件，这样可有效避免文件模块过多时的杂乱以及程序模块丢失导致程序非正常运行等情况的发生。本文所述程序在Windows 98下，由Microsoft Visual C++ 6.0编译通过。Flash动画由 Macromedia Flash 5.0制作，所需浏览器支持为Internet Explorer 6.0。
流媒体的定义很广泛，大多数时候指的是把连续的影像和声音信息经过压缩处理后放上网站服务器，让用户一边下载一边观看、收听，而不需要等整个压缩文件下载到自己机器就可以观看的视频/音频传输、压缩技术。流媒体也指代由这种技术支持的某种特定文件格式：压缩流式文件，它通过网络传输，并通过个人电脑软件进行解码。
MCI是微软为Windows最初提出的多媒体编程接口，随着多媒体技术的迅速发展，各种压缩算法在该领域的的应用，MCI技术越来越显的力不从心，最明显的是它不支持可变比特率的压缩算法，对于处理DVD等近年出现的多种新的媒体格式已显得无能为力，而使用微软提供的vfw之类的多媒体库又太麻烦。怎么办呢？
作为MCI的"接班人"，微软又适时推出了建立在DirectX（包含DirectDraw、DirectSound、Direct3D）之上的DirectShow技术，它是在DirectX之上的媒体层，支持来自本地或网络的各种视频、音频压缩格式的媒体文件的解码和回放，可以从设备上捕捉多媒体流，也可以处理各种压缩算法处理的流媒体。这些格式包括：MPEG的音频和视频标准、音频和视频交互标准（AVI）、WAVE、MIDI和高级流格式ASF。DirectShow对媒体数据处理采用流媒体（Multimedia Stream）的方式，在应用中使用该方式可以大大的减少编程的复杂程度，同时又可以自动协商从数据源到应用的转换，流接口提供了统一的、可以预测的数据存取的控制方法，这样应用程序在播放媒体数据时不需要考虑它最初的来源和格式。
DirectX是一个用于多媒体应用程序和硬件增强的编程环境，它是微软为了将其Windows建设成适应各种多媒体的最好平台而开发设计的。DirectX目前已经成为微软自身SDK的一部分，而Windows 98/Windows 2000内则集成了DirectX，表明它已成为操作系统的一部分。
DirectX技术是一种API（应用程序接口），每个DirectX部件都是用户可调用的API的总和，通过它应用程序可以直接访问计算机的硬件。这样，应用程序就可以利用硬件加速器（Hardware Accelerator）。如果硬件加速器不能使用，DirectX还可以仿真加速器以提供强大的多媒体环境。
为了理解DirectX，我们可以把系统分为四层：
●硬件/网络层：放置有多媒体设备，包括图形加速器、声卡、输入设备以及网络通信设备等；
●DirectX基础层：为图像、声音和设备提供多媒体基本服务；
●DirectX媒体层：为动画制作、音频和视频等提供API功能；
●组件层：包括ActiveX控制和应用，它利用DirectX的API功能的优势为用户提供多媒体服务。
DirectShow就是建立在DirectX媒体层之上的技术，其前身是ActiveMovie2.0。它以一组API函数或ActiveX控件出现，用途是让开发者能够在网络上传递高质量的音频和视频信号。值得一提的是，DirectShow为我们提供了一个开放式的开发环境，我们可以根据自己的需要定制组件。
DirectShow定义了如何利用标准组件来处理流媒体数据，这些组件称为过滤器。过滤器带有输入、输出针角(pin)，或二者兼而有之。在DirectShow技术中处于最核心位置的就是作为"过滤器"的可插入标准组件，它是执行特定任务的COM对象。过滤器又可被细分为源过滤器（Source filter）、变换过滤器（Transform filter）、表现过滤器(Renderer filter)等。过滤器通过向文件读写、修改数据和显示数据到输出设备上来操作流媒体。为了完成整个任务，必须要将所有的过滤器Filter连接起来，这三种过滤器组成了过滤器图表结构，如图3.1所示：
图3.1 过滤器图表结构(Filter Graph)
从图3.1中可以看出，过滤器图表是各种过滤器的集合，它是通过过滤器的输入输出针脚"pin"顺序连接而成的，这些过滤器的针脚通过协商来决定它们将支持何种形式多媒体。由于DirectShow支持可重构的过滤器图表结构，所以使用相同的软件组件可以播放多种类型的媒体。开发人员可以通过定义自己的过滤器来扩展DirectShow对媒体的支持功能。
在过滤器图表结构中，源过滤器用来从数据源获取数据，并将数据传送到过滤器图表中，这里的数据源可以是摄像机、因特网、磁盘文件等；转换过滤器用来获取、处理和传送媒体数据，它包括分离视频和音频的分解变换过滤器（Splitter transform filter）、解压视频数据的视频转换过滤器（Video transform filter）、解压音频数据的音频转换过滤器（Audio transform filter）；表现过滤器用来在硬件上表现媒体数据，如显卡和声卡，或者是任何可以接受媒体数据的地方，如磁盘文件。它包括用来显示图像的视频表现过滤器（Video renderer filter）、将音频数据送到声卡上去的音频表现过滤器(Audio renderer filter)。
在过滤器图表中，为了完成特定的任务，必须将所有需要的过滤器连接起来，因此前级过滤器的输出必定成为下级过滤器的输入。一个过滤器至少有一个输入针（Input pin），并将特定的输出送到输出针（Output pin）；图3.2显示了一个过滤器连接图：
3.2 过滤器连接图
你的应用程序不需要对过滤器图表中的各个过滤器进行单独的处理，因为在更高的层次上，DirectShow提供的一个称为过滤图表管理器的部件（FGM）管理着这些过滤器的连接和流媒体数据在过滤器之间的流动，FGM提供了一套COM接口，应用程序可以通过它来访问过滤器图表、控制流媒体或者接收过滤器事件。如果需要，它可以自动的插入一个合适的解码器，并将转换过滤器的输出针脚连接到表现过滤器。应用程序可以通过与过滤图表管理器的通信来控制过滤器图表的活动。程序开发人员只需要调用API函数来实现对流媒体的控制，如run方法启动流媒体在过滤器图表（Filter graph）中的流动；pause方法暂停流媒体的播放；stop方法停止播放流媒体等。
另外，利用Filter Graph Manager能够将事件信息传送到应用层这一特点，可以使应用程序可以响应事件处理，例如播放或搜索流媒体中的特定时间段的数据、流结束信息等。
图3.3是一个MPEG解码播放的实例，可以看出Source filter将获取的多媒体数据通过Outpin送到MPEG分解转换过滤器，MPEG分解转换过滤器有一个输入针脚，两个输出针角分别将视频和音频解释码器进行解码，最后两路数据分别通过视频表示过滤器、音频表示过滤器送到显卡和声卡进行回放。
图3.3 MPEG解码实例
DirectShow建立在COM组件技术基础上，所以开发DirectShow程序必须要掌握COM组件技术。DirectShow与COM紧密相连，它所有的部件和功能都由COM接口来构造和实现，其开发方式相当灵活，没有固定的模式，通常随不同的需要使用不同的COM接口。但是其中几个重要的接口确实经常需要用到的：IGraphBuilder接口，这是最为重用的COM接口，用来创建Filter Graph Manager；IMediaControl接口，用来控制流媒体在滤波器图表（Filter Graph）中的流动，例如流媒体的启动和停止；IMediaEvent接口，该接口在Filter Graph发生一些事件时用来创建事件的标志信息并传送给应用程序。
一个典型的DirectShow应用程序的开发通常遵循的步骤为：
1）通过API函数CoCreateInstance（）创建一个Filter Graph Manager 实例；
2）通过调用QueryInterface ( )函数来获取Filter Graph 和IMediaEvent组件的指针；
3）对Filter Graph进行控制和对事件作出响应。
下面举一个简单的例子来说明如何利用DirectShow技术对多媒体流进行解码回放的。首先生成一个名为MediaPlay的单文档应用程序，定义一个名字为MediaPlay的函数，该函数的具体实现代码为：
void PlayMovie(LPTSTR lpszMovie)
{
IMediaControl *pMC = NULL;
IGraphBuilder *pGB = NULL;
IMediaEventEx *pME = NULL;
long evCode; // something to hold a returned event code
hr = CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC,
IID_IMediaControl, (void **)&pMC);
hr = pMC->QueryInterface(IID_IGraphBuilder, (void **)&pGB);
hr = pMC->QueryInterface(IID_IMediaEventEx, (void **)&pME);
hr = pGB->RenderFile(lpszMovie, NULL);
hr = pMC->Run();
hr = pME->WaitForCompletion(INFINITE, &evCode);
if(pMC)pMC->Release();
if(pGB)pGB->Release();
if(pME)pME->Release();
}
上述代码中，CoCreateInstance（）函数创建了一个过滤器图表（Filter Graph）对象，并返回一个媒体控制（ImediaControl）接口，这个接口通过过滤器来实现播放、暂停、停止等媒体放映功能，但是这时候图表对象并不包含具体的过滤器，因为此时DirectX并不清楚需要播放何种类型的媒体；接下来创建一个图表构建接口，该接口可以实现创建过滤器图表、向图表对象添加、删除各种过滤器、列举当前过滤器图表中所有的过滤器、连接图表对象中的各个过滤器等功能；本例中使用了IGraphBuilder 接口的RenderFile（）函数，告诉DirectX需要播放的媒体文件名，此时IgraphBuilder对象接口根据多媒体文件的类型，自动向过滤器图表添加播放该类型媒体所需的的各种过滤器，并实现其连接。
最后，函数调用ImediaControl接口对象的Run()函数，就可以开始播放媒体文件了。为了实现从头至尾的顺序播放完多媒体文件，需要调用IMediaEventEx 对象接口的WaitForCompletion（）阻塞函数的运行，直到媒体文件结束后才可以释放对象、结束函数的运行。
DES (DirectShow Editing Services)，是一套基于DirectShow核心框架的编程接口。DES的出现，简化了视频编辑任务，弥补了DirectShow对于媒体文件非线性编辑支持的先天性不足。但是，就技术本身而言，DES并没有超越DirectShow Filter架构，而只是DirectShow Filter的一种增强应用。我们可以从下图中了解到DES在我们整个多媒体处理应用中的位置。
如果我们使用DES，我们还可以得到如下的便利：
1. 基于时间线(Timeline)的结构以及Track的概念，使得多媒体文件的组织、编辑变得直观而高效；
2. 支持即时的预览；
3. 视频编辑项目支持XML文档的形式保存；
4. 支持对视频/音频的效果处理，以及视频之间切换的过渡处理；
5. 可以直接使用DES提供的100多种SMPTE过渡效果，以及MS IE自带的各种Transform、Transition组件；
6. 支持通过色调、亮度、RGB值或者alpha值进行图像的合成；
7. 自动对源文件输出的视频帧率、音频的采样率进行调整，直接支持视频的缩放。
接下去，我们来看一下DES的结构（Timeline模型），如下图所示：
下面，我们来看一个典型的基于Timeline的Source Track编排。如下图：
我们再看一个典型的Track之间加入了Transition的Timeline结构。如下图：
讲到这里，我们已经对DES结构有了一个初步的了解。我们需要回过去再看一看这个Timeline树结构。我们会发现，Group下面一般都有一个Composition，而随后的图例中，我们看到一般Group下直接嵌入的是Track。那么，Composition有什么用呢？熟悉《设计模式》的人很容易就明白了，微软采用的就是对象结构型模式的其中一种叫Composite（组合）的模式。Composition可以包装几个Track（这几个Track之间可能是包含Transition的），组成一个Virtual Track，并且与其他普通的Track接口保持一致。我们完全可以把这个Virtual Track与普通的Track一样操作，进而很方便地进行更加复杂、丰富的效果编辑。我们知道，DES是在Filter之上做了一层封装。为了更进一步地理解DES，我们就必须从Filter Graph这个层次对DES进行剖析。
下面，我们看一个典型的DES Filter Graph图：
下面我们再看一下当一个Timeline结构“翻译”成Filter Graph时是什么样子。先看Video部分：
值得注意的是，这条解码链路是通过微软的“智能连接”来创建的。采用这种方法，DES可以最大限度地使用本地系统中已经安装的Filter。但同时，也给基于DES的应用程序带来了麻烦。因为应用程序运行的系统环境是不可预见的，DES对Source的解码链路构建也就不稳定，相应地，应用程序的稳健性受运行环境的影响也会比较大。
下面我们再来看一下Audio部分：
理论上说，DES支持任何格式的媒体文件，只要系统中注册了对这种格式文件的解码Filter。我们看一下下图，DES对静态图片的支持：
从图中可以看出，Effect/Transition都使用了Wrapper filter（这两个Filter的CLSID是相同的），不同的是Effect是一进一出，而Transition是两进一出。我们还可以看到，Video控制Filter的Output pin经过Effect/ Transition后重新作为Video控制Filter的一个输入。
接下去，我们再来看一下DES对Audio Mixing的实现。典型的Timeline会有一个Video Group和一个Audio Group。如果整个Audio Group没有一个Audio source，或者一个10s的Timeline，Audio file仅有0-5s的输出，DES是如何处理的呢？我们看下图：
对于编写基于DES的应用程序开发者来说，了解这些DES的Filter Graph结构不是十分必要的。另一方面，因为DES的局限性（而且或许对于某些大型的商业应用软件来说是致命的），我们直接使用DES的可能性很小。我们研究的目的，在于汲取DES设计的精华，以开发一套适合于我们自己的使用的、提供强大编辑功能的DirectShow Filter应用架构。
流媒体的处理，以其复杂性和技术性，一向广受工业界的关注。特别伴随着因特网的普及，流媒体在网络上的广泛应用，怎样使流媒体的处理变得简单而富有成效逐渐成为了焦点问题。选择一种合适的应用方案，事半功倍。此时，微软的DirectShow，给了我们一个不错的选择。
DirectShow是微软公司提供的一套在Windows平台上进行流媒体处理的开发包，与DirectX开发包一起发布。目前，DirectX最新版本为8.1。
那么，DirectShow能够做些什么呢？且看，DirectShow为多媒体流的捕捉和回放提供了强有力的支持。运用DirectShow，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒体数据的回放变得轻而易举。另外，DirectShow还集成了DirectX其它部分（比如DirectDraw、DirectSound）的技术，直接支持DVD的播放，视频的非线性编辑，以及与数字摄像机的数据交换。更值得一提的是，DirectShow提供的是一种开放式的开发环境，我们可以根据自己的需要定制自己的组件。
DirectShow使用一种叫Filter Graph的模型来管理整个数据流的处理过程；参与数据处理的各个功能模块叫做Filter；各个Filter在Filter Graph中按一定的顺序连接成一条“流水线”协同工作。大家可以看到，按照功能来分，Filter大致分为三类：Source Filters、Transform Filters和Rendering Filters。Source Filters主要负责取得数据，数据源可以是文件、因特网、或者计算机里的采集卡、数字摄像机等，然后将数据往下传输；Transform Fitlers主要负责数据的格式转换、传输；Rendering Filtes主要负责数据的最终去向，我们可以将数据送给声卡、显卡进行多媒体的演示，也可以输出到文件进行存储。值得注意的是，三个部分并不是都只有一个Filter去完成功能。恰恰相反，每个部分往往是有几个Fitler协同工作的。比如，Transform Filters可能包含了一个Mpeg的解码Filter、以及视频色彩空间的转换Filter、音频采样频率转换Filter等等。除了系统提供的大量Filter外，我们可以定制自己的Filter，以完成我们需要的功能。下图是一条典型的Avi文件回放Filter Graph链路：
在DirectShow系统之上，我们看到的，即是我们的应用程序（Application）。应用程序要按照一定的意图建立起相应的Filter Graph，然后通过Filter Graph Manager来控制整个的数据处理过程。DirectShow能在Filter Graph运行的时候接收到各种事件，并通过消息的方式发送到我们的应用程序。这样，就实现了应用程序与DirectShow系统之间的交互。下图给出了DirectShow应用程序开发的一般过程：
以上简单介绍了DirectShow的系统结构，希望大家对这个强劲的应用框架已经有了大概的认识。如果你有兴趣，可以详细研究DirectX的帮助文档。DirectShow是一个强大的开发包；另外，它是基于COM的，因此要求程序员具有COM编程的一些基本知识。关于如何深入学习DirectShow应用结构以及开发自己的Filter，请参阅笔者的后续文章。笔者将从编程的角度，详细讲述来源于实际工作中的经验之谈。
从下面开始，我们要从程序员的角度，进一步深入探讨一下DirectShow的应用以及Filter的开发。
在这之前，笔者首先要特别提一下微软提供的一个Filter测试工具——GraphEdit，它的路径在DXSDK\bin\DXUtils\GraphEdit.exe。（如果您还没有安装DirectX SDK，请到微软的网站上去下载。）通过这个工具，我们可以很直观地看到Filter Graph的运行及处理流程，方便我们进行程序调试。（如果您手边就有电脑，还等什么，马上体验一下吧：运行GraphEdit，执行File-＞Render Media File…选择一个媒体文件；当Filter Graph构建成功后，按下工具栏的运行按钮；您就能看到刚才选择的媒体文件被回放出来了！看到了吧，写一个媒体播放器也就这么回事！）
接下去，我们开讲Filter的开发。
学习DirectShow Filter的开发，不外乎以下几种方法：看帮助文档、看示例代码和看SDK基类源代码。看帮助文档，应着重于总体概念上的理解；看示例代码应与基类源代码的研究同步进行，因为自己写Filter，关键的第一步是选择一个合适的Filter基类和Pin的基类。对于Filter的把握，一般认为要掌握以下三方面的内容：Filter之间Pin的连接、Filter之间的数据传输以及流媒体的随机访问（或者说流的定位）。下面就开始分别进行阐述。
所谓的Filter Pin之间的连接，实际上是Pin之间Media Type（媒体类型）的一个协商过程。连接总是从输出Pin指向输入Pin的。要想深入了解具体的连接过程，就必须认真研读SDK的基类源代码（位于DXSDK\samples\Multimedia\DirectShow\BaseClasses\amfilter.cpp，类CBasePin的Connect方法）。连接的大致过程为，枚举欲连接的输入Pin上所有的媒体类型，逐一用这些媒体类型与输出Pin进行连接，如果输出Pin也接受这种媒体类型，则Pin之间的连接宣告成功；如果所有输入Pin上枚举的媒体类型输出Pin都不支持，则枚举输出Pin上的所有媒体类型，并逐一用这些媒体类型与输入Pin进行连接。如果输入Pin接受其中的一种媒体类型，则Pin之间的连接到此也宣告成功；如果输出Pin上的所有媒体类型，输入Pin都不支持，则这两个Pin之间的连接过程宣告失败。
有一点需要注意的是，上述的输入Pin与输出Pin一般不属于同一个Filter，典型的是上一级Filter（也叫Upstream Filter）的输出Pin连向下一级Filter（也叫Downstream Filter）的输入Pin。
当Filter的Pin之间连接完成，也就是说，连接双方通过协商取得了一种大家都支持的媒体类型之后，即开始为数据传输做准备。这些准备工作中，最重要的是Pin上的内存分配器的协商，一般也是由输出Pin发起。在DirectShow Filter之间，数据是通过一个一个数据包传送的，这个数据包叫做Sample。Sample本身是一个COM对象，拥有一段内存用以装载数据，Sample就由内存分配器（Allocator）来统一管理。已成功连接的一对输出、输入Pin使用同一个内存分配器，所以数据从输出Pin传送到输入Pin上是无需内存拷贝的。而典型的数据拷贝，一般发生在Filter内部，从Filter的输入Pin上读取数据后，进行一定意图的处理，然后在Filter的输出Pin上填充数据，然后继续往下传输。下面，我们就具体阐述一下Filter之间的数据传送。
首先，大家要区分一下Filter的两种主要的数据传输模式：推模式（Push Model）和拉模式（Pull Model）。
所谓推模式，即源Filter（Source Filter）自己能够产生数据，并且一般在它的输出Pin上有独立的子线程负责将数据发送出去，常见的情况如代表WDM模型的采集卡的Live Source Filter；而所谓拉模式，即源Filter不具有把自己的数据送出去的能力，这种情况下，一般源Filter后紧跟着接一个Parser Filter或Splitter Filter，这种Filter一般在输入Pin上有个独立的子线程，负责不断地从源Filter索取数据，然后经过处理后将数据传送下去，常见的情况如文件源。推模式下，源Filter是主动的；拉模式下，源Filter是被动的。而事实上，如果将上图拉模式中的源Filter和Splitter Filter看成另一个虚拟的源Filter，则后面的Filter之间的数据传输也与推模式完全相同。
那么，数据到底是怎么通过连接着的Pin传输的呢？首先来看推模式。在源Filter后面的Filter输入Pin上，一定实现了一个IMemInputPin接口，数据正是通过上一级Filter调用这个接口的Receive方法进行传输的。值得注意的是（上面已经提到过），数据从输出Pin通过Receive方法调用传输到输入Pin上，并没有进行内存拷贝，它只是一个相当于数据到达的“通知”。再看一下拉模式。拉模式下的源Filter的输出Pin上，一定实现了一个IAsyncReader接口；其后面的Splitter Filter，就是通过调用这个接口的Request方法或者SyncRead方法来获得数据。Splitter Filter然后像推模式一样，调用下一级Filter输入Pin上的IMemInputPin接口Receive方法实现数据的往下传送。深入了解这部分内容，请认真研读SDK的基类源代码（位于DXSDK\samples\Multimedia\DirectShow\BaseClasses\source.cpp和pullpin.cpp）。
下面，我们来讲一下流的定位（Media Seeking）。在GraphEdit中，当我们成功构建了一个Filter Graph之后，我们就可以播放它。在播放中，我们可以看到进度条也在相应地前进。当然，我们也可以通过拖动进度条，实现随机访问。要做到这一点，在应用程序级别应该可以知道Filter Graph总共要播放多长时间，当前播放到什么位置等等。那么，在Filter级别，这一点是怎么实现的呢？
我们知道，若干个Filter通过Pin的相互连接组成了Filter Graph。而这个Filter Graph是由另一个COM对象Filter Graph Manager来管理的。通过Filter Graph Manager，我们就可以得到一个IMediaSeeking的接口来实现对流媒体的定位。在Filter级别，我们可以看到，Filter Graph Manager首先从最后一个Filter（Renderer Filter）开始，询问上一级Filter的输出Pin是否支持IMediaSeeking接口。如果支持，则返回这个接口；如果不支持，则继续往上一级Filter询问，直到源Filter。一般在源Filter的输出Pin上实现IMediaSeeking接口，它告诉调用者总共有多长时间的媒体内容，当前播放位置等信息。（如果是文件源，一般在Parser Filter或Splitter Filter实现这个接口。）对于Filter开发者来说，如果我们写的是源Filter，我们就要在Filter的输出Pin上实现IMediaSeeking这个接口；如果写的是中间的传输Filter，只需要在输出Pin上将用户的获得接口请求往上传递给上一级Filter的输出Pin；如果写的是Renderer Filter，需要在Filter上将用户的获得接口请求往上传递给上一级Filter的输出Pin。进一步的了解，请认真研读SDK的基类源代码（位于DXSDK\samples\Multimedia\DirectShow\BaseClasses\transfrm.cpp的类方法CTransformOutputPin::NonDelegatingQueryInterface实现和ctlutil.cpp中类CPosPassThru的实现）。
以上我们介绍了一下如何学习DirectShow Filter开发，以及一些开始写自己的Filter之前的预备知识。下一讲，笔者将根据自己开发Filter的经验，手把手教你如何写自己的Filter。
首先，从VC++的项目开始（请确认你已经给VC++配置好了DirectX的开发环境）。写自己的Filter，第一步是使用VC++建立一个Filter的项目。由于DirectX SDK提供了很多Filter的例子项目（位于DXSDK\samples\Multimedia\DirectShow\ Filters目录下），最简单的方法就是拷贝一个，然后再在此基础上修改。但如果你是Filter开发的初学者，笔者并不赞成这么做。
自己新建一个Filter项目也很简单。使用VC++的向导，建立一个空的”Win32 Dynamic-link Library”项目。注意，几个文件是必须有的：.def文件，定义四个导出函数；定义Filter类的.cpp文件和.h文件，并在.cpp文件中定义Filter的注册信息以及两个Filter的注册函数：DllRegisterServer和DllUnregisterServer。（注：Filter的注册信息是Filter在注册时写到注册表里的内容，格式可以参考SDK的示例代码，Filter相关的GUID务必使用GuidGen.exe产生。）接下去进行项目的设置（Project-＞Settings…）。此时，你可以打开一个SDK的例子项目进行对比，有些宏定义完全可以照抄，最后注意将输出文件的扩展名改为.ax。
上一讲曾经提到过，在写Filter之前，选择一个合适的Filter基类是至关重要的。为此，你必须对几个Filter的基类有相当的了解。在实际应用中，Filter的基类并不总是选择CBaseFilter的。相反，因为我们绝大部分写的都是中间的传输Filter（Transform Filter），所以基类选择CTransformFilter和CTransInPlaceFilter的居多。如果我们写的是源Filter，我们可以选择CSource作为基类；如果是Renderer Filter，可以选择CBaseRenderer或CBaseVideoRenderer等。
总之，选择好Filter的基类是很重要的。当然，选择Filter的基类也是很灵活的，没有绝对的标准。能够通过CTransformFilter实现的Filter当然也能从CBaseFilter一步一步实现。下面，笔者就从本人的实际经验出发，对Filter基类的选择提出几点建议供大家参考。
首先，你必须明确这个Filter要完成什么样的功能，即要对Filter项目进行需求分析。请尽量保持Filter实现的功能的单一性。如果必要的话，你可以将需求分解，由两个（或者更多的）功能单一的Filter去实现总的功能需求。
其次，你应该明确这个Filter大致在整个Filter Graph的位置，这个Filter的输入是什么数据，输出是什么数据，有几个输入Pin、几个输出Pin等等。你可以画出这个Filter的草图。弄清这一点十分重要，这将直接决定你使用哪种“模型”的Filter。比如，如果Filter仅有一个输入Pin和一个输出Pin，而且一进一处的媒体类型相同，则一般采用CTransInPlaceFilter作为Filter的基类；如果媒体类型不一样，则一般选择CTransformFilter作为基类。
再者，考虑一些数据传输、处理的特殊性要求。比如Filter的输入和输出的Sample并不是一一对应的，这就一般要在输入Pin上进行数据的缓存，而在输出Pin上使用专门的线程进行数据处理。这种情况下，Filter的基类选择CSource为宜（虽然这个Filter并不是源Filter）。
当Filter的基类选定了之后，Pin的基类也就相应选定了。接下去，就是Filter和Pin上的代码实现了。有一点需要注意的是，从软件设计的角度上来说，应该将你的逻辑类代码同Filter的代码分开。下面，我们一起来看一下输入Pin的实现。你需要实现基类所有的纯虚函数，比如CheckMediaType等。在CheckMediaType内，你可以对媒体类型进行检验，看是否是你期望的那种。因为大部分Filter采用的是推模式传输数据，所以在输入Pin上一般都实现了Receive方法。有的基类里面已经实现了Receive，而在Filter类上留一个纯虚函数供用户重载进行数据处理。这种情况下一般是无需重载Receive方法的，除非基类的实现不符合你的实际要求。而如果你重载了Receive方法，一般会同时重载以下三个函数EndOfStream、BeginFlush和EndFlush。我们再来看一下输出Pin的实现。一般情况下，你要实现基类所有的纯虚函数，除了CheckMediaType进行媒体类型检查外，一般还有DecideBufferSize以决定Sample使用内存的大小，GetMediaType提供支持的媒体类型。最后，我们看一下Filter类的实现。首先当然也要实现基类的所有纯虚函数。除此之外，Filter还要实现CreateInstance以提供COM的入口，实现NonDelegatingQueryInterface以暴露支持的接口。如果我们创建了自定义的输入、输出Pin，一般我们还要重载GetPinCount和GetPin两个函数。
Filter框架的实现大致就是这样。你或许还想知道怎样在Filter上实现一个自定义的接口，以及怎么实现Filter的属性页等等。限于篇幅，笔者就不展开阐述了。其实，这些问题都能在SDK的示例项目中找到答案。其他的，关于在实际编程中应该注意的一些问题，笔者整理了一下，供大家参考。
1. 锁（Lock）问题
DirectShow应用程序至少包含有两条线程：一条主线程和一条数据传输线程。既然是多线程，肯定会碰到线程同步的问题。Filter有两种锁：Filter对象锁和数据流锁。Filter对象锁用于Filter级别的如Filter状态转换、BeginFlush、EndFlush等；数据流锁用于数据处理线程内，比如Receive、EndOfStream等。如果这两种锁没有搞清楚，很容易产生程序的死锁，这一点特别需要提醒。
2. EndOfStream问题
当Filter接收到这个“消息”，意味着上一级Filter的数据都已经发送完毕。在这之后，如果Receive再有数据接收，也不应该去理睬它。如果Filter对输入Pin上的数据进行了缓存，在接收到EndOfStream后应确保所有缓存的数据都已经处理过了才能返回。
3. Media Seeking问题
一般情况下，你只需要在Filter的输出Pin上实现NonDelegatingQueryInterface方法，当用户申请得到IID_ImediaPosition接口或IID_IMediaSeeking接口时将请求往上一级Filter的输出Pin上传递。当Filter Graph进行Mediaseeking的时候，一般会调用Filter上的BeginFlush、EndFlush和NewSegment。如果你的Filter对数据进行了缓存，你就要重载它们，并做出相应的处理。如果你的Filter负责给发送出去的Sample打时间戳，那么，在Mediaseeking之后应该重新从零开始打起。
4. 关于使用专门的线程
如果你使用了专门的线程进行数据的处理和发送，你需要特别小心，不要让线程进行死循环，并且要让线程处理函数能够去时时检查线程命令。应该确保在Filter结束工作的时候，线程也能正常地结束。有时候，你把GraphEdit程序关掉，但GraphEdit进程仍在内存中，往往就是因为数据线程没有安全关闭这个原因。
5. 如何从媒体类型中获取信息
比如，你想在输入Pin连接的媒体类型中，获取视频图像的宽、高等信息，你应该在输入Pin的CompleteConnect方法中实现，而不要在SetMediaType中。
DirectX媒体对象（DirectX Media Objects，简称DMOs），是微软提供的另一种流数据处理COM组件。与DirectShow filter相比，DMO有很多相似之处。对filter原理的熟悉，将会大大帮助你对DMO的学习。另外，DMO也因其结构简单、易于创建和使用而倍受微软推崇。
DMO与filter的对比
1. DMO比filter实现的功能要少很多，这使得DMO“体积”很小；
2. DMO使用起来比filter更有灵活性。DMO的使用不需要filter graph，应用程序可以直接与DMO交互。而DMO也可以通过一个DMO wrapper filter工作于DirectShow环境；
3. DMO总是同步处理数据，不像filter有独立的数据传送线程，需要考虑多线程编程问题；
4. 与传统的编解码管理器ACM、VCM相比，用DMO开发的编解码器是基于COM的，更易于扩展。并且DMO支持多个输入和多个输出；
5. DMO不需要像filter一样分配数据传送的内存，而有DMO的使用者负责；
6. DMO是一个独立功能模块，不需要像filter一样连接成一条链路；
7. DMO不需要像filter一样将数据“推”下去，数据的输入输出都是由DMO的使用者完成的；
所有这些优点，使得DMO成为微软对于Encoder和Decoder开发的重点推荐模式。DirectX 9.0 SDK中，微软更是把DMO从DirectShow中分离出来，而对于一些transform filter，微软也推荐用DMO的方式来替换。
关于DMO的使用方式，目前大概有两种：一种是应用程序直接使用DMO，另一种就是在DirectShow filter中的应用。后者比较简单，只是使用了一个DMO wrapper filter。在DirectShow应用程序中，DMO是对用户透明的，所有使用DMO的工作均由DMO wrapper filter来完成。参见下面的代码。
// Create the DMO Wrapper filter.
IBaseFilter *pFilter;
HRESULT hr = CoCreateInstance（CLSID_DMOWrapperFilter, NULL,
CLSCTX_INPROC_SERVER, IID_IBaseFilter,
reinterpret_cast＜void**＞（&pFilter））;
if （SUCCEEDED（hr））
{
// Query for IDMOWrapperFilter.
IDMOWrapperFilter *pDmoWrapper;
hr = pFilter-＞QueryInterface（IID_IDMOWrapperFilter,
reinterpret_cast＜void**＞（&pDmoWrapper））;
if （SUCCEEDED（hr））
{
// Initialize the filter.
hr = pDmoWrapper-＞Init（CLSID_MyDMO, DMOCATEGORY_VIDEO_EFFECT）;
pDmoWrapper-＞Release（）;
if （SUCCEEDED（hr））
{
// Add the filter to the graph.
hr = pGraph-＞AddFilter（pFilter, L"My DMO"）;
}
}
pFilter-＞Release（）;
}
而对于DMO的直接使用，以下几点是要特别注意的。
1. 在处理数据之前，必须为每条输入输出stream设置media type（Optional stream除外）；
2. 从DMO从获取的media type未必包含format块，但是在给DMO设置media type时，务必带上这部分信息（MIDI除外）；
3. 应用程序必须自己负责分配数据缓存。缓存的大小可以通过调用DMO的IMediaObject::GetInputSizeInfo或IMediaObject::GetOutputSizeInfo得到。DMO使用的数据缓存也是一个COM对象，支持ImediaBuffer接口，与DirectShow filter的Media Sample类似。
4. 一般的DMO依次调用IMediaObject::ProcessInput和IMediaObject::ProcessOutput处理数据，In-Place的DMO调用IMediaObjectInPlace::Process处理数据。两套方法不能混用。
5. 在调用ProcessOutput时，如果返回的标记是DMO_OUTPUT_DATA_BUFFERF_INCOMPLETE，说明数据的数据还没有完全取出，需要再次调用ProcessOutput。
6. 所有输入数据都已输入完成，应该调用DMO的IMediaObject::Discontinuity方法。
7. 如果你想中断数据处理流程，调用DMO的IMediaObject::Flush。
8. 区别两种不同的可丢弃stream，标记分别为DMO_OUTPUT_STREAMF_OPTIONAL和DMO_OUTPUT_STREAMF_DISCARDABLE。注意，后者是要设置media type的。
对于小摄像头的驱动有几种方法，通过使用DirectShow来驱动摄像头灵活性比较好，有简单的方法也有比较复杂但更有效的方法，本文只介绍简单方法，希望与大家交流！
用DirectShow来使用摄像头，一般要求摄像头的驱动是WDM格式的，当然，一些比较老的驱动格式DirectShow也可支持。DirectShow通过图形过滤管理器(Filter Graph Manager)来与上层应用程序和下层的驱动进行联系。DirectShow通过一种叫作捕获过滤器(Capture Filter)的东东来支持对摄像头的捕获，一个捕获过滤器有多个插口(pin)，其中的预览(preview)插口可用来进行显示祯图象。
DirectShow通过几个COM接口来对视频捕获的全过程进行控制，其中IGraphBuilder 用于建立过滤器，ICaptureGraphBuilder2用于与下层的驱动程序建立联系，IVideoWindow，IMediaControl，IMediaEventEx分别对整个过程的视频窗口，播放过程和事件响应进行控制，
下面是例程：
CComQIPtr
CComQIPtr
CComQIPtr
CComPtr
CComPtr
DWORD m_dwGraphRegister;
bool bInit(HWND hWnd)
{
HRESULT hr;
//获得接口
hr=CoCreateInstance (CLSID_FilterGraph, NULL, CLSCTX_INPROC,IID_IGraphBuilder, (void **) &m_pGraph);
if (FAILED(hr))
return false;
hr=CoCreateInstance (CLSID_CaptureGraphBuilder2 , NULL, CLSCTX_INPROC,
IID_ICaptureGraphBuilder2, (void **) &m_pCapture);
if (FAILED(hr))
return false;
m_pMC=m_pGraph;
m_pVW=m_pGraph;
m_pME=m_pGraph;
//取得消息
m_pME->SetNotifyWindow((OAHWND)(m_hWnd=hWnd), WM_GRAPHNOTIFY, 0);
//将过滤和捕获进行连接
m_pCapture->SetFiltergraph(m_pGraph);
//设备联接
//枚举设备
CComPtr
CComPtr
hr=CoCreateInstance (CLSID_SystemDeviceEnum, NULL, CLSCTX_INPROC,
IID_ICreateDevEnum, (void **) &pCde);
if (FAILED(hr))
return false;
pCde->CreateClassEnumerator(CLSID_VideoInputDeviceCategory, &pEm, 0);
if(pEm==NULL)
return false;
CComPtr
ULONG cFetched;
CComPtr
if(pEm->Next(1,&pM,&cFetched)==S_OK)
{
pM->BindToObject(0,0,IID_IBaseFilter, (void**)&pBf);
pM.Release();
}
else
{
return false;
}
//将设备添加到graph
hr = m_pGraph->AddFilter(pBf, L"Video Capture");
if (FAILED(hr))
return false;
//连接一个源插口
hr=m_pCapture->RenderStream(&PIN_CATEGORY_PREVIEW,&MEDIATYPE_Video,pBf,NULL,NULL);
if (FAILED(hr))
return false;
pBf.Release();
//设定视频窗口
//设定视频窗口为主窗口的一个子窗口
hr=m_pVW->put_Owner((OAHWND)hWnd);
if (FAILED(hr))
return false;
//设定窗口样式
m_pVW->put_WindowStyle(WS_CHILD | WS_CLIPCHILDREN);
if (FAILED(hr))
return false;
//设定窗口大小
CRect rectClient;
GetClientRect(hWnd,rectClient);
m_pVW->SetWindowPosition(0, 0, 320, 240);
//设定可视
hr=m_pVW->put_Visible(OATRUE);
if (FAILED(hr))
return false;
//将对象加入到运行对象列表中
CComPtr
GetRunningObjectTable(0,&pROT);
WCHAR c[128];
wsprintfW(c, L"FilterGraph %08x pid %08x\0", (DWORD_PTR)m_pGraph.p, GetCurrentProcessId());
hr = CreateItemMoniker(L"!",c,&pM);
if (FAILED(hr))
return false;
hr = pROT->Register(ROTFLAGS_REGISTRATIONKEEPSALIVE,m_pGraph,pM,&m_dwGraphRegister);
pM.Release();
return false;
}
