基于05/31/2018
如果你刚刚接触数字媒体，那么此篇介绍了一些做媒体应用开发需要知道的内容。
Streams（流）
stream 是具有统一格式的媒体数据序列。最常见的是音频和视频，但 stream 也可以包含任何类型的数据，包括 text，脚本命令，甚至图片。此文档中的 stream 不包括网络传输。用于本地播放的媒体文件就包含 stream。.
通常，一个媒体文件只包含一个音频流或者包含一个视频流和一个音频流。然而，一个媒体文件也会包含多个相同类型的 stream。例如，一个视频文件可能包含多个不同语言的音频流，在播放时由应用程序决定播放哪个。
Compression（压缩/编码）
Compression（压缩） 是指为了减小文件大小而去掉冗余数据的过程。压缩算法有以下两种：
- 无损压缩。压缩后的数据可以完全恢复成压缩之前的数据。
- 有损压缩。压缩后的数据可以恢复成接近原始数据的状态，但无法恢复到完全一样。
在大多数情况下，有损压缩不可接受，想象一下打开电子表格获得了原始数据的近似值，但是对于音频和视频，压缩算法是非常合适的。（下面是两段原因不翻了）
The first reason has to do with the physics of human perception. When we listen to a complex sound, like a music recording, some of the information contained in that sound is not perceptible to the ear. With the help of signal processing theory, it is possible to analyze and separate the frequencies that cannot be perceived. These frequencies can be removed with no perceptual effect. Although the reconstructed audio will not match the original exactly, it will sound the same to the listener. Similar principles apply to video.
Second, some degradation in sound or image quality may be acceptable, depending on the intended purpose. In telephony, for example, audio is often highly compressed. The result is good enough for a phone conversation—but you wouldn't want to listen to a symphony orchestra over a telephone.
Compression 又被称为 encoding（编码），进程编码过程的东西称为 encoder（编码器）。恢复过程称为 decoding（解码）， 这个设备称为 decoder（解码器）。解码器和编码器（encoder and decoder）统称为 codec（编解码器？）。Codecs 可以是硬件也可以是软件。
Compression 技术自从数字媒体出现以来变化迅速，于是现在有了许多种压缩格式。这也是数字媒体开发所面对的一个主要挑战。
Media Containers（媒体容器）
很少将音视频流直接存储为文件，或者直接通过网络传输，因为不知道要用哪个编解码器的情况下将无法解码一个 stream。这意味着一个媒体文件至少包含以下几种信息：
- 文件头，包含了 描述文件中有几个 stream 的信息，每个 stream 的格式等等。
- 允许随机访问的索引。
- 描述内容的 Metadata (例如，作者和标题等)。
- Packet headers, 为了通过网络传输或者随机访问。
本文当中使用 container（容器）来描述一个包含 streams（流）, headers（头）, indexes（索引）, metadata, and so forth 的包。用 container（容器）而不用 file（文件） 是因为某些容器格式是为 live broadcast 实时广播而设计的。应用程序可以实时生成容器, 而不会将其存储到文件中。
一个早期的媒体容器例子是 AVI 格式。另外还有 MP4 和 Advanced Systems Format (ASF)。容器格式可以由文件扩展名（for example, .mp4) 或者 MIME 类型标识。
下图显示了媒体容器的典型结构。该图不表示任何特定的格式;每种格式的细节差别很大。
注意图中显示的结构是分层结构，标题信息出现在容器的开头。这种结构是许多（但不是全部）容器格式的典型结构。另外，数据部分包含交错存储的音频和视频数据包。这种交错在媒体容器中很常见。
multiplexing（可译为多路复用） 这个词是指对音频和视频 streams 进行打包并将数据包交错存储到容器中的过程。反过来，将打包了的数据重新组装为 streams 的过程称为 demultiplexing。
Formats
在数字媒体领域， format（格式） 这个词有时候不好理解，“格式”既可以指编码（encoding）格式，像h264，也可以指容器，像MP4。这种区别通常会使普通用户感到困惑。有时候即使给出了具体的格式名称也无济于事，例如MP3既可以指编码格式（MPEG-1 Audio Layer 3）也可以指文件格式。
搞清楚两者的区别是很重要的，解析一个媒体文件实际上涉及两步：
- 首先，必须解析容器。 在大多数情况下，在完成此步骤之前，无法知道 stream 的数量和每个 stream 的格式。
- 然后，如果流被压缩，则必须使用对应的解码器对它们进行解码。
于是这自然地产生了一种软件设计，即使用单独的组件分别来解析容器和解码流。此外，这种方法适用于插件模型（plug-in model），因此第三方可以提供自己的解析器（parser）和编解码器。 在Windows上，组件对象模型（COM）提供了一种将API与其实现分离的标准方法，这是任何插件模型的要求。 出于这些原因，Media Foundation 使用COM接口。
下图显示了用于读取媒体文件的组件：
生成一个媒体文件一般也有两个步骤：
- 编码原始音视频数据
- 把压缩过的数据放入某一特定格式容器
下图显示了用于编写媒体文件的组件：
