Android Media Framework(1): 总纲
转自:http://www.jianshu.com/users/5ba48666a89d/latest_articles
Android系统整体架构：
我们先看一下多媒体框架在整个Android系统所处的位置
从框架图可以看出Media Framework处于Libraries这一层，这层的Library不是用Java实现，一般是C/C++实现，它们通过Java的JNI方式调用。
Android系统的多媒体业务：
多媒体框架变动：
Android froyo版本多媒体引擎做了变动，新添加了stagefright框架，并且默认情况android选择stagefright，弃用之前的opencore，仅仅对opencore中的omx-component部分做了引用。Stagefright自android2.0后才添加，其稳定性有待商榷，是否存在bug也未知，opencore自android诞生起便存在，稳定性有保障。
Opencore上的开发较stagefright上要复杂耗时些。不过，从目前android代码看，opencore有被stagefright取代的趋势，从Android2.3 (Gingerbread) 开始，预设的多媒体框架为 Stagefright。
以MediaPlayer为例，我们先看一下多媒体的简单框架。
上图可知，stagefright是在MediaPlayerService这一层加入的，和opencore是并列的，在选用opencore还是stagefright的代码切换上也非常容易。
OpenCore框架介绍：
Open Core是Android 多媒体框架的核心，所有Android平台的音视频采集，播放的操作都是通过它来实现。它也被称为PV(Packet Video), Packet Video是一家专门提供多媒体解决方案的公司。
通过Open Core程序员可以方便快速的开发出想要的多媒体应用程序，例如：音视频的采集，回放，视频会议，实时的流媒体播放等等应用。在实际开发中我们并不会过多的研究Open Core的实现，Android提供了上层的Media API给开发人员使用，MediaPlayer和MediaRecorder。
CODEC(编解码器)使用OpenMAX IL interface 接口进行扩展，可以方便得支持hardware / software codec plug-ins，支持的格式包括：MPEG4、H.264、MP3、AAC、AMR、JPG、PNG、GIF等。
Open Core的代码在Android代码的External/Opencore目录中。这个目录是OpenCore的根目录，其中包含的子目录如下所示：
· android：这里面是一个上层的库，它实现了一个为Android使用的音视频采集，播放的接口，和DRM数字版权管理的接口实现。
· baselibs：包含数据结构和线程安全等内容的底层库
· codecs_v2：音视频的编解码器，基于OpenMAX实现
· engines：核心部分，多媒体引擎的实现
· extern_libs_v2：包含了khronos的OpenMAX的头文件
· fileformats：文件格式的解析（parser）工具
· nodes：提供一些PVMF的NODE，主要是编解码和文件解析方面的。
· oscl：操作系统兼容库
· pvmi： 输入输出控制的抽象接口
· protocols：主要是与网络相关的RTSP、RTP、HTTP等协议的相关内容
· pvcommon：pvcommon库文件的Android.mk文件，没有源文件。
· pvplayer：pvplayer库文件的Android.mk文件，没有源文件。
· pvauthor：pvauthor库文件的Android.mk文件，没有源文件。
· tools_v2：编译工具以及一些可注册的模块。
StageFright框架介绍：
具体stagefright的内部变动，可见下图概述。Stagefright并没有完全抛弃opencore，主要是做了一个OMX层，用来引用opencore的omx-component部分。而stagefright内部而言，与opencore是完全不同的设计。
Stagefright的内部组成模块
AwesomePlayer的内部组成模块
调用openMAX IL层时的Video Buffer传输流程
Video Rendering内部组成模块
Video Playback流程
VideoEvent事件驱动
Audio Playback流程
awesomeplayer初始化流程
两个框架之间的具体差异：
Opencore所支持的格式
Stagefright所支持的格式
Opencore与stagefright两套机制，对于我们的开发而言，主要体现在parser和codec部分。Opencore方面，必须按照其规范完成相应的parser-node，codec则要按照omx规范实现相应的component。Stagefright方面，则要按照其规范实现相应的extractor和decoder。 最基本的实现，二者是相同的，可以共用，差别在封装上，opencore难度和工作量要大。
Opencore处理流程如下图示
engine分别创建audio/video datapath，parser/dec/sink作为node节点由各自datapath连接起来，后续node节点由统一调度器调度。
Stagefright处理流程如下图示。
Audioplayer为AwesomePlayer的成员，audioplayer通过callback来驱动数据的获取，awesomeplayer则是通过videoevent来驱动。二者有个共性，就是数据的获取都抽象成mSource->Read()来完成，且read内部把parser和dec绑在一起。
Opencore和stagefright处理机制对比：
（1）Opencore的parser与dec是分离的，各行其职；stagefright则是绑在一起作为一个独立的原子操作。
（2）Stagefright通过callback和videoevent来驱动数据输出；opencore是通过sink-node节点控制输出。
（3）Opencore中parser/dec/sink是并行处理的；stagefright中为串行处理。
Opencore有一个主clock，audio/video分别与该主clock同步，作为输出的判定依据，且audio会不断校准主clock。
Stagefright部分，audio完全是callback驱动数据流，video部分在onVideoEvent里会获取audio的时间戳，是传统的AV时间戳做同步。
- Opencore相对成熟稳定，作为框架采用，风险小；parser/codec集成相对复杂，如果android后续版本弃用opencore转用stagefright，那多媒体引擎的选择是个问题。
- Stagefright新推出，肯定有未预知的bug，直接采用有潜在风险；parser/codec集成相对容易，架构较opencore做了极大简化，通俗易懂。
- 目前来看opencore支持的文件格式多些。
- Opencore与stagefright在数据处理机制及AV同步上有很大差异，需要在实际板子上评估性能差异。
- 如果在android froyo版本开发多媒体相关产品，建议采用opencore框架，这样旧版本opencore上的成果可以沿用，且节省项目时间。
- Opencore支持的文件格式较stagefright丰富。
stagefright框架中调用OMX的时序图
Openmax架构在Android中位置
Openmax架构
