Android多媒体开发-stagefright及AwesomePlayer相关知识梳理

android的多媒体框架中， stagefright其实是AwesomePlayer的代理，就是个皮包公司。

  View Code

功能几乎都是通过调用  

  View Code

成员变量来实现的，看来真正实现播放器功能的原来是 AwesomePlayer。Stagefright只是做了一层浅浅的封装。

AwesomePlayer 不管他有多神秘，说到底还是个多媒体播放器。在播放器的基本模型上，他与VCL、mplayer、ffmpeg等开源的结构是一致的。只是组织实现的方式不同。

深入了解AwesomePlayer 之前，把播放器的基本模型总结一下，然后按照模型的各个部分来深入研究AwesomePlayer 的实现方式。

说白了播放器大致分为4大部分：source、demux、decoder、output。

1.source：数据源，数据的来源不一定都是本地file，也有可能是网路上的各种协议例如：http、rtsp、HLS等。source的任务就是把数据源抽象出来，为下一个demux模块提供它需要的稳定的数据流。demux不用关信数据到底是从什么地方来的。

2.demux解复用：视频文件一般情况下都是把音视频的ES流交织的通过某种规则放在一起。这种规则就是容器规则。现在有很多不同的容器格式。如ts、mp4、flv、mkv、avi、rmvb等等。demux的功能就是把音视频的ES流从容器中剥离出来，然后分别送到不同的解码器中。其实音频和视频本身就是2个独立的系统。容器把它们包在了一起。但是他们都是独立解码的，所以解码之前，需要把它分别 独立出来。demux就是干这活的，他为下一步decoder解码提供了数据流。

3.decoder解码：解码器--播放器的核心模块。分为音频和视频解码器。影像在录制后, 原始的音视频都是占用大量空间, 而且是冗余度较高的数据. 因此, 通常会在制作的时候就会进行某种压缩 ( 压缩技术就是将数据中的冗余信息去除数据之间的相关性 ). 这就是我们熟知的音视频编码格式, 包括MPEG1（VCD）\ MPEG2（DVD）\ MPEG4 \ H.264 等等. 音视频解码器的作用就是把这些压缩了的数据还原成原始的音视频数据. 当然, 编码解码过程基本上都是有损的 .解码器的作用就是把编码后的数据还原成原始数据。

4.output输出：输出部分分为音频和视频输出。解码后的音频（pcm）和视频（yuv）的原始数据需要得到音视频的output模块的支持才能真正的让人的感官系统（眼和耳）辨识到。

所以，播放器大致分成上述4部分。怎么抽象的实现这4大部分、以及找到一种合理的方式将这几部分组织并运动起来。是每个播放器不同的实现方式而已。

接下来就围绕这4大部分做深入分析。

 

上文已经大概介绍了播放器的几大主要部分，但是有了这些功能组件也不能叫做播放器。需要某种方式将这些单独的功能组件驱动起来，形成一个整体的功能。

视频处理过程中有很多都是十分耗时的，如果都放在一个大的线程空间中。用户体验的效果可想而知。所以通常都是做异步操作。

AwesomePlayer是通过event事件调度来实现这些功能之间的驱动和调用的。

AwesomePlayer中的内部变量

  View Code

这个mQueue就是AwesomePlayer的事件队列，也是事件调度器。从他类型的名字上就能很清楚的看出他是以时间为基础事件队列。接下来看看它是怎么玩转的。

1.先来看TimedEventQueue的内部结构，TimedEventQueue内部有一个 List<QueueItem>，每个QueueItem包含enent和时间

  View Code

有一个独立线程threadEntry是在TimedEventQueue::start被创建，TimedEventQueue::stop被销毁的。

  View Code

2.List<QueueItem>目的就是按照延时时间维护一个event事件队列，threadEntry线程就是不断的从队列的头取出一个event，然后通过  event->fire(this, now_us); 回调到这个event事件提前注册好的相对应功能函数。 

3.然后看看AwesomePlayer是怎么用TimedEventQueue，AwesomePlayer会定义很多类型的event事件，并把和这些事件相关的功能函数一定绑定起来。

  View Code

  原因之前也说了，因为好多音视频处理的功能是十分耗时间的，假如AwesomePlayer 想用某个功能，他并不是直线去调用它，而是抽象成一种AwesomeEvent，将想要调用的功能函数与事件捆绑。通过TimedEventQueue::postTimedEvent(),按照延时的优先顺序把它放到TimedEventQueue的队列之中。然后AwesomePlayer就不管了。TimedEventQueue start之后，自己内部的线程会从队列中依次取出这些事件，然后通过event->fire回调事件的功能函数。这样就达到了AwesomePlayer的目的。

4.之前也介绍过mediaPlayer大致流程就是

mediaPlayer.setDataSource(path);  
mediaPlayer.prepare();  
mediaPlayer.start(); 

在AwesomePlayer 也是这种流程，在AwesomePlayer prepare（）相关函数中。

  View Code

并没有实际的调用onPrepareAsyncEvent（）真正的功能函数，他只是把mQueue start之后，然后创建个mAsyncPrepareEvent事件，把它插入到mQueue之中就不管了，具体调用是由mQueue中的threadEntry线程来做。

 

 

1.通过setDataSource 指定播放器的数据源。可以是URI或者fd.可以是http:// 、rtsp://、本地地址或者本地文件描述符fd。其最终调用是将上层传递来的参数转化为DataSource，为下一步的demux提供数据支持。

2.在真正Prepare功能函数onPrepareAsyncEvent()会调用finishSetDataSource_l。通过第一步产生的DataSource来生成extractor，因为封装的格式很多，所以需要通过DataSource的信息，去创建不同的extractor。

  View Code

  View Code

3.得到extractor之后，通过setVideoSource() setAudioSource()产生独立的mVideoTrack(视频)、mAudioTrack(音频)数据流，分别为音视频解码器提供有各自需要的数据流。

其实extractor和mVideoTrack、mAudioTrack就组成了播放器模型中的demuxer部分。把封装格式里面的音视频流拆分出来，分别的送给音视频解码器。

 

4.接下来就是initVideoDecoder() initAudioDecoder().依赖上面产生的mVideoTrack(视频)、mAudioTrack(音频)数据流。生成了mVideoSource和mAudioSource这两个音视频解码器。不同类型匹配不同的解码器。

  View Code

mVideoSource、mAudioSource组成了播放器模型中的decoder部分。

 

android系统中的编解码器部分用的是openmax，以后会深入了解。openma x是一套标准接口，各家硬件厂商都可以遵循这个标准来做自己的实现，发挥自己芯片特性。然后提供给android系统来用。因为大部分的机顶盒芯片产品硬件的编解码是它的优势，可以把这种优势完全融入到android平台中。以后手机高清视频硬解码也会是个趋势。

5.解码完之后的数据就要输出了。AwesomePlayer分别用了mVideoRenderer做视频输出、mAudioPlayer做音频输出。他们分别调用android图像和音频的相关服务。这俩部分是android平台中十分重要的2块，以后会深入了解。

mVideoRenderer和mAudioPlayer就组成了播放器中output的部分。

 

综上AwesomePlayer的整体框架和流程就清晰了，其实也脱离不了DataSource、demux、decoder、output这4大部分。接下来会分别了解每个部分是怎么实现的。

1.openmax 简介

http://www.khronos.org/openmax/

OpenMax是一个多媒体应用程序的框架标准，由NVIDIA公司和Khronos在2006年推出。

OpenMAX分为3层：

第一层：OpenMax DL（Development Layer，开发层）

第二层：OpenMax IL（Integration Layer，集成层）

第三层：OpenMax AL（Appliction Layer，应用层）

2.OpenMax IL简介

OpenMax IL 处在中间层的位置，OpenMAX IL 作为音频，视频和图像编解码器 能与多媒体编解码器交互，并以统一的行为支持组件（例如资源和皮肤）。这些编解码器或许是软硬件的混合体，对用户是 的底层接口应用于嵌入式或 / 和移动设备。它提供了应用程序和媒体框架， 透明的。本质上不存在这种标准化的接口，编解码器供 应商必须写私有的或者封闭的接口，集成进移动设备。 IL 的主要目的 是使用特征集合为编解码器提供一个系统抽象，为解决多个不同媒体系统之间轻便性的问题。

OpenMax IL 的目的就是为硬件平台的图形及音视频提供一个抽象层，可以为上层的应用提供一个可跨平台的支撑。这一点对于跨平台的媒体应用来说十分重要。本人也接触过几家高清解码芯片，这些芯片底层的音视频接口虽然功能上大致相同，但是接口设计及用法上各有不同，而且相差很多。你要想让自己开发的媒体应用完美的运行在不同的硬件厂商平台上，就得适应不同芯片的底层解码接口。这个对于应用开发来说十分繁琐。所以就需要类似于OpenMax IL 这种接口规范。应用假如涉及到音视频相关功能时，只需调用这些标准的接口，而不需要关心接口下方硬件相关的实现。假如换了硬件平台时，只需要把接口层与硬件适配好了就行了。上层应用不需要频繁改动。

你可以把OpenMax IL 看作是中间件中的porting层接口，但是现在中间件大部分都是自家定义自己的。

OpenMax 想做的就是定义一个这样的行业标准，这样媒体应用、硬件厂商都遵循这种标准。硬件厂商将OpenMax 与处理器一并提供，上层的多媒体框架想要用到硬件音视频加速功能时，只需遵循openmax的接口就可以扩平台运行。

可喜的，现在越来越多的多媒体框架及多媒体应用正在遵循openmax标准，包括各种知名的媒体开源软件。越来越多的芯片厂商也在遵循openmax的标准。对于现在的音视频编解码来说，分辨率越来越高，需要芯片提供硬件加速功能是个大的趋势。我相信 接口的标准化是一定要走的。

3.OpenMax IL结构

OpenMax IL主要内容如下所示。

 客户端（Client）：OpenMax IL的调用者

 组件（Component）：OpenMax IL的单元，每一个组件实现一种功能

 端口（Port）：组件的输入输出接口

 隧道化（Tunneled）：让两个组件直接连接的方式

组件、端口、隧道化思想和GStreamer 中的 pipeline 十分类似。

Component实现单一功能、或是Source、Host、Accelerator和Sink。

Port 是 Component对外的输入输出口。

通过Tunneled 将单一Component串联起来形成一个完整功能。

OpenMax Core是辅助各个组件运行的部分

        

4.Component内部结构

 

Component 的基本模型如上图，可以把它想象成一个加工车间：

输入端口输入材料

输出端口输出加工完成品

通过handle 来给车间发送指令或者或者状态

将事件及时发送给车间外部管理者

1.android中用openmax来干啥？

有了上一篇AwesomePlayer基本框架及播放流程已经很清楚的看到了，android中的 AwesomePlayer就是用openmax来做(code)编解码,其实在openmax接口设计中，他不光能用来当编解码。通过他的组件可以组成一个完整的播放器，包括sourc、demux、decode、output。但是为什么android只用他来做code呢？我认为有以下几方面：

 

1.在整个播放器中，解码器不得不说是最重要的一部分，而且也是最耗资源的一块。如果全靠软解，直接通过cpu来运算，特别是高清视频。别的事你就可以啥都不干了。所以解码器是最需要硬件提供加速的部分。现在的高清解码芯片都是主芯片+DSP结构，解码的工作都是通过DSP来做，不会在过多的占用主芯片。所有将芯片中DSP硬件编解码的能力通过openmax标准接口呈现出来，提供上层播放器来用。我认为这块是openmax最重要的意义。

 

2.source 主要是和协议打交道，demux 分解容器部分，大多数的容器格式的分解是不需要通过硬件来支持。只是ts流这种格式最可能用到硬件的支持。因为ts格式比较特殊，单包的大小太小了，只有188字节。所以也是为什么现在常见的解码芯片都会提供硬件ts demux 的支持。

 

3.音视频输出部分video\audio output 这块和操作系统关系十分紧密。可以看看著名开源播放器vlc。vlc 在mac、linux、Windows都有，功能上差别也不大。所以说他是跨平台的，他跨平台跨在哪？主要的工作量还是在音视频解码完之后的输出模块。因为各个系统的图像渲染和音频输出实现方法不同，所以vlc需要针对每个平台实现不同的output。这部分内容放在openmax来显然不合适。

 

所以openmax 中硬件抽象的编解码是最为常用的，也是为什么android中只用它来抽象code。

2.android中openmax实现框架

 

1.上面已经说过了，android系统中只用openmax来做code，所以android向上抽象了一层OMXCodec，提供给上层播放器用。

播放器中音视频解码器mVideosource、mAudiosource都是OMXCodec的实例。

 

2.OMXCodec通过IOMX 依赖binder机制 获得 OMX服务，OMX服务 才是openmax 在android中 实现。

 

3. OMX把软编解码和硬件编解码统一看作插件的形式管理起来。

 

AwesomePlayer 中有个变量 

1. OMXClient mClient;  

让我们看看   OMXClient 

OMXClient 有个IOMX 的变量 mOMX ，这个就是和OMX服务进行binder通讯的。

在 AwesomePlayer 的构造函数中会调用 

  View Code

OMXClient::connect函数是通过binder机制 获得到MediaPlayerService，然后通过MediaPlayerService来创建OMX的实例。这样OMXClient就获得到了OMX的入口，接下来就可以通过binder机制来获得OMX提供的服务。

也就是说OMXClient 是android中 openmax 的入口。

 

在创建音视频解码mVideoSource、mAudioSource的时候会把OMXClient中的sp<IOMX> mOMX的实例 传给mVideoSource、mAudioSource来共享使用这个OMX的入口。

也就是说一个AwesomePlayer对应着 一个IOMX 变量，AwesomePlayer中的音视频解码器共用这个IOMX变量来获得OMX服务。

  View Code

  View Code

转自 http://www.cnblogs.com/shakin/p/4463639.html