下一代多媒体设备交付的开放标准

消费者对他们的多媒体设备的期望越来越高，这迫使应用程序开发人员跟上。幸运的是，带有标准组件的中间件框架正在出现以帮助设计人员。Fakhir 介绍了 OpenMAX 多媒体框架并说明了它如何改变多媒体设备的开发。

一个渐进但革命性的变化正在改变当今软件应用程序中使用多媒体的方式。不久前，大多数多媒体供应商都有自己的实施方案。代码互操作性和可移植性通常不是主要要求。但现在，随着硬件越来越强大，终端用户的需求越来越大，多媒体领域已经向各个方向扩展。

这种扩展现在已经达到了单个供应商无法满足所有要求的程度。加速硬件、编解码器、容器格式、网络流媒体和其他高度专业化的子域已经出现。这种增长引发了人们感知多媒体服务方式的重大转变。

从服务到框架

为了理解这种转变，开发人员必须检查传统的多媒体库。这些库通常具有静态结构并提供一组固定的服务。所提供的服务是确定性的，例如“播放 WAV 文件”或“播放 MP3 文件”。API 本身是特定于供应商的，为一个多媒体库编写的应用程序通常不能移植到另一个。库实现保持不透明，限制了自定义或扩展的选项。

为了满足不断扩展的多媒体领域不断增长的需求，软件供应商已将他们的重点转移到多媒体框架上，如图 1 所示。框架是来自不同来源的软件的异构混合物。多媒体框架的关键特性是一个灵活和可扩展的架构，它允许框架提供的服务随着行业不断变化的需求而发展。

图1

多媒体框架的灵活性是通过利用组件的概念来实现的。组件就像简单的构建块一样执行，它们组合在一起形成更复杂的系统。框架 API 不提供对特定服务的访问，而是允许开发人员根据设计要求组装不同的组件。该框架独立于这些组件实际执行的操作以及它们的执行方式。

为什么框架范式在多媒体上运行良好？答案在于多媒体处理的本质。多媒体处理本质上涉及通过不同阶段的线性数据流。每个阶段都有明确的定义，并且在逻辑上独立于其他阶段。因此，以管道形式线性排列的组件自然适合多媒体。图 2 显示了音频播放的示例管道。多媒体数据从一端流入，并在从另一端离开管道时由不同的组件处理。

图 2

多媒体框架优势

没有例子就很难实现这个概念的力量。框架通常包含丰富的组件库。表 1 对四种类型的组件进行了分类。框架用户通常会从表格的每一列中选择一个组件，并将生成的四个组件组成一个管道。很容易看出，使用这些示例组件可以进行多种配置。例如，MP4 解复用器、MPEG4 解码器、视频缩放和视频输出组件可以连接在一起以显示视频。为该视频添加对字幕的支持就像将字幕组件添加到管道一样简单。

框架的一个重要特征是每个组件都与其他组件松散耦合，因此易于替换。例如，可以用硬件加速的视频解码器代替标准视频解码器。增强现有应用程序被简化，因为用户只需添加或替换现有组件具有更多增强版本。

标准化确保互操作性

每个组件的内部逻辑都封装在标准组件定义中。这种标准化和前面提到的松散耦合提供了一个很好的平台来确保不同软件供应商编写的组件之间的互操作性。几个软件供应商可能会为一个框架做出贡献，他们的所有组件都可以无缝地配合和协同工作。框架也可用作软件集成工具。

当今使用的更流行的多媒体框架通常依赖于平台。示例包括用于 MS Windows 的 DirectX 和用于 Linux 的 GStreamer。但是标准化已经提高了一个档次。Khronos 等跨行业组织已经对框架定义本身进行了标准化。一个中立组织的开放、免版税框架定义鼓励了软件供应商之间的合作。Khronos 定义的多媒体框架称为 OpenMAX （www.khronos.org/openmax/）。尽管这是一个新标准，但已有多家公司采用了它。

OpenMAX 标准由三个级别组成，如图 3 所示。到目前为止所讨论的内容对应于定义基于组件的框架的 OpenMAX 集成级别 （IL）。IL 级别之上和之下的其他两个级别解决了框架同样重要的方面：实现和使用。

图 3

为多媒体框架编写组件

组件库是多媒体框架中最大的功能区域，涉及软件和芯片供应商的最大努力。供应商通常专注于某些服务；例如，软件供应商可能专门提供 MPEG4 等视频编解码器。一旦嵌入到框架的组件中，这个特定的编解码器就可以成为多媒体框架的一部分。供应商将服务封装到组件中，使其标准化并易于插入现有软件，从而为广泛使用其产品开辟了机会。

多媒体框架的另一个显着特征是它允许将第三方服务集成到组件中很容易。框架为此目的提供了特殊的工具和技术。

鉴于这些辅助工具通常因框架而异，本次讨论将集中在 OpenMAX 框架相关的功能，特别是 Mentor Graphics 的 Nucleus Multimedia Framework 实现。

多媒体数据处理对时间非常关键。数据必须实时压缩、解压缩或转换为其他格式。这种数据处理采用必须高度优化的计算密集型算法。OpenMAX Development Level （DL） 解决了这一重要的优化领域，为大量与多媒体处理相关的常用算法提供了一个 API。

服务提供商不必担心实施和优化这些算法；他们只是在他们的软件中使用 OpenMAX DL API。然后，这些 API 的实际实现由此类系统中的另一个利益相关者（即硅供应商）提供。硅供应商实施所有 OpenMAX DL 定义的算法，这些算法专门针对供应商的硬件平台进行了优化。这通过允许他们的软件在硬件上有效运行而使软件供应商受益，并通过确保为其平台编写的软件充分利用硬件来帮助硅供应商。

框架组件执行许多常见操作，例如管理缓冲区、维护组件状态和保护数据。一些框架通过允许组件层次结构来简化组件编写者的任务。一个通用基础组件提供所有通用功能以及可以从该基础组件派生的其他组件，如图 4 所示。使用面向对象的设计原则，派生组件继承基础组件的属性，最大限度地减少冗余并帮助组件作家只专注于他们的特定服务。

图 4

因为框架充当来自不同来源的软件的异构混合，组件编写者可能并不总是熟悉另一个组件。这就是框架提供的其他调试和开发工具发挥作用的地方。调试工具至关重要，因为它们有助于可视化多媒体管道并定位问题。图 5 表示使用 Nucleus Multimedia Framework 调试器的实时组件管道。

图 5

在软件应用程序中使用多媒体框架

尽管基于组件的框架具有优势，但这些类型的 API 并不容易被应用程序开发人员接受，他们习惯于简单的 API，例如“播放 MP3 文件”。必须创建组件，将它们连接在一起，然后使用它们‚Äì 无论多么简单的操作‚Äì 都没有提供足够的抽象级别来证明它们的使用是合理的。

OpenMAX 应用层 （AL） 旨在解决这些问题，提供易于使用的 API，隐藏了底层框架的机制。这也使用户应用程序更具可移植性，因为它们使用跨所有硬件平台一致的开放标准，而不是依赖专有 API。

最近，一些框架已经转移到更高的抽象层次。开发人员不提供编程语言 API，而是通过在简单的 XML 中定义应用程序来创建应用程序。这种技术在用户界面应用程序中流行起来。在如此高的水平上集成多媒体框架使多媒体能够以迄今为止不可能的方式使用。

简化集成的 API

嵌入式行业正在加速努力建立免版税的 API，以支持媒体创作并促进在各种平台和设备上的采用。Khronos Group 密切参与了这些努力，其媒体库可移植性的 OpenMAX 标准正在获得强大的动力。

OpenMAX 跨平台 API 支持跨多个操作系统和硅平台开发、集成和编程来自不同软件供应商的加速多媒体组件。通过这种方法，嵌入式设备集成商可以利用来自任何软件供应商的库和编解码器组件，只要它们基于 OpenMAX API 构建，同时实现新硅平台的全部加速潜力。结果将是具有最先进多媒体功能的设备以硅片速率交付给消费者。

审核编辑：郭婷