DirectShow（流媒体处理开发包）

DirectShow

流媒体处理开发包

DirectShow是微软公司在ActiveMovie和Video for Windows的基础上推出的新一代基于COM的流媒体处理的开发包，与DirectX开发包一起发布。

简介

DirectShow是微软公司提供的一套在Windows平台上进行流媒体处理的开发包，9.0之前与DirectX开发包一起发布，之后包含在windowsSDK中。

运用DirectShow，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒体数据的回放变得轻而易举。另外，DirectShow还集成了DirectX其它部分（比如DirectDraw、DirectSound）的技术，直接支持DVD的播放，视频的非线性编辑，以及与数字摄像机的数据交换。

历史

ActiveMovie，开发代号Quartz，这个由GeraintDavies为微软公司设计的DirectShow的前身，在Windows3.0时代，是作为一种对当时最流行的媒体平台QuickTime的回应而开发的。ActiveMovie最早的出现是被附加在Windows95上面的并且需要系统安装了IE3.0。它当时的使命是作为IE的附件播放在其窗口内的媒体文件，正如当时QuickTime为Netscape以及IE提供的服务那样，它的另一个功能是作为Windows视频技术（VFW，VideoForWindows）的一个替换，特别地为在VFW架构中难于处理的MPEG（移动图象专家组格式文件）文件提供辅助处理。

在1998年，大致在DirectX5年代的时候，ActiveMovie被重命名为DirectShow（反映了微软公司在那时正在努力加强“直接地”在一个通常的取名系统之下与硬件合作的技术）并且被包含为"DirectMediaSDK"的一部份。在DirectX的7版中，DirectShow变成了DirectXSDK主要组成部分而且如同DirectInput等其它DirectXAPIs一样被给予了它自己的位置。甚至之后，DirectShow被主要用来接收来自像一个手提摄像机这样的电视输入装置的数据，而且它从文件中显示数据的能力被广泛用在WindowsMediaPlayer上面。

从2005年四月起，DirectShow被从DirectXSDK移除，必须单独下载Extra包才能得以支持，之后DirectShow的文档和示例被转移到WindowsSDK，DirectShow也正式成为Windows的一个组件。然而，在编译某些DirectShow的示例时，DirectXSDK仍然是必需的。

设计

DirectShow运行的方式通常是一个开发者创建一个FilterGraph，把一些Filter-可能订制-加入FilterGraph，然后播放文件，或者播放来自互联网或照相机的数据。当播放进程运行时，FilterGraph在Windows注册中寻找注册了的Filters并且为这些Filter创建本地提供的Graph。在这之后，它将所有的Filter连接在一起，并且在开发者的请求下，播放/中止创造的Graph。

为一个mp3文件创建的Filtergraph，由DirectShow自带的示例GraphEdit来播放。在这幅图中大的方块代表Filtergraph，小的方块代表端口。每个Filter表示数据处理过程的一个阶段，举例来说从一个文件或照相机读取数据，解码，转换以及绘制。filter有若干的能被连接到其他filter上的连接点的Interface。Interface可能是输出或输入。根据filter，数据被采用“拉模式”从输出端口输出，或者以“推模式”被推到另一个输入端口，并借此来传输数据。大多数filters的创建使用了一组DirectShowSDK提供的C++类，叫做DirectShowBaseClass。

这些为filters解决了许多创建，注册和连接的问题。如果要让filtergraph能够自动的使用filters，它们需要在一个分开的DirectShow项目中被登记并与COM一起登记。这一个注册能被DirectShowBaseClass处理。然而，如果应用程序手工增加filters，他们不需要被全然登记。不幸地，它难以修改一个正在运行中的graph。从头停止graph而产生一个新graph通常是比较容易的。

功能

在DirectShow中有许多抽象的播放源文件的方法，实现这些功能也是相当简单的而且不需要一个定制过的filter。下一步相对复杂的过程是程序开发员需要开发他（她）自己的filtergraph，举个例子他们可能设计一个可以接受来自互联网或是硬盘文件数据的sourcefilter，也许有些定制的filter就是开发者想要的，接下来他们需要让DirectShow为用户完成一个filterGraph并将所有filter连接起来，在最后开发者仅仅只用让DirectShow为他们生成一个可以获取文件数据的sourcefilter就可以了。

DirectShow预先设置支持许多通常的媒体格式，如MP3，和Windows媒体视频和一些比较常见的格式，比如简单的静态图像。自从在Windows中这些技术被许可了，对Fraunhofer来说就没有为专利权而付出花费的必要了，比如MP3执照。扩充机制允许DirectShow在将来可以支持出现的任何格式，举例来说，已经有对OggVorbis文件和AC3文件的支持filters，此外还有若干其它的支持filters。

不同于为了读取媒体文件必须在循环中需要调用MoviesTask的为QuickTime设计的mainCAPI，DirectShow以一种透明的方式处理这个问题。它在后台创建了一些线程来平缓的播放这些来自文件和互联网的数据与此同时不需要程序做很多任务作。还跟QuickTime正好相反的是，在读取一段来自互联网数据而不是读取硬盘文件的时候没有特别的需要——DirectShow的filtergraph摘录了来自程序的这些明细。然而，QuickTime（包括一个ActiveX控制）在这方面的发展相比之下逊色很多。

评价

播放一个文件是一项相对简单的任务，不过对于像是从视频窗口接收特定窗口信息到创建特定filters，开发者会不断地遇到DirectShowAPI的黑暗面。DirectShow因其复杂性而声名狼借与此同时很多人认为它是微软最复杂的libraries/APIs。在“Microsoft.public.win32.programmer.directx.video”新闻群组上存在一个长期的灰色笑话，讲的是每当某人想要为DirectShow开发一个新的filter时，那么“六个月后见吧”。

开发者很少直接创建DirectShowfilters他们通常使用被称为“DirectShow基础类”的一组像MFC一样的（不需要MFC）类别而开发者通常将会使用这些类来处理大多数工作。基本类的大小几乎是在代码中整个MFClibrary类大小的一半。即使有了基本类，DirectShow中存在的COM对象的绝对数量也是巨大的，甚至可以颠复那些开发者想要开发的那种本以为相当直接的东西。DirectShow's的API有时违反一些传统的COM规则，比如关于关于参数到方法，虽然那些通常被证明了的。

因此，为了制止这些情形，开发者时常使用DirectShow本身中较高层次的API，即WindowsMediaPlayerSDK，它提供了一个有较少COM接口处理的ActiveX控制。DirectShow也因它对数据管理权限的支持而受到批评。然而当DirectShow本身有的API对DRM只有最小支持的时候，它在这情况只是一个名义上的领导者。

在这个案例中真正的“坏人”事实上是被从DirectShow分开的WindowsMediaPlayerSDK因为它是对DRM有最多支持的地方。在相同方面，DirectShow也因对第三方媒体播放器功能的限制而受到指责，也就是说，在播放媒体文件方面，对WindowsMediaPlayer以外的媒体播放器存在不公。

参考资料

1.高清视频应用中DirectShow与DirectX的区别·wisdat网