Windows开发：关于微软媒体基础（Microsoft Media Foundation）

最新推荐文章于 2025-05-08 22:19:20 发布

锕琅

最新推荐文章于 2025-05-08 22:19:20 发布

阅读量3.1k

点赞数 3

CC 4.0 BY-SA版权

分类专栏： Windows 基础文章标签： windows c++ 视频处理音频编码解码

本文链接：https://blog.csdn.net/weixin_44339850/article/details/112985888

Windows 同时被 2 个专栏收录

15 篇文章

订阅专栏

基础

14 篇文章

订阅专栏

本文深入介绍了微软的MediaFoundation框架，它是Windows平台的下一代多媒体处理技术。MediaFoundation支持流媒体、压缩算法，如无损和有损压缩，以及各种媒体容器格式，如MP4和ASF。文章详细阐述了基础概念，如流、压缩、媒体容器和格式，并提及了增强视频渲染器（EVR）的功能，包括其在视频显示和多流混合中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

序言

介绍

Microsoft Media Foundation是适用于Windows的下一代多媒体平台，使开发人员，消费者和内容提供商能够以更强的健壮性，无与伦比的质量和无缝交互来拥抱新一轮的高级内容。
Media Foundation需要Windows Vista或更高版本。它使用组件对象模型（COM），并且需要C / C ++。Microsoft不提供Media Foundation的托管API。
Media Foundation API是Windows SDK的一部分。要开发Media Foundation应用程序，请安装最新版本的Windows SDK。

可用的基础工具

基础概念 Essential Concepts

流 Streams

流，是一个统一格式的媒体数据序列。其中最常见的是音频流和视频流，但是一个流也可以包含几乎任何种类的数据，包括文本、脚本命令、以及静止图片。在这篇文章里的术语“流”并不特指网络传输中的流。用于本地播放的媒体文件也包含“流”。
通常一个媒体文件要么包含单一的音频流，要么是一个视频流和一个音频流。然而一个媒体文件也可能包含很多个相同类型的流。例如一个视频文件可能包含多种语言的音频流。在运行过程中应用程序去选择播放哪一种语言的音频。

压缩 Compression

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

无损压缩：使用无损算法，复原后的数据与原始数据相同。
有损压缩：使用有损算法，复原后的数据是原始数据的近似值，但不是准确值。

在大多数其他领域中，有损压缩是不可接受的。（想象一下电子表格的“近似值”！）但是有两个原因，有损压缩方案非常适合音频和视频。
第一个原因与人类感知的物理学有关。当我们听复杂的声音（例如音乐录音）时，该声音中包含的某些信息是听不到的。借助信号处理理论，可以分析和分离无法感知的频率。可以消除这些频率，而不会产生感知影响。尽管重建的音频将与原始音频不完全匹配，但它对听众来说听起来是一样的。类似的原理也适用于视频。
其次，根据预期目的，声音或图像质量的某些下降可能是可以接受的。例如，在电话中，音频通常被高度压缩。结果足以进行电话交谈-但却不能用来听音乐。
压缩也称为编码，将进行编码的设备称为编码器。反向过程是解码，该设备自然称为解码器。编码器和解码器的总称是编解码器。编解码器可以用硬件或软件来实现。

媒体容器 Media Containers

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

用于描述流的数量，以及每个流的格式等的文件头。
允许对内容进行随机访问的索引。
描述内容的元数据（例如，文件的作者或标题）。
数据包头，以实现网络传输或随机访问。

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

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

下图显示了媒体容器的典型结构。该图不代表任何特定格式；因为每种格式的细节差异很大。
在这里插入图片描述
请注意，图中所示的结构是分层的，标头信息出现在容器的开头。这种结构是许多（但不是全部）容器格式的代表。还要注意，数据部分包含交错的音频和视频数据包。这种交织在媒体容器中很常见。
术语多路复用是指对音频和视频流进行打包并将包交织到容器中的过程。从打包数据重新组合流的反向过程称为多路分解。

格式 Formats

在数字媒体中，格式一词并不明确。格式可以指代编码的类型（例如H.264视频）或容器的类型（例如MP4）。这种区别通常会使普通用户感到困惑。媒体格式的名称并不总是有用。例如，MP3既指编码格式（MPEG-1音频第3层）又指文件格式。
但是，区别很重要，因为读取媒体文件实际上涉及两个阶段：

首先，必须对容器进行解析。在大多数情况下，直到完成此步骤才能知道流的数量和每个流的格式。
接下来，如果流被压缩，则必须使用适当的解码器对其进行解码。

这种情况下自然衍生了一种软件设计模式，使用单独的组件来解析容器和解码流。另外，此方法适合于插件模型，以便第三方可以提供自己的解析器和编解码器。在Windows上，组件对象模型（COM）提供了一种将API与实现分开的标准方法，这是任何插件模型所必需的，这也是Media Foundation使用COM接口的原因之一。
下图显示了用于读取媒体文件的组件：
在这里插入图片描述
编写媒体文件还需要两个步骤：

编码未压缩的音频/视频数据。
将压缩数据放入特定的容器格式。

下图显示了用于写入媒体文件的组件：
在这里插入图片描述

增强的视频渲染器 Enhanced Video Renderer（EVR）

增强的视频渲染器（EVR）是在用户的监视器上显示视频的组件。存在两种版本的EVR：

EVR媒体接收器，用于Media Foundation应用程序。
EVR筛选器，用于DirectShow应用程序。

两种版本都使用相同的内部对象来渲染视频，并且它们共享许多相同的接口。
EVR最多可以混合16个视频流。第一个输入流称为参照流。参照流通常在z-order的首位。
（窗口的z-order表明了在一堆堆叠的窗口中该窗口的位置。窗口的堆叠是沿bai着一条虚轴—Z轴，从屏幕里向外延伸的。在z-order顶端的窗口将会压在其他窗口上。在z-order底部的窗口将会被其他窗口所压。系统在一个单一的表中维护z-order 。根据窗口是不是顶级窗口，父窗口，子窗口，系统把他们添加到z-order中。顶级窗口将会堆叠在所有非顶级窗口之上，不管它是否是活动窗口或者是前台窗口。）
任何其他流称为子流，并在参照流的顶部混合。应用程序可以更改子流的z-order，但是任何子流都不能在z-order中排在首位。
图形驱动程序确定支持哪些视频格式，但通常仅限于以下几种：

参照流：逐行或交错式的没有单个像素alpha值的YUV（例如NV12或YUY2），或渐进式RGB。
子流：含逐像素alpha值的渐进式YUV，例如AYUV或AI44。

可用的子流格式可能取决于参考流的格式。
在内部，EVR使用称为混合器（mixer）的对象将来自输入流的帧合成到一个表面上进行渲染。混合器还执行去隔行和色彩校正。混合器最终输出混合后的视频帧。再通过第二个对象演示器（presenter）将视频帧渲染到屏幕。演示器安排渲染帧的时间并管理Direct3D设备。应用程序可以提供混合器或演示器的自定义实现。
在这里插入图片描述