OpenCore学习-OpenCore介绍及与stagefright的对比

一、OpenCore简介

        OpenCore是Android的多媒体核心，采用C++实现，定义了全功能的操作系统移植层（OSCL），各种基本的功能均被封装成类的形式，各层次之间的接口多使用继承等方式。

        从宏观上来看，它主要包含了两大方面的内容：

1. PVPlayer：提供媒体播放器的功能，完成各种音频(Audio)、视频(Video)流的回放(Playback)功能。
2. PVAuthor：提供媒体流记录的功能，完成各种音频(Audio)、视频(Video)流的以及静态图像捕获功能 。

二、OpenCore在Android系统中的位置

        首先来一张抽象一点的图（如下）：

        从上图我们可以感觉到OpenCore封装了一些接口给应用程序。具体是什么呢？下面以音频/视频播放器为例，看看具体的过程：

         其中， 

1.  
   1. VideoView.java是一个media集成的高层的JAVA类，这个类的文件在/frameworks/base/core/java/android/widget/。它集成了MediaPlayer和SurfaceView的类，可以作为一个UI元素（View）直接放在界面中，用于视频的播放。
   2. MediaPlayer.java和MediaRecorder.java为基本的处理音频数据的Java类，它里面直接调用很多本地接口。
   3. android_media_MediaPlayer.cpp和android_media_MediaRecorder.cpp封装了相应的JNI接口。

三、多媒体播放的过程

        视频文件（流）播放过程就像一个状态机。图形如下，其中椭圆形代表MediaPlayer类的状态；线代表状态变化，由源状态指向目标状态，它旁边标注有状态变化的条件，其中单箭头的线表示同步（synchronous）方法调用，双箭头表示异步（asynchronous）方法调用。

这幅状态运行图显示了视频播放时的各种状态之间的切换方法，除此之外，为了方便用户处理，在一些状态下，系统会调用回调函数，只要用户提前注册好相应的回调函数即可。

状态	回调函数	注册方法
Error	OnErrorListener.onError()	setOnErrorListener(android.media.MediaPlayer.OnErrorListener)
Prepared	OnPreparedListener.onPrepared()	setOnPreparedListener(android.media.MediaPlayer.OnPreparedListener)
Started	OnBufferingUpdateListener.onBufferingUpdate()	setOnBufferingUpdateListener(OnBufferingUpdateListener)
使用seekTo(int)后	OnSeekComplete.onSeekComplete()	setOnSeekCompleteListener(OnSeekCompleteListener)
PlaybackCompleted	OnCompletionListener.onCompletion()	setOnCompletionListener(OnCompletionListener)

 

四、OpenCore内部的重要概念

　　 OSCL：Operating System Compatibility Library (操作系统兼容库)，包含了一些操作系统底层的操作，为了更好地在不同操作系统移植。包含了基本数据类型、配置、字符串工具、IO、错误处理、线程等内容，类似一个基础的C++库。
　　 PVMF：PacketVideo Multimedia Framework(PV多媒体框架)，在框架内实现一个 文件解析(parser)和 组成(composer)、 编解码的 NODE，也可以继承其通用的接口，在用户层实现一些NODE。

 

五、OpenCore的内部调度过程

        PlayerDriver创建后进入 OSCL线程来处理消息， engine创建完各个 node节点并将其连接起来，剩下的就是node间的通讯问题，各node状态变化会触发oscl对其下一次调度，参与到oscl调度中的模块都必须提供一个 Run函数，oscl会去call这个函数。

        内部流程图如下：

       文件的播放过程如下：

1.  
   1. 判断源文件的格式，根据文件格式创建对应的文件解析节点ParseNode：  PVPlayerRecognizerRegistry负责文件格式识别，并将结果返回给PVPlayerEngine；
   2. 通过文件解析节点（ParseNode）来完成音视频文件格式的解析，并将文件中的音频、视频数据送到对应的解码节点进行解码；
   3. 解码节点（DecNode）通过调用底层的opencoreMAX通用接口实现媒体数据的解码；对于一个普通的视频文件，存在2个解码节点：音频解码节点和视频解码节点；

六、解码的内部流程：

        参考OpenMax的相关介绍。

 

七、Android上的视频输出方案

        为了使opencore的视频播放支持Android系统，谷歌定义了两套视频输出方案，一种是由硬件厂商实现硬件加速的视频输出（ libopencorehw.so），硬件视频输出里面可以调用硬件Overlay模块对输出的视频数据进行硬件混叠，这样输出效率会非常的高；另外一种为谷歌定义的软视频输出，该软视频输出定义为 AndroidSurfaceOutput类，这种方案中系统会调用SurfaceFilnger对输出视频数据进行混叠，该混叠为软件混叠，执行效率比较低。

 

八、OpenCore的测试方式

参考《Build OpenCORE 2.05 on x86 Linux.PDF》和《pvplayer_engine_unit_test_guide.pdf》
 

九、OpenCore与stagefright的对比

1引言
Android froyo版本多媒体引擎做了变动，新添加了stagefright框架，并且默认情况android选择stagefright，弃用之前的opencore，仅仅对opencore中的omx-component部分做了引用。
Stagefright自android2.0后才添加，其稳定性有待商榷，是否存在bug也未知，opencore自android诞生起便存在，稳定性有保障。不过，从目前android代码看，opencore有被stagefright取代的趋势，所以在opencore上所作工作也许会无法沿用。Opencore上的开发较stagefright上要复杂耗时些。

2框架变动
以MediaPlayer为例，我们先看一下多媒体的简单框架。
 
上图可知，stagefright是在MediaPlayerService这一层加入的，和opencore是并列的，在选用opencore还是stagefright的代码切换上也非常容易。
 具体stagefright的内部变动，可见下图概述。Stagefright并没有完全抛弃opencore，主要是做了一个OMX层，用来引用opencore的omx-component部分。而stagefright内部而言，与opencore是完全不同的设计。
 

3具体差异
3.1所支持的文件格式
Opencore所支持的格式。
       
Stagefright所支持的格式。

3.2 Parser和codec部分开发有差异
 Opencore与stagefright两套机制，对于我们的开发而言，主要体现在parser和codec部分。Opencore方面，必须按照其规范完成相应的parser-node，codec则要按照omx规范实现相应的component。Stagefright方面，则要按照其规范实现相应的extractor和decoder。
 最基本的实现，二者是相同的，可以共用，差别在封装上，opencore难度和工作量要大。

3.3 数据处理机制不同
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中为串行处理。

3.4 AV同步
 Opencore有一个主clock，audio/video分别与该主clock同步，作为输出的判定依据，且audio会不断校准主clock。
 Stagefright部分，audio完全是callback驱动数据流，video部分在onVideoEvent里会获取audio的时间戳，是传统的AV时间戳做同步。

3.5 稳定性
 客观来讲，opencore存在时间长，相对稳定；stagefright刚推出，肯定会有未预知的bug存在。

4 总结
1.Opencore相对成熟稳定，作为框架采用，风险小；parser/codec集成相对复杂，如果android后续版本弃用opencore转用stagefright，那多媒体引擎的选择是个问题。
2.Stagefright新推出，肯定有未预知的bug，直接采用有潜在风险；parser/codec集成相对容易，架构较opencore做了极大简化，通俗易懂。
3.目前来看opencore支持的文件格式多些。
4.Opencore与stagefright在数据处理机制及AV同步上有很大差异，需要在实际板子上评估性能差异。
5.如果在android froyo版本开发多媒体相关产品，建议采用opencore框架，这样旧版本opencore上的成果可以沿用，且节省项目时间。
6.Opencore支持的文件格式较stagefright丰富。
7.如果项目研发中android出现新版本，或stagefright做了更新，仍然维持opencore不变，多媒体引擎变更问题待ipad后再议。一种选择是一直延续采用opencore，或者在适当时候（认为stagefright足够稳定）切换到stagefright。

Stagefright阅读笔记附录
两套方案对比过程中，基本上把stagefright的代码阅读过一遍，摘录如下，以图为主。
Stagefright整体框图。
 
Stagefrightplayer里awesomeplayer初始化流程
 
Awesomeplayer框图，其中涵盖主要节点元素。
 
Stagefrightrecorder部分
 
MediaPlayer框图。
 
MediaRecorder框图。
 
Libstagefright草图，涵盖了主要节点元素。
 

转:http://blogold.chinaunix.net/u2/61880/showart.php?id=2339481

http://blog.csdn.net/ponder008/article/details/6414103#comments