嵌入式系统多媒体框架分析

1 Android系统的多媒体框架

        Google正式对外发布的Android版本，在Android2.3版本之前，使用的是Opencore多媒体框架，Android2.3版本及之后的Android系统，以Stagefright多媒体框架取代Opencore多媒体框架。Opencore多媒体框架结构过于庞大复杂，Stagefright多媒体框架提高了多媒体框架的灵活性和可开发性。

1.1 Opencore

        Android系统的Opencore多媒体框架，基于第三方PacketVideo 公司的Opencore platform来实现。支持所有通用的音频，视频，静态图像格式codec。使用OpenMAX 1L interface 接口进行扩展，可以方便得支持hardware / software codec plug-ins。

Opencore的优点是兼顾了跨平台的移植性，其缺点是过于庞大复杂，需要耗费较多时间维护。

1.2 Stagefright

        在Google正式发布Android2.3 Gingerbread之后，多媒体框架默认预设Stagefright，但是该框架也保留了Opencore的可移植性。架构相对Opencore而言较为简洁，更容易维护。

Stagefright框架中，比较重要的部分是AwesomePlayer、AudioPlayer、MediaExtractor和ColorConverter。AwesomePlayer和AudioPlayer负责播放音视频图像和声音，MediaExtractor负责处理多媒体文件的解析，Color Converter负责图像色彩空间的转换。

Stagefright框架在MediaPlayerService层实现了一个OMX层，对Opencore的omx组件部分做了引用。

 图一  Stagefright框架图

1.3 Opencore/Stagefright的差异

1）支持的文件格式不同：

         Opencore比Stagefright支持的音视频编解码格式更多；

2）Parser和codec部分开发有差异：

        Opencore框架中，parser必须按照其规范完成相应的parser-node，codec必须要实现相应的组件，parser和codec分离；Stagefright框架中，只需要按照其规范实现相应的extractor和decoder，parser和codec捆绑在一起。

3）数据处理机制不同：

        Opencore框架中，通过节点控制输出，节点并行处理数据，有一个判定AV同步的依据，设定一个主时钟，使audio/video分别与主时钟同步，且音频会不断校准主时钟；Stagefright框架中，通过事件（callback和videoevent）来驱动数据输出，串行处理数据，利用传统的利用时间戳的AV同步方式，用callback驱动audio数据流，video部分用onVideoEvent事件获取audio的时间戳。

 

2  Linux系统的多媒体框架

 

2.1 Gstreamer

        GStreamer 是 GNOME 桌面环境下用来构建流媒体应用的多媒体框架（framework）。它是一个开源的多媒体框架库，利用它，可以构建一系列的媒体处理模块，包括从简单的播放功能到复杂的音频（混音）和视频（非线性编辑）的处理。

        GStreamer是一个基于管道的多媒体框架，采用c语言开发，基于GObject。是跨平台的，包括Linux (x86, PowerPC and ARM), Solaris (Intel and SPARC) and OpenSolaris, FreeBSD, OpenBSD, NetBSD, Mac OS X, Microsoft Windows and OS/400。

        GStreamer通过把若干elements链接在一起构成pipeline实现对媒体内容的处理，element通过plug-in的方式提供。bin是一种特殊的element，是由多个其它elements组成的。

element之间通过pad进行数据通讯，一个element的源pad可以链接到另一个element的sink pad。pad之间的数据类型通过capability来协商。pipeline有多种状态，当处于playing状态的时候，数据buffer就从源pad向sink pad传送。

        GStreamer的核心实现了对plug-in的注册和加载等功能，plug-in是以动态库的形式存在的。当需要某个element的时 候，Gstreamer就动态的加载对应的动态库。可以通过编写plug-in方式对gstreamer的功能进行扩展，包括编码方式，封装格式等各种功能。

图二  GStreamer pipeline

       GStreamer采用基于插件（plugin）和管道（pipeline）的体系结构，框架中的所有的功能模块都被实现成可以插拔的组件（component），能够很方便地安装到任意管道上。GStreamer使用插件架构并造就了大量的GStreamer的共享库。

图三 Gstreamer overview

2.1 Phonon

        Phonon是KDE 4的多媒体API 。Phonon提供一个稳定的API允许KDE 4独立于任何一个声音系统服务器如xine。

     使用了phonon，用四行C++程式码就能播放档案 ，而旧声音框架（aRts)则需要用到30行.

 media = new MediaObject(this);
 connect(media, SIGNAL(finished()), SLOT(slotFinished()));
 media->setCurrentSource("/home/username/music/filename.ogg");
 media->play();

     Phonon并非只能运行于Unix系统，他的后端可以是在其它平台如 Microsoft Windows 并提供相同的功能。

• Phonon让各种后端提供界面给开发者所谓的"引擎"；每个引擎运作在一个具体的后端。每个后端都可让Phonon控制基本功能，如播放、暂停和搜寻。Phonon也支持更高层次的功能，如让音轨转化之间变微弱。^[3]
• 使用Solid，Phonon将给予用户更多配件的控制能力如耳机、扬声器、麦克风。一个例子是，因为你可能只有一个VoIP会话使用您的耳机，但所有其他的声音通过扬声器出来。^[3]
• 支援 Unix-like 系统下的后端xine、VLC、MPlayer。^[4]
• 支援 Windows 下的后端 DirectShow、VLC和MPlayer.
• 支援 Mac OS X下的后端QuickTime

3 Windows系统的多媒体框架

3.1 DirectShow

        DirectX软件开发包是微软公司提供程序员的一套在Windows操作平台上开发高性能图形、声音、输入、输出和网络游戏的编程接口。微软将DirectX定义为“硬件设备无关性”，即使用DirectX可以用于设备无关的方法提供设备相关的（高）性能。DirectX标准的建立，可以为硬件开发提供策略，硬件厂商不得不按照这一标准进行产品改进，同时，通过使用DirectX所提供的接口，开发人员可以尽情地利用硬件可能带来的高性能，而无需关系硬件的具体执行细节。

        DirectX采用了COM（组件对象模型）标准，因此不同对象的版本可以有不同的接口，这使用DirectX开发的程序即使在未来也能得到完全的兼容和支持。

    DirectShow是DirectX家族成员中为在Windows平台上处理各种格式的多媒体文件的回放、音视频采集等高性能要求的多媒体应用提供了完整的解决方案；DirectShow集成了DirectX家族中其他成员（如DirectDraw、DirectSound等）的技术，为我们的多媒体应用提供了一下的方便：

（1）、保证了数据量巨大的多媒体应用数据处理的高效性；

（2）、解决了音频和视频时刻保持同步；

（3）、用最简单的方法处理复杂的多媒体源问题，包括本地文件、计算机网络、广播电视以及其他一些数码产品等；

（4）、提供了解决处理各种多媒体格式文件的方法；

（5）、支持目标系统中不可预知的硬件变动。

 DirectShow使应用程序开发人员从复杂的数据传输、硬件差异、同步性等工作解脱出来，总体应用框架和底层工作由DirectShow来完成。

图四 DirectShow系统框图

4  其他媒体相关资源参考

Phonon:http://zh.wikipedia.org/wiki/Phonon_(KDE)

Mplayer:http://zh.wikipedia.org/wiki/MPlayer

Xine:http://zh.wikipedia.org/wiki/Xine

VLC:http://zh.wikipedia.org/wiki/VLC

本文参考：http://wenku.baidu.com/link?url=aHYzfzUFoqG_dp3RyFNashBuLNbR7amNsmSIqtziR3yzEKennxWD3cJAybhUlGWLEHb3GeC8SMMGlJ_a9wSc9fWoXrACcxJ4GOFchpy7ri7