说起视频捕捉问题，先来看一下视频捕捉卡。根据使用的驱动程序的不同来分类，目前市场上大致有两种捕捉卡：VFW (Video for Windows)卡和WDM (Windows Driver Model)卡。前者是一种趋于废弃的驱动模型，而后者是前者的替代模型；WDM还支持更多新的特性，比如直接支持电视接收、视频会议、1394接口的设 备、桌面摄像机、多条视频流（Line-21或Closed-Caption等）同时输出等等。采用VFW的一般都是些以前生产的卡；市面上新出现的，一 般都是采用了WDM驱动程序。另外，视频捕捉卡的接口，可以是以PCI或AGP的方式插入PC机箱，也可以直接以USB接口的方式外挂；还有就是通过 1394接口与PC机相连的数码摄像机等等。
基于VFW的视频捕卡
VFW技术受到的很多批评，因它捕获的数据保存到磁盘上会占用大量磁盘空间，每秒数据量超过20M，（有人试验640*480窗口1s大约需要10M）， 同时需要大量的客户端支撑软件，VFW体系架构上的不足在视频会议应用上和PC/TV应用上被暴露无遗，这样就要求一种新的视频捕获技术来弥补这些不足。 VFW的体系结构缺乏为视频会议，电视浏览，视频区域捕获和VBI（Vertical Blanking Interval）数据流提供强而有效的支持。一些视频卡等设备开发商在设计自己的产品时，针对这些缺陷，对VFW进行了功能扩展。由于没有统一的标准， 我们的应用程序在使用这些扩充的功能时，就必须要写一些基于特定硬件的代码。这就意味着当要改变捕获驱动程序时，就必须要对显卡的驱动程序进行修改。
基于WDM的视频捕获
WDM视频捕获设计就是为了来解决VFW体系结构中存在的这些问题。WDM视频捕获主要的好处体现在：
l 可以为设备(如基于USB，IEEE 1394通讯方式的摄像头 )提供32位的驱动程序。
l 允许DirectShow 和 WDM流协同工作。
l 可以在视频捕获设备和DVD/MPEG设备间，为硬件（如video ports和 chip sets）共享一个分类的驱动程序结构(Stream.sys)。
l 支持多个数据流。
l 允许电视信号调频和输入选择。
l 支持视频区域捕获，区域显示和VBI。
l 允许使用DirectDraw® VPE （Video Port Extensions）管理视频输入。
在一个单独设备上可能会有多个组件共存的情况，这些组件包括DVD解码器，MPEG解码器，视频解码器，调谐器，音频解码器。WDM数据流就是用于解决这种情况而创建的。它是个统一的驱动模型，可以支持所有的这些设备和去处理它们的资源分配。
WDM数据流为标准数据类型和用户自定义数据类型提供了统一的数据模型，同样，它定义了大部分的标准设备的属性，并且根据需要可以很容易地实现扩充。因为按WDM数据流的协议，它支持在设备内核间进行数据传输，而不需要在用户模式下进行数据转换。这样可以获得较高的效率，减少不必要的工作。
操作系统仍然支持VfW驱动程序，但是依赖于VFW的开发将逐渐减少，这是因为下面三个原因：
l WDM数据流为基于电视浏览和视频会议的捕获设备提供了优化支持。
l DirectShow提供了更强的功能。
l Microsoft 将不会对VFW进行持续开发。
上面这段话节选之http://blog.csdn.net/suntaoznz/article/details/596180。http://blog.csdn.net/suntaoznz这个博客中有几篇文章介绍了VFW和WDM。
http://wenku.baidu.com/view/07af18d380eb6294dd886cb8.html比较详细的介绍了WDM视频捕获。
一、VFW
VFW（Video for Windows）是微软公司1992年推出的关于数字视频的一个软件包，它能使应用程序通过数字化设备从传统的模拟视频源得到数字化的视频剪辑。简单说，它就是从Win95就开始使用的一组对音视频操作的一组API。VFW的一个关键思想是播放时不需要专用硬件，为了解决数字视频数据量大的问题，需要对数据进行压缩。它引进了一种叫AVI的文件标准，该标准未规定如何对视频进行捕获、压缩及播放，仅规定视频和音频该如何存储在硬盘上，以及在AVI文件中交替存储视频帧和与之相匹配的音频数据。VFW给程序员提供.VBX和AVICap窗口类的高级编程工具，使程序员能通过发送消息或设置属性来捕获、播放和编辑视频剪辑。在Windows 9x系统中,当用户在 安装VFW时，安装程序会自动地安装配置视频所需要的组件，如设备驱动程序、视频压缩程序等。
具体的开发步骤参考：
http://blog.ednchina.com/opencv2008/193859/message.aspx。自己也顺便转载了一下的。
二、DirectShow
DirectShow是微软公司在ActiveMovie和Video for Windows的基础上推出的新一代基于COM(Component Object Model)的流媒体处理的开发包，与DirectX开发包一起发布。DirectShow使用一种叫Filter Graph的模型来管理整个数据流的处理过程，运用DirectShow，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。这样使在多媒体数据库管理系统（MDBMS）中多媒体数据的存取变得更加方便。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等，为多媒体流的捕捉和回放提供了强有力的支持。
http://hi.baidu.com/%EE%B8%EE%B8/blog/item/951b33348e684b3e5ab5f54e.html中详细介绍了DirectShow捕捉如何编程。下面这段摘自维基百科http://zh.wikipedia.org/wiki/DirectShow 的话说明了 DirectShow的缺点。
播放一个文件是一项相对简单的任务，不过对于像是从视频窗口接收特定窗口信息到创建特定filters，开发者会不断地遇到DirectShow API的黑暗面。DirectShow因其复杂性而声名狼藉与此同时很多人认为它是微软最复杂的libraries/APIs。在“Microsoft.public.win32.programmer.directx.video”新闻群组上存在一个长期的灰色笑话，讲的是每当某人想要为DirectShow开发一个新的filter时，那么“六个月后见吧”。
开发者很少直接创建DirectShow filters - 他们通常使用被称为“DirectShow基础类”的一组像MFC一样的（不需要MFC）类别而开发者通常将会使用这些类来处理大多数工作。基本类的大小几乎是在代码中整个MFC library类大小的一半。即使有了基本类，DirectShow中存在的COM对象的绝对数量也是巨大的，甚至可以颠覆那些开发者想要开发的那种本以为相当直接的东西。DirectShow's的API有时违反一些传统的COM规则，比如关于关于参数到方法，虽然那些通常被证明了的。因此，为了制止这些情形，开发者时常使用DirectShow本身中较高层次的API，即Windows Media Player SDK，它提供了一个有较少COM接口处理的ActiveX控制。 DirectShow也因它对数据管理权限的支持而受到批评。然而当DirectShow本身有的API对DRM只有最小支持的时候，它在这情况只是一个名义上的领导者。在这个案例中真正的“坏人”事实上是被从DirectShow分开的Windows Media Player SDK因为它是对DRM有最多支持的地方。在相同方面，DirectShow也因对第三方媒体播放器功能的限制而受到指责，也就是说，在播放媒体文件方面，对Windows Media Player以外的媒体播放器存在不公。
《深入浅出DirectShow Filter》http://caodixy.blog.163.com/blog/static/5094048820106133850563/?fromdm&fromSearch&isFromSearchEngine=yes