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文件读取的场合下还是使用异步读取器。
最后来简单介绍一下编辑器。说是编辑器，大家不要误会它能做媒体内容的修改。其实它只能编辑一些元数据。所谓元数据，就是这个媒体内容的标题、描述、作者、版权等信息。
