在开始正式的学习前,我们先来聊一聊Android音视频开发中的一些问题、感受与想法。(有一点要事先说明,我的问题与答案、想法并不一定正确,请读者带着审慎的思考来阅读,后续的文章也是一样,希望读者边阅读边思考,看到错误可以指出让我改正,如有问题也可以提出一起讨论。)
-
为什么要有Android OpenMAX?
- Android系统可以跑在多种类型的设备上,比如说手机、电视、平板或者是现在的车机上,这些设备会有不同的芯片,手机用的比较多的是海思、高通、联发科,电视见的比较多的是AML、RTK,这些芯片厂商会有自己编解码器的实现(VPU API),Android作为一个通用的平台为了调用不同芯片的VPU API引入了OpenMAX框架,各大厂商实现Android OpenMAX框架提供的接口之后,开发者就可以用统一的接口使用硬件编解码了。
-
Android OpenMAX(OMX)和OpenMAX有什么异同?
- 在网上搜寻资料,一般介绍OpenMAX框架会包含三层,自上而下分别是OMX AL层、OMX IL层、OMX DL层,每一层都定义有一套标准的API,但是在Android中只用到了IL层的部分并且做了部分裁减。
-
OMX IL层包含哪些内容呢?
- 简单来讲,OMX IL层定义了
编解码组件的结构
(我们应该如何实现OMX组件,一个OMX组件包含哪些东西)、组件的调用接口
(我们应该如何获取、管理、调用、控制OMX组件)。
- 简单来讲,OMX IL层定义了
播放器可以分为如下几个部分:IO、Demux、Control、Decoder、Render,一般来说IO和Demux可以看作是一部分,Control用于控制IO-Demux、Decoder、Render协同工作,数据在三个组件之间来回流转,所以我觉得播放器控制,实际指的是Buffer流转的控制,Buffer传递方式的控制。
回到Decoder中来,我们在看ACodec、OpenMAX代码时可能会感觉写的十分复杂,这是因为考虑了非常多的情况,以Buffer传递方式为例:
- 对于普通Input buffer或者是普通Output Buffer,传递给Decoder时用共享内存可以减少Buffer的拷贝,共享内存可以在ACodec这一层分配,可以由OMX组件分配;
- 对于需要加密的Secure Input Buffer,Buffer由OMX组件分配并且将Buffer Handle回传给ACodec使用,本质上是一块共享内存,只不过是加密的物理内存;
- 如果需要渲染到Surface上,那么可以直接将解码后的数据直接存储到graphic buffer上,graphic buffer也是一块物理共享内存,ACodec与OMX组件之间的Buffer传递需要通过Fence和Handle来完成。
input/output buffer有多种类型,分配方式和传递方式也是各不相同,所以看代码只看流程是很难理解实现原理的,我们要知道Buffer是从哪儿分配的,从哪里来又到哪里去,不同状态下是如何控制的。
最后,也是非常重要的一点,我们还需要对音视频的基础知识有所了解。
目前就想到这么多,后续如果有想到其他内容会继续补充。