DirectShow是微软公司在ActiveMovie和Video for Windows的基础上推出的新一代基于COM(Component Object Model)的流媒体处理的开发包，与DirectX开发包一起发布。DirectShow使用一种叫Filter Graph的模型来管理整个数据流的处理过程，运用DirectShow，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。这样使在多媒体数据库管理系统（MDBMS）中多媒体数据的存取变得更加方便。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等，为多媒体流的捕捉和回放提供了强有力的支持。

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

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

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

在 1998 年，大致在 DirectX 5 年代的时候，ActiveMovie

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

为一个 mp3 文件创建的 Filter graph，由 DirectShow 自带的示例 GraphEdit 来播放。在这幅图中大的方块代表 Filter graph ，小的方块代表端口。 每个Filter表示数据处理过程的一个阶段，举例来说从一个文件或照相机读取数据，解码，转换以及绘制。filter 有若干的能被连接到其他 filter 上的连接点的Interface。Interface可能是输出或输入。根据 filter，数据被采用“拉模式”从输出端口输出，或者以“推模式”被推到另一个输入端口，并借此来传输数据。 大多数 filters 的创建使用了一组 DirectShow SDK 提供的 C++类，叫做 DirectShow BaseClass。这些为 filters 解决了许多创建，注册和连接的问题。如果要让 filter graph 能够自动的使用 filters，它们需要在一个分开的 DirectShow 项目中被登记并与 COM 一起登记。 这一个注册能被 DirectShow BaseClass处理。然而，如果应用程序手工增加 filters，他们不需要被全然登记。 不幸地，它难以修改一个正在运行中的 graph 。从头停止 graph 而产生一个新 graph 通常是比较容易的。

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

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

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

播放一个文件是一项相对简单的任务，不过对于像是从视频窗口接收特定窗口信息到创建特定 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以外的媒体播放器存在不公。