Media Foundation：基本概念

如果你不熟悉数字媒体，本主题介绍在编写 Media Foundation 应用程序之前需要了解的一些概念。

• 流
• 压缩
• 媒体容器
• 格式
• 相关主题

流

流是具有统一类型的媒体数据序列。 最常见的类型是音频和视频，但流几乎可以包含任何类型的数据，包括文本、脚本命令和静止图像。 本文档中的术语 流 并不意味着通过网络传递。 用于本地播放的媒体文件还包含流。

通常，一个媒体文件包含一个音频流，或者正好包含一个视频流和一个音频流。 但是，媒体文件可能包含多个相同类型的流。 例如，视频文件可能包含几种不同语言的音频流。 在运行时，应用程序会选择要使用的流。

压缩

压缩 是指通过删除冗余信息来减小数据流大小的任何过程。 压缩算法分为两大类：

• 无损 压缩。 使用无损算法，重新构造的数据与原始数据相同。
• 有损 压缩。 使用有损算法，重新构造的数据是原始数据的近似值，但不是完全匹配。

在大多数其他域中，有损压缩是不能接受的。 (想象一下，找回电子表格的“近似值”！) 但有损压缩方案非常适用于音频和视频，原因有几个。

第一个原因与人类感知的物理有关。 当我们听一个复杂的声音，如音乐录音时，耳朵无法察觉到该声音中包含的一些信息。 借助信号处理理论，可以分析和分离无法感知的频率。 可以删除这些频率，而不会产生感知效果。 虽然重建的音频与原始音频不完全匹配，但对侦听器来说，它 听起来 是一样的。 类似的原则适用于视频。

其次，声音或图像质量的一些下降可能是可以接受的，具体取决于预期目的。 例如，在电话中，音频通常是高度压缩的。 结果足以进行电话交谈，但你不想通过电话收听交响乐团的声音。

压缩也称为 编码，编码的设备称为 编码器。 反向过程是 解码，设备自然称为 解码器。 编码器和解码器的通用术语是 编解码器。 编解码器可以在硬件或软件中实现。

自数字媒体问世以来，压缩技术发生了迅速变化，目前正在使用大量压缩方案。 这是数字媒体编程main挑战之一。

媒体容器

很少将原始音频或视频流存储为计算机文件，或者直接通过网络发送一个。 首先，如果不事先知道要使用哪个编解码器，就不可能解码此类流。 因此，媒体文件通常至少包含以下一些元素：

• 描述流数、每个流的格式等的文件标头。
• 启用对内容的随机访问的索引。
• 描述内容 (的元数据，例如艺术家或作品) 。
• 数据包标头，用于启用网络传输或随机访问。

本文档使用术语 容器 来描述流、标头、索引、元数据等的整个包。 使用 术语“容器 ”而不是 “文件 ”的原因是，某些容器格式专为实时广播而设计。 应用程序可以实时生成容器，永远不会将其存储到文件中。

媒体容器的早期示例是 AVI 文件格式。 其他示例包括 MP4 和高级系统格式 (ASF) 。 可以通过文件扩展名 (标识容器，例如，.mp4) 或 MIME 类型。

下图显示了媒体容器的典型结构。 关系图不表示任何特定格式;每种格式的详细信息差异很大。

请注意，关系图中显示的结构是分层的，标头信息显示在容器的开头。 此结构是许多 (但并非所有) 容器格式的典型结构。 另请注意，数据部分包含交错的音频和视频数据包。 这种类型的交错在媒体容器中很常见。

术语 多路复用 是指将音频和视频流数据包化并将数据包交错到容器的过程。 反向过程（从数据包化数据重新组合流）称为 解复用。

格式

在数字媒体中，术语 格式 不明确。 格式可以引用 编码类型（如 H.264 视频）或 容器（如 MP4）。 对于普通用户来说，这种区别通常会让人感到困惑。 为媒体格式提供的名称并不总是有帮助的。 例如， MP3 引用编码格式 (MPEG-1 音频第 3 层) 和文件格式。

但是，这一区别很重要，因为读取媒体文件实际上涉及两个阶段：

1. 首先，必须分析容器。 在大多数情况下，在此步骤完成之前，无法知道流的数量和每个流的格式。
2. 接下来，如果流已压缩，则必须使用适当的解码器对其进行解码。

这一事实很自然地导致软件设计，其中单独的组件用于分析容器和解码流。 此外，此方法还适用于插件模型，以便第三方可以提供自己的分析器和编解码器。 在 Windows 上，组件对象模型 (COM) 提供了一种将 API 与其实现分开的标准方法，这是任何插件模型的要求。 因此，媒体基础 () 等使用 COM 接口。

下图显示了用于读取媒体文件的组件：

写入媒体文件还需要两个步骤：

1. 对未压缩的音频/视频数据进行编码。
2. 将压缩的数据放入特定的容器格式。

下图显示了用于写入媒体文件的组件：

相关主题

媒体基础编程指南