Android 13 - Media框架（8）- MediaExtractor（2）
上一篇 MediaExtractor 笔记中我们学习了 extractor 以及 source 调用的层次结构，这一节我们会看一看部分的实现细节。
1、getFormat
getFormat 是 IMediaSource 的一个方法，调用它可以获得指定 track 的格式信息。格式信息在 extractor 中被称为 MetaData，里面存储有编码格式，视频的宽高，时长，音频的通道数，采样率等等信息，有的存储有解码所需要的 csd 信息。
在高版本的 Android 中，格式信息在 extractor 中一般以 AMediaFormat 的形式存储（例如 mp4 extractor），AMediaFormat 内部实际就是一个 AMessage，信息以 key-value 的形式存储，key 是字符串；有的会以 MetaData 的形式存储（例如 mpeg2 ts extractor），MetaData 也是以 key-value 的形式存储信息，但是它的 key 是int类型，存储的信息会更多一点：
bool MetaDataBase::setData(uint32_t key, uint32_t type, const void *data, size_t size);
可以看到出了 key-value 外还多了 type 和 size 信息。
之所以要这么设计是因为 format 需要通过 binder 跨进程传递给 mediaserver，传递的时候我们需要知道被传递内容的大小信息，而 type 大概是用做特殊的标记。
status_t MediaTrackCUnwrapper::getFormat(MetaDataBase& format) {
sp<AMessage> msg = new AMessage();
AMediaFormat *tmpFormat = AMediaFormat_fromMsg(&msg);
media_status_t ret = wrapper->getFormat(wrapper->data, tmpFormat);
sp<MetaData> newMeta = new MetaData();
convertMessageToMetaData(msg, newMeta);
delete tmpFormat;
format = *newMeta;
return reverse_translate_error(ret);
}
从以上代码片我们可以知道，内部的 getFormat 方法传出参数为 AMediaFormat，也就是说无论内部 format 以何种形式存储，最终会转换为 AMediaFormat，以 MPEG2TSSource 为例，MetaData 会先被转换为 AMessage，再转换为 AMediaFormat 回传：
media_status_t MPEG2TSSource::getFormat(AMediaFormat *meta) {
sp<MetaData> implMeta = mImpl->getFormat();
sp<AMessage> msg;
convertMetaDataToMessage(implMeta, &msg);
copyAMessageToAMediaFormat(meta, msg);
return AMEDIA_OK;
}
跨进程传递时 AMediaFormat 又要被转换为 MetaData，因为 MetaData 中有 writeToParcel 和 createFromParcel( 方法，很方便就完成 Parcel 的封装和解封装。
其实 AMessage 也有 writeToParcel 和 FromParcel，可以很轻松的让 AMessage 在进程间传递，但是这两个方法不能用于 vendor 和 apex。
上面说可以将 MetaData 和 AMessage 相互转换，但是由于它们的 key 的类型并不一样，所以一定有对照关系，这里我们要看 Utils.cpp 这边的几个 pair，pair 中没有的对照关系在 convertMessageToMetaData 和 convertMetaDataToMessage 中会指定转换关系。
如果我们需要自定义一些 Format 信息，那么必须要在 convertMessageToMetaData 和 convertMetaDataToMessage 实现转换关系，否则 extractor parse 出的信息将无法通过 binder 传递，mediaserver 端也无法解析到自定义的 format。
MetaData 所用的 key 位于 MetaDataBase.h，以 enum 的形式提供，如何使用可以参考 Utils.cpp 。
AMediaFormat 使用的 key 位于 NdkMediaFormat.cpp ，以字符串的形式提供，AMediaFormat 如何使用同样参考 Utils.cpp 。
2、MediaExtractor 与 MediaTrack（MediaSource） 设计结构
看代码我们可以发现基础实现 MediaExtractor 和 MediaTrack 分别继承于 MediaExtractorPluginHelper 和 MediaTrackHelper，这两个基类的声明位于 MediaExtractorPluginHelper.h，除了这两个类外，还有非常重要的 MediaBufferHelper、MediaBufferGroupHelper、DataSourceHelper。
往上一层，与之相对应的 C 风格的 api 声明位于 MediaExtractorPluginApi.h，创建了 MediaExtractorPluginHelper 和 MediaTrackHelper 对象后，会将其封装到 CMediaExtractor 和 CMediaTrack 供上层使用。wrap 方法在 MediaExtractorPluginHelper.h 中有提供，对 Helper 提供的 api 进行了封装。
再往上就到了 MediaExtractor 和 MediaTrack，它们两个是基类提供了对外接口，对应的实现是 MediaExtractorCUnwrapper 和 MediaTrackCUnwrapper 。它们内部封装了对 CMediaExtractor 和 CMediaTrack 的调用以及对返回结果的处理。
最外层是binder封装，这里就不细看了。
看到这里我们大致就可以了解，binder 调用的是 MediaExtractor 和 MediaTrack 提供的标准接口，它们对内部依赖进行了抽象，使其依赖于 CMediaExtractor 和 CMediaTrack，而不是依赖于具体的实现，具体实现封装在CMediaExtractor 和 CMediaTrack中。我觉得这里CMediaExtractor -> MediaExtractorPluginHelper 所用到的设计模式应该算是外观模式。
我并不是很理解为什么要设计中间层 CMediaExtractor 和 CMediaTrack，拿掉它们同样可以实现抽象与多态，如果有大神理解可以指点我一下。