Android Opencore OpenMAX学习
1 OMX core methods
1)OMX_Init
2)OMX_Deinit
3)OMX_GetHandle
4)OMX_FreeHandle
5)OMX_ComponentNameEnum
6)OMX_GetComponentsOfRole
7)OMX_GetRolesOfComponent
8)OMX_SetupTunnel
9)OMX_GetContentPipe
2 The configuration parser API
除了以上methods，强烈推荐OMX核心插件库包含此API2.1函数原型
OMX_BOOL OMXConfigParser ( OMX_PTR aInputParameters,OMX_PTR aOutputParameters);
2.2 传递参数
aInputParameters 指向如下结构typedef struct
{
OMX_U8* inPtr; //codec 配置头部指针
OMX_U32 inBytes; //codec 配置头部长度
OMX_STRING cComponentRole; //OMX codec类型 eg "video_decoder.mpeg4"
OMX_STRING cComponentName; //OMX 组件名称
} OMXConfigParserInputs;
2.3 返回值
OMX_FALSE : 处理codec配置头部错误或不支持该格式OMX_TURE : 正确处理codec配置头部
2.4 函数作用
填充aOutputParameters，有两种选择：audio coded or vedio codec for audio
typedef struct
{
OMX_U16 Channels; //通道：单声道、立体声、5.1
OMX_U16 BitsPerSample; //位宽（eg16）
OMX_U32 SamplesPerSec; //采样率
} AudioOMXConfigParserOutputs;
typedef struct
{
OMX_U32 width; //检测到的视频剪辑宽度
OMX_U32 height; //检测到的视频剪辑高度
OMX_U32 profile; //参数
OMX_U32 level; //级别？
} VideoOMXConfigParserOutputs;
3 动态加载OMX内核
解释了\system\system\etc\pvplayer.cfg文件中最后一行的含义(0xa054369c,0x22c5,0x412e,0x19,0x17,0x87,0x4c,0x1a,0x19,0xd4,0x5f),"libomx_sharedlibrary.so"
作用：将OMX内核动态加载进OpenCORE框架
位置：\system\system\etc\pvplayer.cfg
形式：(OMX Core API OsclUuid), “shared library name.so”
eg：(0xa054369c,0x22c5,0x412e,0x19,0x17,0x87,0x4c,0x1a,0x19,0xd4,0x5f),"libomx_core_vendorXYZ.so"
注意：(0xa054369c,0x22c5,0x412e,0x19,0x17,0x87,0x4c,0x1a,0x19,0xd4,0x5f) 提供独立API ID，不可修改
4 数据格式及OMX输入缓冲细节
4.1 帧起始代码
一般不用，H.264可能使用。
4.2 OMX缓冲区
三个值得信赖的关键参数nFilledLen 缓冲区长度
nTimestamp 缓冲区时间戳
OMX_BUFFERLAG_ENDOFFRAME 缓冲区结束标志位
4.3多帧合并输入缓冲
一些音频信息，单帧过小（eg ARM），将其合并作为一个缓冲区处理。nFilledLen为所有帧总长度，nTimestamp指向缓冲区第一帧时间。
4.4部分帧
视频解码单帧过大情况下，可能将单帧拆分后传递给缓冲区。部分帧情况下，只有最后一帧的缓冲区才拥有OMX_BUFFERLAG_ENDOFFRAME。
部分帧缓冲区不会包含两帧信息。
流媒体可能包含多帧。
部分帧的nTimestamp应当相同。
总结：OMX输出缓冲区可能包含
——完整多帧
——完整单帧
——部分帧
4.5 错误的数据封装
多帧的部分帧封装 eg wrong（Frame1+Frame2 part）
4.6 Codec配置数据
Codec配置缓冲区使用OMX_BUFFERLAG_ENDOFFRAME 和OMX_BUFFERFLAG_CODECCONFIG标志位。H.264的SPS和PPS使用独立的OMX输入缓冲区。
5 H264/AVC 解码器格式
Codec配置头部：SPS和PPS NAL单元位于起始的OMX输入缓冲区。
SPS和PPS NALs使用独立的OMX输入缓冲区，并使用OMX_BUFFERLAG_ENDOFFRAME 和OMX_BUFFERFLAG_CODECCONFIG标记。
5.1 AVC NAL模式与AVC Frame模式
通过设置iOMXComponentUsesFullAVCFrame标志位，可以决定AVC数据使用哪种模式解码。默认使用NAL模式，此种模式下OpenCORE框架同时提供完整单帧和部分帧输入缓冲区。
在Frame模式下，OpenCORE框架积累NALs并提供完整单帧给输入缓冲区。
OMX_OTHER_EXTRADATA结构体用来区分NAL边界。
如果iOMXComponentUsesFullAVCFrame和iOMXComponentUsesNALStratCodes都被置为OMX_TRUE，
NAL边界可被start codes区分，此时OMX_OTHER_EXTRADATA无用。
数据结构——NAL模式：
输入缓冲区包含一个或多个NAL，但只包含同一帧的NAL，一帧最后一个NAL才含有OMX_BUFFERLAG_ENDOFFRAME标志位。
数据结构——Frame模式：
每个输入缓冲区包含完整帧。
如果使用NAL start codes，可通过读取NAL start codes区分NAL边界。
否则使用OMX_OTHER_EXTRADATA结构体区分NAL边界。
在Frame模式中，每个缓冲区都含有OMX_BUFFERLAG_ENDOFFRAME标志位。
在Frame模式中，每个缓冲区都含有位于OMX_BUFFERLAGHEADERTYPE结构体nFlags区域的OMX_BUFFERLAG_EXTRADATA标志位。
缓冲区最后包含AVC frame，追加以下数据：
OMX_OTHER_EXTRADATATYPE extra;
OMX_OTHER_EXTRADATATYPE terminator;
extra.eType = OMX_ExtraDataNALSizeArray;
extra.nSize = 20+4*(number of NALs in the frame); // 20 is the size of
OMX_OTHER_EXTRADATATYPE structure + 4 bytes per NAL size
extra.nDataSize = 4 * (number of NALs in the frame)
extra.data[4*i] = size of the i-th NAL (data is declared as byte array – so offset is 4*i, since 4 bytes
is assigned to signal the size of each NAL unit)
terminator.eType = OMX_ExtraDataNone;
terminator.nSize = 20;
terminator.nDataSize = 0;
#define OMX_ExtraDataNALSizeArray 0x7F123321
通过获取OMX_OTHER_EXTRADATA结构体信息，可以得知每一帧包含NAL单元的数目并确定NAL边界。
一个例子：AVC Frame模式，包含2个NAL，包含extra数据结构
总结：
1）每个缓冲区都含有位于OMX_BUFFERLAGHEADERTYPE结构体nFlags区域的OMX_BUFFERLAG_EXTRADATA标志位
2）每个NAL的长度应当使用独立的4byte无符号整型数表示（eg OMX_U32）
3）所有NAL的长度被编码成OMX_U32的数组存放在buffer最后。
4）包含完整帧的缓冲区必须含有位于OMX_BUFFERLAGHEADERTYPE结构体nFlags区域的OMX_BUFFERLAG_ENDOFFRAME标志位。
5）一个独立的缓冲区不包含多帧数据。
6 YUV和RGB数据格式
OMX编码组件中，提供YUV或者RGB格式，OpenCORE框架将提供一帧完成的YUR或RGB数据给OMX组件。