原文:http://msdn.microsoft.com/en-us/library/ee663601(v=vs.85).aspx
如果你是数字多媒体新手,这个主题介绍了一些你需要在缩写MF应用程序之前理解的概念。
流是具有统一类型的一系列媒体数据序列。最觉的类型是音频和视频,但是流可以包含几乎任何数据类型,包括文本、脚本命令、静止图象。此文档中的术语stream不意味着通过网络来传递(数据)。用于本地播放的媒体文件也包含流。
通常,一个媒体文件或包含单个音频流,或者包含一个视频流和一个音频流。然而,一个媒体文件可能包含几个相同类型的流。例如,一个视频文件可能包含不同语言的几个音频流。在运行时,应用程序会选择使用哪个流。
压缩指的是任何通过除去冗余信息从而减少数据流大小的过程。压缩算法分为两大类:
在大多数其他领域,有损压缩是不可接受的。(想想看一个电子表格有损压缩后会有什么后果!)但是对很多理由来说,有损压缩是非常适合音频和视频的。
第一个理由有关于人类的知觉。当我们听一个复杂的声音时,比如一个音乐唱片,耳朵会忽略这个声音中的某些信息。通过信号处理理论的帮助,分析并分离那些不能被感觉的频率是可能的。这些频率可以被除去而不影响到我们的感觉。尽管压缩后的音频和原始音频并不一样,但对于听的人来说是一样的。同样的原则适用于视频。
其次,声音或图象中的某些损耗是可以接受的,取决于预期的目的。例如在电话服务中,音频经常被高度地压缩。结果对于电话交谈已经足够好了——但你一定不愿意通过电话来听交响乐。
压缩也称为“编码”,编码的设备称为“编码器”。相反的过程是“解码”,解码的设备自然地称为“解码器”。编码器和解码器统称为“编解码器”(codec)。Codec可以实现为硬件或软件。
自从数字媒体出现以来,压缩技术变化非常快,今天已经有非常多的压缩机制在使用。这个事实是数字媒体编程所面临的主题挑战之一。
很少把一个raw音频或视频流存成一个电脑文件,或者将它们直接通过网络发送。首先,如果事先不知道使用了什么codec,这样一个流是不可能解码的。因缘,媒体文件通常至少包含下面某些元素:
此主题使用术语容器(container)来描述包含流、头、索引、元数据等等的整个包(package)。使用术语container而不是file的原因是一些容器被设计用于实况广播。应用程序可以实时地产生容器,而不将其存入文件。
媒体容器的早期例子是AVI文件格式。其他例子包括MP4和Advanced Systems Format(ASF)。容器可以用文件后缀(如.mp4)或MIME类型来标识。
下图展示了一个典型的媒体容器的结构。此图并不代表任何特定的格式;每种格式的细节差别很大。
注意上图所示的结构是分层的,在容器的开头有头信息出现。这种结构对很多容器格式(但不是所有)来说是典型的。另外还要注意数据区包含交错(interleaved)的音频和视频包。这种交错在媒体容器里很常见。
术语“复用”(multiplexing)指将音频和视频流打包并把这些包交错放入容器的过程。相反的过程,即从打包的数据重组流称为“解复用”(demultiplexing)。
在数字媒体中,术语“格式”(format)是有歧义的。格式可以指编码的类型,比如H.264视频,也可以指容器,例如MP4。这个区别经常让普通用户感到迷惑。为媒体格式起名字通常没有什么帮助。例如,MP3既指编码格式(MPEG-1 Audio Layer 3),也指文件格式。
然而,这个差别是很重要的,因为读取一个媒体文件实际上涉及到两个阶段:
这一事实自然地导致了在软件设计中用来解析容器和用来解码流的组件是分离的。另外,这个方法适用于插件模式(plug-in mode),因此第三方可以提供它们自己的解析器和编解码器。在Windows上,COM提供了把API从它的实现分离的标准方式,对任何插件模型来说是必需的。正因如此,Media Foundation使用COM接口。
下图展示了用来读取媒体文件的组件:
写入一个媒体文件也需要两步:
下图展示了用来写入媒体文件的组件:
Media Foundation编程指南