Windows多媒体开发框架介绍

欢迎来到 Windows 的多媒体开发世界

1990 年 5 月 22 日，Windows 3.0 诞生了，微软帝国从此奠基，虽然没有和 Mac 一样精美的界面，但 Windows 兼容各个硬件厂家的框架才是它的致命武器。从 GDI 到 GDI+ 再到 Direct2D， 从 MME 到 DirectSound 再到 Core Audio，从 VFW 到 DirectShow 再到 Media Foundation，Windows 多媒体开发框架的发展其实也是顺应（强迫）硬件技术和性能的不断提高。

2D 绘图 API

1. GDI

GDI 全称为 Graphics Device Interface，即图形设备接口。它是 Windows 图形显示程序与实际物理设备之间的桥梁，GDI 使得用户无需关心具体设备的细节，而只需在一个虚拟的环境（即逻辑设备）中进行操作。

GDI 虽然使程序员得到了一定程度的解脱，但是其编程方式仍很麻烦。譬如，显示一张位图，程序员需要进行以下一连串操作，而有了 GDI+，这些问题便迎刃而解了。

2. GDI+

GDI+ 是 GDI 的后续版本，最早于 2001 年随 Windows XP 一起推出，后来又被包装进 .NET 框架的托管类库中，成为 .NET 中窗体绘图的主要工具。GDI 接口是基于函数的，而 GDI+ 是基于 C++ OO 的编程接口，因此使用起来比 GDI 要方便。因为 GDI+ 实际上是 GDI 的封装和扩展，所以执行效率一般要低于 GDI。

使用 GDI 时，经常需要将 PEN、BRUSH 等 GDI 对象选入 DC，并需要保存旧的 GDI 对象，然后进行一些绘图操作。此时调用的绘图函数都是使用这些新选入的 PEN、BRUSH，绘图完成之后再把旧的 GDI 对象重新选回 DC，这称之为 状态模式。而 GDI+ 不是这样，GDI+ 只是将 PEN、BRUSH 等对象作为参数传递给绘图函数，它们只影响这一次的绘制，下次再调用绘图函数，可以将新的 PEN、BRUSH 传入给绘图函数，这称为 无状态模式。与 GDI 相比，GDI+ 的编程模式发生了改变。

3. Direct2D

在 Windows 7 操作系统中，微软花费了很大的力气构建了一套新的 2D 绘图 API。微软称之为 Direct2D ，隶属于 DirectX 家族。这个 API 的开发填补了 Windows 图形平台的一些缺陷。其中非常重要的一点就是 GDI / GDI+ 不支持硬件加速。微软寄望于开发的这个 API 具备很多现代特性。比如硬件加速、支持抗锯齿和 Alpha Blend 的 2D 渲染，和其它现代图形 API 如 Direct3D 交互，服务器端渲染，诸如此类。

其实还有一套更方便的 UI 框架支持 2D 渲染硬件加速，那就是 WPF，对于开发人员来说，WPF 的好处在于它做了很重要的资源管理工作，但却使得直接控制硬件变得困难起来，而且 WPF 不支持 Native 的 C++ 程序。此外，对于处理文本和图像可以分别采用 DirectWrite 和 WIC 。这表明了微软 DirectX 家族正更加组件化。Direct2D 以一种互补的方式对 DirectWrite 文本和 WIC 位图操作提供硬件加速支持。

下面的 demo 演示了渐变绘制及圆角边框的效果

Direct2D 支持将一个或多个 Effects（特效 / 滤镜） 应用于图像，如调整亮度，去噪或创建阴影。Effects API 建立在 Direct3D 11 上，并利用 GPU 进行图像处理。在 Effect Graph 中可以串联或混合 Effects 的输出。

音频 API

1. MME

MME 全称为 Multimedia Extensions，有时也称为 waveOut API。 MME 既有 low-level API，也有 high-level API。 Low-level API 支持波形音频和 MIDI 输入 / 输出（waveIn，waveOut，midiIn，midiStream 等）。High-level API，即媒体控制接口（Media Control Interface ），是方便操作设备的类似脚本语言。

延迟是 MME 的一个很大的问题。 要实现动态的、接近实时的音频（如游戏事件声音）非常困难。

另外，对高质量音频的支持一直是 MME 的一个痛点。 部分 MME API（例如涉及设备能力结构体 WININCAPS 和 WINOUTCAPS 的任何调用）只能处理最大 96kHz 和 16 位音频。在 Windows Vista 以后的版本中，MME 其实是建立在 Core Audio 之上的一个 Wrapper。 你可能会发现，即使设备无法将自身报告为具有更高质量音频的能力，但实际上可以使用更高的采样率和位深度(-.-)。

2. DirectSound

DirectSound 和 MME 的主要区别有：即时采样率转换，Effects，多流混合，备用缓冲策略和硬件加速（如果可用）。因为 DirectSound 是使用 VxD（内核模式驱动程序）实现的，所以它可以非常接近硬件。与 MME 相比，它提供了更低的延迟和对更高质量音频的支持。

但是如果硬件供应商想要同时支持 Windows NT 和 Windows 95，他们需要编写两个完全独立的驱动程序：使用 Windows NT 驱动程序模型构建的 NT 驱动程序和 支持 Windows 95 的 VxD。

微软决定解决这个问题，因此 Windows 驱动程序模型（WDM）诞生了。有了 WDM，MME 和 DirectSound 的音频现在都 pass through 到了内核音频混音器（通常称为 KMixer）。 KMixer 是一个内核模式组件，负责将所有系统音频混合在一起。 但不幸的是，KMixer 引入了延迟，很多，确切地说是 30 毫秒，有时还会更长。

后来总部位于波士顿的 Cakewalk 公司开发了一种名为 WDM / KS 的技术。KS 不属于官方的音频 API，它算是 WDM 音频驱动程序基础架构的一部分。 WDM / KS 技术直接与硬件的 streaming driver 通信，完全绕开 KMixer。这样应用程序可以避免 KMixer 引入的性能税，并减少 CPU 负载。音频软件社区突然发现了这个小技巧，很快似乎每个人都在支持 WDM / KS。

3. Windows Core Audio

Windows Core Audio 是对 Windows 上音频处理方式的完全重新设计。KMixer 被彻底抛弃了。大多数音频组件都从内核移植到用户区（由于 WDM 是通过内核模式访问的，如果编写得不好，WDM / KS 应用程序很容易导致系统蓝屏）。所有 Legacy 的音频 API 都被构建在这个新的用户模式 API 之上，包括 DirectSound，但从此它完全失去了对硬件加速音频的支持。
Core Audio 实际上是 4 个 API 组成的 - MMDevice、DeviceTopology、EndpointVolume 和 WASAPI。

• MMDevice：设备发现 API
• DeviceTopology：与音频路径中存在的所有用户态组件交互的 API
• EndpointVolume：与设备本身的音量控制进行交互的 API
• WASAPI：音频会话 API，Core Audio 的主力 API，是所有行动发生的地方

Core Audio 架构

Core Audio 为我们带来的另一项重大改进是能够以 共享模式 或 独占模式 运行。

• 共享模式 与旧的 KMixer 模型有一些相似之处。在共享模式下，应用程序会写入一个缓冲区，该缓冲区将传递给系统的音频引擎。音频引擎负责将所有应用程序的音频混合在一起然后发送到音频驱动程序。与 KMixer 一样，这会引入延迟。
• 独占模式 是微软对专业音频世界的回应。独占模式具有许多与 WDM / KS 相同的优点。应用程序可以独占访问硬件，音频数据可以直接从应用程序经由驱动程序传输到硬件。

视频 API

1. VFW

VFW（Video for Windows）是微软于 1992 年推出的关于数字视频的一个 SDK，它能使应用程序通过数字化设备从传统的模拟视频源得到数字化的视频剪辑。VFW 的一个关键思想是播放时不需要专用硬件。为了解决数字视频数据量大的问题，需要对数据进行压缩。VFW 引进了一种叫 AVI 的文件标准，该标准未规定如何对视频进行捕获、压缩及播放，仅规定视频和音频该如何交错存储在硬盘上。VFW 给程序员提供 .VBX 和 AVICap 窗口类的高级编程工具，使程序员能通过发送消息或设置属性来捕获、播放和编辑视频剪辑。

VFW 技术受到的最多批评是它捕获的数据保存到磁盘上会占用大量磁盘空间，有人试验用 640x480 捕获 1s 大约需要10MB ⊙_⊙，另外 VFW 的体系结构缺乏为视频会议，在线电视等流媒体应用提供强而有效的支持。

2. DirectShow

DirectShow （简称 DShow）是微软在 ActiveMovie 和 VFW 的基础上推出的新一代基于 COM 的流媒体处理的 SDK，与 DirectX SDK 一起发布。DirectShow 使用一种叫 Filter Graph 的模型来管理整个数据流的处理过程。有了 DirectShow，我们可以很方便地从支持 WDM 驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。它广泛地支持各种媒体格式，包括 Asf、Mpeg、Avi、Dv、Mp3、Wave 等，为多媒体流的捕捉和回放提供了强有力的支持。

DirectShow 架构

Direct Show 的发展历史

• 孕育期（1995 ~ 1998）ActiveMovie，开发代号 Quartz，在 Windows 3.0 时代，是作为一种对当时最流行的媒体平台 QuickTime 的回应而开发的。它当时的使命是作为 IE 的插件播放在其窗口内的媒体文件，正如当时 QuickTime 为 Netscape 以及 IE 提供的服务那样，它的另一个功能是作为 VFW 的一个替换，特别地为在 VFW 架构中难于处理的 MPEG 文件提供辅助处理。
• 诞生期（1998）在这一年，大致在 DirectX 5 的年代，ActiveMovie 被重命名为 DirectShow 并且被包含为 “DirectMedia SDK” 的一部分。
• 成长期（1999 ~ 2005）在 DirectX 7 中，DirectShow 变成了 DirectX SDK 主要组成部分，而且如同 DirectInput 等其它 DirectX API 一样被赋予了它自己的位置。DirectShow 被主要用来做音视频捕捉和媒体文件的播放（Windows Media Player 就是基于 DShow 开发的）。
• 动荡衰落期（2005 ~ 至今） 从 2005 年 4 月起，DirectShow 从 DirectX SDK 中移除了，必须单独下载 DirectShow 的 SDK 包才能得以支持，之后 DirectShow 的文档和示例被转移到 Windows SDK，DirectShow 也正式成为 Windows 的一个组件。然而，在编译某些 DirectShow 的 sample 时，DirectX SDK 仍然是必需的。

DirectShow 对数字高清媒体的应用程序确实是非常通用的、万能的，但是，DirectShow 作为一个 20 年的老技术而言已经力不从心了。比如：

1. Graph 是静态的，要实现动态的 Graph 和 Major format change 是非常困难的。
2. DirectShow filter 的线程模型是非常复杂的，要完全理解并永不出错是太困难了。
   在 “Microsoft.public.win32.programmer.directx.video” 新闻群组上存在一个长期的灰色笑话，讲的是每当某人想要为 DirectShow 开发一个新的 filter 时，那么，“六个月后见吧”
3. DirectShow filter 只能用于DirectShow。
4. DirectShow 不支持文件保护（DRM）。

于是便有了 Media Foundation。

3. Media Foundation

2005 年，微软推出 Windows Vista，与此同时在 Windows Vista 上推出了新一代多媒体应用库 Media Foundation（以下简称 MF）。目的是提供 Windows 平台一个统一的多媒体影音解决方案，开发者可以通过 MF 播放视频或声音文件、进行多媒体文件格式转码，或者将一连串图片编码为视频等等。MF 是 DirectShow 为主的旧式多媒体应用程序接口的替代者与继承者，在微软的计划下将逐步汰换 DirectShow 技术。MF 要求Windows Vista 或更高版本，不支持较早期的 Windows 版本，特别是 Windows XP。

MF 架构

• MF 架构分为控制层（Control layer），核心层（Core layer）与平台层（Platform layer）。大部分 MF 功能均由核心层提供，开发者则由控制层来控制行为。一般开发者仅须了解控制层与核心层，几乎不须接触平台层。
• MF 提供了两种编程模型，第一种是以 Media Session 为主的 Media pipeline 模型，但是该模型太过复杂，且曝露过多底层细节，故微软于 Windows 7 上推出第二种编程模型，内含 SourceReader、Transcode API 、SinkWriter 及 MFPlay 等高度封装模块，大大简化了 MF 的使用难度。
• Media pipeline 分三个组成部分：Media Source，Media Sink 和 Media Foundation Transforms（简称 MFT）。
  MFT 推出了一个革新式的技术 DirectX Media Objects (DMO)。DMO 不仅可以用在 MF 中，也可以通过一个通用的 wrapper filter 成为一个标准的 DShow Filter，反之却不行。

看起来 MF 是完美的 DShow 替代者，但实际情况却是 MF 在推出十多年间鲜有人理会⊙﹏⊙b。个人认为，一是 DShow 已经形成了成熟的社区，从硬件到软件到开发库都是非常完备的，而且 Windows 的兼容性也一直非常好-_-|||，实在没有换代的动力。二是 MF 除了在 DRM 媒体保护（Protected Media Path）方面是天然支持的，其他功能并没有比 DShow 技高一筹，顶多是用着更简单一些，然并卵。

Anyway，像最新的 UWP 框架里只支持 MFT，不能用 DShow 的 Filter，所以，不要再留恋 DShow 了，它终将成为一个传说。

微软在 MF 推出之初还写了一篇 文章 勾引大家从 DShow 迁移到 MF，纯英文，原汁原味。

– EOF –