Windows Media媒体内容采用的是 ASF文件格式。 Microsoft公司提供了 Windows Media Format SDK，以支持以下三大功能： ASF文件的生成（包括 ASF数据的流化）、 ASF文件的编辑和 ASF文件的播放（包括 ASF媒体流的播放）。在开始编程之前，对 SDK系统有个总体的认识和理解是必要的。（注：如果未作特别说明，本书所述的 SDK或 WMF SDK均是指 Windows Media Format SDK。）

WMF SDK采用了面向对象的设计，是一套完全基于 COM组件模型的高级开发包。这里说高级，意味着 SDK屏蔽了 ASF数据格式、网络传输控制等较为底层的流媒体技术实现细节，留给开发者的只有比较上层的编程接口。

图 2.1 WMF SDK 系统结构

如图 2.1， SDK引入了一系列的对象，如生成器、读取器、编辑器等。正是这些 SDK对象屏蔽了 Windows Media技术实现细节，使得应用程序开发者不需要了解太多的流媒体底层技术，也能开发出非常专业的流媒体应用系统。

在 SDK引入的众多对象中，最重要的莫过于图 2.1中列出的那三个了。其中，生成器一般用于将非压缩的媒体数据编码成 Windows Media格式的数据。整个编码过程非常简单，只要通过一个叫 Profile的对象配置好目标数据流格式，再将输入数据的格式告诉生成器，然后依次将输入数据按照既定的方式传给生成器，剩下的事就都可以交给生成器了。生成器内部会根据 Profile的配置，自动选择一种 Windows Media编码器，然后对输入数据进行压缩编码，并且完成打包，最终写成文件或者向网络流化。

图 2.2 生成器的工作流程

如图 2.2是 生成器大致的工作流程。可以看到，生成器内部对输入数据可能有一个预处理过程。因为特定编码器能够接受的数据格式总是有限的。如果输入数据格式不能被编码 器接受，生成器内部会自动进行一个预处理过程。这些预处理工作包括视频的图像大小缩放、帧率调整、色彩空间转换、水印叠加，音频的采样频率转换等等。另 外，生成器本身不负责编码后的数据的最终去向，而是把这个任务交给了一种叫接收器（ Sink）的对象，比如交给文件接收器就可以将数据保存为文件，交给网络接收器就可以将数据进行广播，交给推接收器就可以将数据分发到运行 Windows Media Services的服务器上等等。 SDK采用这种“生成器 + 接收器”的设计是很先进的，它保证了 SDK系统具有很强的扩展性。比如我们可以开发自己的接收器，按我们的要求决定压缩数据的最终去向。

如果你用过 Microsoft公司官方发布的 Windows Media内容的编码软件 Windows Media Encoder的话，不要怀疑，通过 WMF SDK的学习，你也可以开发出一个类似的编码软件。

WMF SDK有两个读取器：异步读取器和同步读取器。两个读取器的功能类似，都是用于读取 ASF数 据，不同的是它们的工作方式：异步读取器内部自带一个线程来把数据流推给应用程序；而同步读取器内部没有驱动数据流的线程，应用程序直接（在应用程序的线 程中）通过同步读取器上的接口函数来获取数据。（注：异步读取器通常简称为读取器，而只在与同步读取器对比时才强调“异步”特性。）

图 2.3 读取器的工作流程

默认情况下，读取器输出一种非压缩格式的数据。也就是说，读取器内部会自动选择合适的解码器对 ASF流数据进行解压缩，如图 2.3。当然，通过适当的设置，读取器也可以输出 ASF流数据原有的压缩格式。

值得注意的是，异步读取器在各个版本的 SDK中都能使用；而同步读取器是在 9系列的 SDK中 才开始有的。之所以增加同步读取器，是因为数据的同步读取模式在一些特殊的场合下较有优势，比如在一些进行内容编辑的应用程序中，使用同步读取器可以快速 读取指定位置的一部分数据。另外，同步读取器通过直接的接口函数调用来提供数据，使用起来也比较简单。当然，同步读取器也有明显的不足，比如不支持读取网 络文件，不支持 DRM（数字版权管理）等等。因此，在绝大多数 ASF文件读取的场合下还是使用异步读取器。

最后来简单介绍一下编辑器。说是编辑器，大家不要误会它能做媒体内容的修改。其实它只能编辑一些元数据。所谓元数据，就是这个媒体内容的标题、描述、作者、版权等信息。

转自：http://blog.csdn.net/happydeer/archive/2004/11/29/198262.aspx