Android底层音视频播放媒体提取器【MediaExtractor】的解复用模块demuxers模块化加载和注册流程实现源码分析【Part 2】

最新推荐文章于 2024-07-01 17:32:30 发布
最新推荐文章于 2024-07-01 17:32:30 发布
阅读量1.5k 收藏 1
点赞数 2
分类专栏： MediaPlayer 【音视频】 文章标签： mm-parser MediaExtractor 解复用模块demuxers注册 媒体提取器加载 ExtractorPlugin
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u012430727/article/details/115514676
版权
本文详细分析了Android10.0版本中MediaExtractor的解复用模块加载和注册流程，特别是高通模块libmmparserextractor的实现。内容包括GetExtractorDef方法指针的查找，Sniff方法的实现，以及GetExtensions方法的执行过程，揭示了Android系统如何识别和处理不同音视频文件格式。
摘要由CSDN通过智能技术生成

承接上一章节分析：Android底层音视频播放媒体提取器【MediaExtractor】的解复用模块demuxers模块化加载和注册流程实现源码分析【Part 1】
本系列文章分析的安卓源码版本：【Android 10.0 版本】

关于每个so库提取器具体如何实现GetExtractorDef方法指针，这里只列举一下高通该功能的实现，其他so库实现方式都是类似的。
首先我们可以找到高通模块so库名称【libmmparserextractor】的声明mk文件：
动态库创建的mk文件声明。【省略部分代码】

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/Android.mk]
BUILD_PARSER :=

include $(CLEAR_VARS)

LOCAL_C_FLAGS := -D_ANDROID_

LOCAL_SRC_FILES:=                 \
    src/MMParserExtractor.cpp     \
    src/QComExtractorFactory.cpp  \
    src/SourcePort.cpp            \

LOCAL_C_INCLUDES:=                                    \
    $(LOCAL_PATH)/inc                                 \
    $(LOCAL_PATH)/../../common/inc                    \
    $(LOCAL_PATH)/../../../common/inc                 \
    $(TARGET_OUT_HEADERS)/mm-core/omxcore

LOCAL_HEADER_LIBRARIES :=       \
    libmmosal_headers           \
    libmmparser_headers         \
    libstagefright_headers

LOCAL_SHARED_LIBRARIES +=       \
    libcutils                   \
    liblog                      \
    libmediandk                 \
    libmmparser_lite            \
    libstagefright              \
    libstagefright_foundation   \
    libutils

LOCAL_SANITIZE := cfi signed-integer-overflow unsigned-integer-overflow

LOCAL_MODULE:= libmmparserextractor

LOCAL_MODULE_RELATIVE_PATH := extractors

LOCAL_MODULE_TAGS := optional

include $(BUILD_SHARED_LIBRARY)
endif

因此可以知道该mk包含的实现文件就是该so库的实现。
然后找到实现了GetExtractorDef方法指针的实现方法。
注意：[QComExtractorFactory.cpp]该文件内的实现都是在android命名空间中，头文件[frameworks/av/include/media/MediaExtractorPluginApi.h]也在它的实现也是在android命名空间中，因此实现端必须引用该头文件。
再注意此处是要求C++编译器通过C编译器编译方式来编译这段代码，也就是说方法名【GETEXTRACTORDEF】在编译后的库中将不会被修改（注：C++编译方式就会改变该值），因此也就能像上面的分析一样可以通过dlsym来查询指定名【GETEXTRACTORDEF】的该方法指针（即方法地址）。

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]
extern "C" {

// This is the only symbol that needs to be exported
__attribute__ ((visibility ("default")))
ExtractorDef GETEXTRACTORDEF() {
    return {
        EXTRACTORDEF_VERSION,
        UUID("2cb1d938-46d8-436d-b73e-681c47392cc8"),
        2, // version
        "QCOM Extractor",
        // 并实现了这两个方法
        // Sniff方法指针实现，见2.1小节分析
        // GetExtensions() 方法实现，见2.2小节分析
        { .v3 = {Sniff, GetExtensions()} }
    };
}

} // extern "C"

2.1、Sniff() 方法实现：

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]
static CreatorFunc Sniff(CDataSource *source, float *confidence,
                                         void **, FreeMetaFunc *) {
    // 该类其实是一个CDataSource类的代理实现类，主要就是读取数据源的数据（注意非解复用，仅仅只是读取数据），
    // CDataSource类对象由上层调用端实现和传入。
    // 其定义在[/frameworks/av/include/media/MediaExtractorPluginHelper.h]头文件中
    DataSourceHelper helper(source);
    // 分配一个指向128KB大小的指针，MAX_FORMAT_HEADER_SIZE 宏定义大小为128KB
    uint8_t* sniffBuffer = (uint8_t*)malloc(sizeof(uint8_t) * MAX_FORMAT_HEADER_SIZE);
    if (!sniffBuffer)
    {
        LOGE("malloc for sniff buffer failed");
        return NULL;
    }

    bool sniffSuccess = false;
    bool isEOS = false;
    int  parser_flags = 0;
    char property_value[PROPERTY_VALUE_MAX] = {0};
    // 文件数据源读取状态
    FileSourceStatus status = FILE_SOURCE_INVALID;
    ssize_t sniffBufferSize = 0;
    uint32_t requiredSize = 0;
    // GetID3Size() 方法是处理获取ID3数据的偏移量即跳过ID3类型的数据
    // 见2.1.1小节分析
    uint64_t offset = GetID3Size(&helper);

    // 此处代码处理为：从该系统属性值中获取文件解析器设置的标志位。其实就是对应于文件解析器格式类型值，
	// 若无设置则默认为0，其实就是将不会使用高通该模块功能。
	// 备注：默认在编译期间以及定义了该值的，一般情况下是启用所有支持的文件解析器格式类型值。
    property_get("vendor.mm.enable.qcom_parser", property_value, "0");
    parser_flags = atoi(property_value);
    LOGV("Parser_Flags == %x",parser_flags);
    
    // SNIFF_ARRAY_SIZE 一个宏定义，其值为支持的解复用文件格式数组大小，其为固定值
    // #define SNIFF_ARRAY_SIZE (sizeof(sniffArray)/sizeof(SniffInfo))
    // 关于 sniffArray 和 SniffInfo 的声明和定义，见2.1.2小节分析
    int index = 0;
    for (index = 0; index < SNIFF_ARRAY_SIZE; ++index) {
        const SniffInfo *sniff = &sniffArray[index];
    	// 与运算符作用为：检查启用了哪些支持的文件解析器格式类型值。即允许解析使用支持解析的哪些文件格式类型
    	// sniffArray：文件解析器格式支持列表数据，见上面的分析
        if (!(sniff->flag & parser_flags))
          continue;

        LOGV("Sniff %s ==>", sniff->type);
        // 此处的文件类型处理
        switch (sniff->format)
        {
            case FILE_SOURCE_AAC:
            case FILE_SOURCE_MP3:
            case FILE_SOURCE_FLAC:
            case FILE_SOURCE_APE:
            case FILE_SOURCE_DTS:
            case FILE_SOURCE_MHAS:
              // 这几种文件格式时，设置要求读取数据大小为最大值128KB
              requiredSize = MAX_FORMAT_HEADER_SIZE;
              break;
            default:
              // 否则，其他文件格式时默认设置要求读取数据大小为最小值1KB
              requiredSize = MIN_FORMAT_HEADER_SIZE;
              break;
        }

        //Check for file format and give validation a chance to request more data
        //if required buffer is not enough to sniff successfully. Maximum data that
        //can be requested is limited to max possible sniff buffer size.
        // 记录已读取数据字节数
        ssize_t dataRead = sniffBufferSize;
        do {
            //No need to read again until more data required
            if (!isEOS && requiredSize > dataRead) {
            	// 文件未到末尾并且还需要读取数据时
				
                // offset + dataRead：从offset数据偏移量即开始读取位置，
                // 加上已读取数据大小dataRead，即成为新的开始读取数据位置。
                // sniffBuffer + dataRead：计算本次需要存储读取到的数据的存储位置。
                // requiredSize - dataRead：计算还剩余需要读取的数据大小（字节）。
                ssize_t readBytes = helper.readAt(offset + dataRead,
                                                  sniffBuffer + dataRead,
                                                  requiredSize - dataRead);
                // 返回值表示本次实际读取数据的大小，未读到数据则退出
                if (readBytes <= 0)
                    break;
                // 计算文件是否到末尾，也就是要求读取的数据大小，未读取到这么多数据
                // 【理论上数据足够的话，一次性就能读取完成，即此处相等】
                isEOS = ((requiredSize - dataRead) != readBytes);
                // 计算总读取数据大小
                dataRead += readBytes;
                ALOGV("Data read for sniffing at offset %llu required %u read %zu",
                      (unsigned long long)offset, requiredSize, dataRead);
            }

            // 检查最小要求读取数据是否满足
            //Check min sniff data is available
            if (dataRead < MIN_FORMAT_HEADER_SIZE) {
                LOGE("Sniff FAIL :: coundn't pull enough data for sniffing");
                // 数据不足时，将数组访问下标置为数组大小，即在下面的处理时，将会返回一个空结果给上层。
                index = SNIFF_ARRAY_SIZE;
                break;
            }

            // 将已读取数据字节数赋值给指定要求读取大小变量（修正）
            requiredSize = dataRead;
            // 检查文件格式，其实该方法是高通私有库【libmmparser_lite.so】实现的功能，因此目前分析不了，
            // 不过从其头文件的API英文注释可知，该方法就是将输入的sniffBuffer即携带文件格式数据进行文件格式是否支持检查，
            // 说是主要为了不不需要创建FileSource对象就能快速检查文件格式是否支持解复用。
            status = FileSource::CheckFileFormat(sniff->format, sniffBuffer, &requiredSize);
            LOGV("CheckFileFormat status = %d", status);
            // 若未完成读取数据，则继续
        }while (!isEOS && status == FILE_SOURCE_DATA_NOTAVAILABLE &&
                requiredSize <= MAX_FORMAT_HEADER_SIZE &&
                requiredSize > dataRead);

		// 记录已读取数据字节数
        sniffBufferSize = dataRead;
        if (status == FILE_SOURCE_SUCCESS) {
        	// 文件格式校验成功，则标记为true，并打分0.8百分比，最高1
            LOGV(" Sniff %s success <==", sniff->type);
            sniffSuccess = true;
            *confidence = 0.8;
            break;
        }
    }
    // 释放内存
    free(sniffBuffer);
    // 最后若成功，则返回该index对应的支持目标文件的SniffInfo配置信息对象的CreatorFunc方法指针
    return sniffSuccess ? sniffArray[index].creator : NULL;
}

2.1.1、GetID3Size(&helper)实现分析：
处理获取ID3数据的偏移量即跳过ID3类型的数据。
ID3定义：一种metadata容器，一般是位于一个mp3文件的开头或末尾的若干字节内，附加了关于该mp3的歌手，标题，专辑名称，年代，风格等信息，该信息就被称为ID3信息，ID3信息分为两个版本，v1和v2版。 其中：v1版的ID3在mp3文件的末尾128字节，以TAG三个字符开头，后面跟上歌曲信息。 v2版一般位于mp3的开头，可以存储歌词，该专辑的图片等大容量的信息。

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]

#define ID3V2_HEADER_SIZE 10
/*! =========================================================================
 * @brief       Get ID3 tag size. This routine is used to skip ID3 tag data
 *              while sniffing.
 *
 * @param
 *   source[in] : Data source to read from.
 *
 * @return        ID3 tag size.
 * =========================================================================*/
uint64_t GetID3Size(DataSourceHelper *source)
{
    uint64_t offset = 0;
    // 循环检查文件开头是否有ID3 TAG标记消息存在
    // 注意：此处采取循环处理的原因是，ID3信息会有多个信息，因此需要循环读取全部出来并跳过
    //Check if file has ID3Tag present before AAC/MP3/FLAC/APE file header.
    for(;;) {
    	// 此处其实只处理ID3第二个版本的头信息，默认读取10个字节数据(头大小)
        uint8_t pProcessBuff[ID3V2_HEADER_SIZE];

        // 读取至少10个字节数据，调用了readAt方法
        // 其方法返回值表示读取到的数据大小，若小于10个字节则直接退出，表示该文件没数据了
        //read atleast 10 bytes of data
        if(source->readAt(offset,pProcessBuff,sizeof(pProcessBuff))
           < (ssize_t)sizeof(pProcessBuff)) {
            break;
        }

        // 比较两个字符串内存字节的前三个字符的（三）字节大小，返回0表示相同，返回不相同时退出
        //Stop if there are no more ID3 tags
        if(memcmp("ID3",pProcessBuff,strlen("ID3")))
            break;

        // 计算ID3类型数据大小并跳过它
        //Calculate size and skip ID3 tag
        // 跳过六个字节大小数据即 ID3 （三字符大小） + Ver （版本号两字节大小） + Flag （标记一字节大小） 
        //skip 6 byte = ID3(3byte)+ Ver(2byte)+ Flag (1byte)
        // 从文件数据开头的第6个字节之后的数据开始计算ID3 tag 大小，计算到第10个字节处
        // 注意：该size数据类型是64位bit长度的无符号类型
        uint64_t ulID3TagSize = 0;
        for(int i = 6; i < ID3V2_HEADER_SIZE; i++) {
        	// (ulID3TagSize << 7) 表示 size的值做左移运算符计算 
        	// 即size值的bit数位全部左移7个位，也就是将最高位的7个bit值移除。
        	// (pProcessBuff[i] & 0x7F) 表示 将 pProcessBuff 字节数组中的第7到10的字节数值和 0x7F【0111 1111】进行与运算符计算，
        	// 也就说将 pProcessBuff[i] 第i个字节数据的bit最高位去掉（置为0）。
        	// 最后将这两个计算得到的值继续 | 或运算符，其实际效果和作用根据这两个计算处理流程中分析的可知，
        	// 最终作用就是将 pProcessBuff[i] 后面四个字节的右7位有效bit值加最高位0，按顺序排列成一个64位int变量的右32位来表示的值。
            ulID3TagSize = (ulID3TagSize << 7) | (pProcessBuff[i] & 0x7F);
        }
        // 可能此时你还看不出来到底这么处理后得到的值表示啥，其实就是表示当前ID3 tag后面携带的信息长度值，
        // 因此如此计算后面4个字节有效bit位，得到的size值就表示该长度值

		// 因此此处就在加上ID3头部信息大小（10字节），得到的总值就是当前ID3 tag及其携带信息的总长度字节数
        ulID3TagSize += ID3V2_HEADER_SIZE;

		// 然后再次相加此前已计算的ID3 tag信息长度，就得到所有ID3 tag及其携带信息的总长度字节数
		// 而该值就是需要跳过的值，跳过该值后就是文件头即文件类型信息了。
        offset += ulID3TagSize;
    }
    return offset;
}

2.1.2、sniffArray：文件解析器格式支持列表数据
其实为一个全局固定数据大小的数组。
以下文件均在【QComExtractorFactory.cpp】文件中实现

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]

#define CREATOR(_x_) [](CDataSource *source, void *) -> CMediaExtractor* { \
  return wrap(new MMParserExtractor(new DataSourceHelper(source), _x_)); \
}

#define SNIFF_ENTRY(_flag_, _type_, _format_) {_flag_, _type_, _format_, CREATOR(_format_)}

typedef struct
{
    int flag;
    const char* type;
    // 这是个枚举类型，即高通该解复用模块支持的所有数据源文件格式类型，
    // 但是注意该枚举里面的类型并非所有的都支持了，只是将其所有的列出来而已。
    // 想要知道具体哪些文件格式类型支持情况，可以查看2.2小节中的分析
    FileSourceFileFormat format;
    CreatorFunc creator;
} SniffInfo;

static const SniffInfo sniffArray[] = {
  SNIFF_ENTRY(PARSER_OGG,    "OGG",    FILE_SOURCE_OGG),
  SNIFF_ENTRY(PARSER_AVI,    "AVI",    FILE_SOURCE_AVI),
  SNIFF_ENTRY(PARSER_WAV,    "WAV",    FILE_SOURCE_WAV),
  SNIFF_ENTRY(PARSER_DSF,    "DSF",    FILE_SOURCE_DSF),
  SNIFF_ENTRY(PARSER_DSDIFF, "DSDIFF", FILE_SOURCE_DSDIFF),
  SNIFF_ENTRY(PARSER_AC3,    "AC3",    FILE_SOURCE_AC3),
  SNIFF_ENTRY(PARSER_ASF,    "ASF",    FILE_SOURCE_ASF),
  SNIFF_ENTRY(PARSER_AMR_NB, "AMRNB",  FILE_SOURCE_AMR_NB),
  SNIFF_ENTRY(PARSER_AMR_WB, "AMRWB",  FILE_SOURCE_AMR_WB),
  SNIFF_ENTRY(PARSER_MKV,    "MKV",    FILE_SOURCE_MKV),
  SNIFF_ENTRY(PARSER_MOV,    "MOV",    FILE_SOURCE_MOV),
  SNIFF_ENTRY(PARSER_3GP,    "3GP",    FILE_SOURCE_MPEG4),
  SNIFF_ENTRY(PARSER_QCP,    "QCP",    FILE_SOURCE_QCP),
  SNIFF_ENTRY(PARSER_FLAC,   "FLAC",   FILE_SOURCE_FLAC),
  SNIFF_ENTRY(PARSER_FLV,    "FLV",    FILE_SOURCE_FLV),
  SNIFF_ENTRY(PARSER_MP2TS,  "MP2TS",  FILE_SOURCE_MP2TS),
  SNIFF_ENTRY(PARSER_3G2,    "3G2",    FILE_SOURCE_3G2),
  SNIFF_ENTRY(PARSER_MP2PS,  "MP2PS",  FILE_SOURCE_MP2PS),
  SNIFF_ENTRY(PARSER_AIFF,   "AIFF",   FILE_SOURCE_AIFF),
  SNIFF_ENTRY(PARSER_APE,    "APE",    FILE_SOURCE_APE),
  SNIFF_ENTRY(PARSER_AAC,    "AAC",    FILE_SOURCE_AAC),
  SNIFF_ENTRY(PARSER_MP3,    "MP3",    FILE_SOURCE_MP3),
  SNIFF_ENTRY(PARSER_DTS,    "DTS",    FILE_SOURCE_DTS),
  SNIFF_ENTRY(PARSER_MHAS,   "MHAS",   FILE_SOURCE_MHAS)
};

通过上面的分析可以知道，sniffArray该数组将会定义所有当前高通解复用模块支持的文件格式数据信息SniffInfo，并通过宏定义方法【CREATOR】赋值来创建具体的真正的解复用模块媒体提取器实现对象指针【CMediaExtractor*】，并且通过一个wrap方法来对【MMParserExtractor】对象进行转换，其实就是相当于对数据对象功能的封装，即代理设计模式，上层使用CMediaExtractor对象来代理操作真正的实现者【MMParserExtractor】对象功能。
具体是怎么实现的，可以简单如下分析：
先看类声明：【省略其他代码】

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/inc/MMParserExtractor.h]
class MMParserExtractor : public MediaExtractorPluginHelper {}

// [frameworks/av/include/media/MediaExtractorPluginHelper.h]
// extractor plugins can derive from this class which looks remarkably
// like MediaExtractor and can be easily wrapped in the required C API
class MediaExtractorPluginHelper {}

wrap()方法肯定不会凭空出现，因此QComExtractorFactory.cpp该文件中没有定义，那么肯定是在头文件中声明定义的，
其只引用了一个头文件：

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]

#include "MMParserExtractor.h"

因此再看该头文件中引用的头文件：

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/inc/MMParserExtractor.h]

#define MMPARSER_EXTRACTOR_H_
#include <utils/threads.h>
#include <cutils/properties.h>
#include <media/MediaExtractorPluginHelper.h>
#include <media/NdkMediaFormat.h>
#include "SourcePort.h"
#include "filesource.h"
#include "filesourcetypes.h"
#include "common_log.h"

其实可以大致猜到该方法肯定跟前面内容相关，因此在MediaExtractorPluginHelper.h文件中可以看到该wrap()方法的声明定义：
因此方法的实现就完成了代理类功能的实现，即代理设计模式

// [frameworks/av/include/media/MediaExtractorPluginHelper.h]

inline CMediaExtractor *wrap(MediaExtractorPluginHelper *extractor) {
	// 创建一个【CMediaExtractor】代理类
    CMediaExtractor *wrapper = (CMediaExtractor*) malloc(sizeof(CMediaExtractor));
    wrapper->data = extractor;
    wrapper->free = [](void *data) -> void {
        delete (MediaExtractorPluginHelper*)(data);
    };
    wrapper->countTracks = [](void *data) -> size_t {
        return ((MediaExtractorPluginHelper*)data)->countTracks();
    };
    wrapper->getTrack = [](void *data, size_t index) -> CMediaTrack* {
    	// 注意：此处也是使用了代理设计模式，将底层的Track对象封装【转换】为上层的Track对象，以供上层控制下层实现
    	// 见下面的分析
        return wrap(((MediaExtractorPluginHelper*)data)->getTrack(index));
    };
    wrapper->getTrackMetaData = [](
            void *data,
            AMediaFormat *meta,
            size_t index, uint32_t flags) -> media_status_t {
        return ((MediaExtractorPluginHelper*)data)->getTrackMetaData(meta, index, flags);
    };
    wrapper->getMetaData = [](
            void *data,
            AMediaFormat *meta) -> media_status_t {
        return ((MediaExtractorPluginHelper*)data)->getMetaData(meta);
    };
    wrapper->flags = [](
            void *data) -> uint32_t {
        return ((MediaExtractorPluginHelper*)data)->flags();
    };
    wrapper->setMediaCas = [](
            void *data, const uint8_t *casToken, size_t size) -> media_status_t {
        return ((MediaExtractorPluginHelper*)data)->setMediaCas(casToken, size);
    };
    wrapper->name = [](
            void *data) -> const char * {
        return ((MediaExtractorPluginHelper*)data)->name();
    };
    return wrapper;
}

wrap(((MediaExtractorPluginHelper*)data)->getTrack(index))实现分析：
也是使用了代理设计模式，将底层的Track对象封装【转换】为上层的Track对象，以供上层控制下层实现。
首先看下MediaExtractorPluginHelper的getTrack() 方法返回类型：

// [frameworks/av/include/media/MediaExtractorPluginHelper.h]

    virtual MediaTrackHelper *getTrack(size_t index) = 0;

wrap()实现：

// [frameworks/av/include/media/MediaExtractorPluginHelper.h]

inline CMediaTrack *wrap(MediaTrackHelper *track) {
    if (track == nullptr) {
        return nullptr;
    }
    // 创建Track代理类
    CMediaTrack *wrapper = (CMediaTrack*) malloc(sizeof(CMediaTrack));
    wrapper->data = track;
    wrapper->free = [](void *data) -> void {
        delete (MediaTrackHelper*)(data);
    };
    // 开始Track，代理实现
    wrapper->start = [](void *data, CMediaBufferGroup *bufferGroup) -> media_status_t {
        if (((MediaTrackHelper*)data)->mBufferGroup) {
            // this shouldn't happen, but handle it anyway
            delete ((MediaTrackHelper*)data)->mBufferGroup;
        }
        // 每次开始track时都会新分配缓冲区封装对象给到下层使用，
        // 也就是说媒体解复用缓冲区内存是由上层调用端来统一分配的。
        ((MediaTrackHelper*)data)->mBufferGroup = new MediaBufferGroupHelper(bufferGroup);
        return ((MediaTrackHelper*)data)->start();
    };
    // 停止track
    wrapper->stop = [](void *data) -> media_status_t {
        return ((MediaTrackHelper*)data)->stop();
    };
    // 获取track到的媒体信息
    wrapper->getFormat = [](void *data, AMediaFormat *meta) -> media_status_t {
        return ((MediaTrackHelper*)data)->getFormat(meta);
    };
    // track解复用读取解析的数据，传入读取操作的参数
    wrapper->read = [](void *data, CMediaBuffer **buffer,  uint32_t options, int64_t seekPosUs)
            -> media_status_t {
        MediaTrackHelper::ReadOptions opts(options, seekPosUs);
        MediaBufferHelper *buf = NULL;
        // 调用底层Track实现的read()方法来真正解复用获取音视频数据
        media_status_t ret = ((MediaTrackHelper*)data)->read(&buf, &opts);
        if (ret == AMEDIA_OK && buf != nullptr) {
        	// 成功则获取该buffer数据
            *buffer = buf->mBuffer;
        }
        return ret;
    };
    // 是否支持非阻塞读取
    wrapper->supportsNonBlockingRead = [](void *data) -> bool {
                return ((MediaTrackHelper*)data)->supportsNonBlockingRead();
    };
    return wrapper;
}

2.2、GetExtensions()实现分析：
获取该媒体提取器so库支持的文件扩展类型，返回类型为char ** 其实也就是字符串数组，即返回的是支持解复用的文件格式类型名称数组。

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]
static const char** GetExtensions() {
	// 此处代码处理为：从该系统属性值中获取文件解析器设置的标志位。其实就是对应于文件解析器格式类型值，
	// 若无设置则默认为0，其实就是将不会使用高通该模块功能。
	// 备注：默认在编译期间以及定义了该值的，一般情况下是启用所有支持的文件解析器格式类型值。
    int  parser_flags = 0;
    char property_value[PROPERTY_VALUE_MAX] = {0};
    property_get("vendor.mm.enable.qcom_parser", property_value, "0");
    parser_flags = atoi(property_value);
    LOGV("Parser_Flags == %x",parser_flags);
    
    int index = 0;
    total_extensions = 0;
    // 关于 sniffArray 和 SniffInfo 的声明和定义，见上面的分析
    for (index = 0; index < SNIFF_ARRAY_SIZE; ++index) {
    	// 与运算符作用为：检查启用了哪些支持的文件解析器格式类型值。即允许解析使用支持解析的哪些文件格式类型
    	// sniffArray：文件解析器格式支持列表数据，见上面的分析
        switch((parser_flags & sniffArray[index].flag)) {
            case PARSER_OGG:
            	// 支持该文件格式和它的扩展文件格式，也就是说一种类型文件可能有多种文件格式来表示
            	// 见下面的分析
                addExtension("oga");
                addExtension("ogg");
                break;
            case PARSER_AVI:
                addExtension("avi");
                break;
            case PARSER_WAV:
                addExtension("wav");
                break;
            case PARSER_DSF:
                addExtension("dsf");
                break;
            case PARSER_DSDIFF:
                addExtension("dff");
                addExtension("dsd");
                break;
            case PARSER_AC3:
                addExtension("ac3");
                addExtension("ec3");
                break;
            case PARSER_ASF:
                addExtension("asf");
                addExtension("wma");
                addExtension("wmv");
                break;
            case PARSER_AMR_NB:
                addExtension("amr");
                break;
            case PARSER_AMR_WB:
                addExtension("awb");
                break;
            case PARSER_MKV:
                addExtension("mka");
                addExtension("mkv");
                addExtension("webm");
                break;
            case PARSER_MOV:
                addExtension("mov");
                break;
            case PARSER_3GP:
                addExtension("3gp");
                addExtension("3gpp");
                addExtension("3gpp2");
                addExtension("m4a");
                addExtension("m4r");
                addExtension("m4v");
                addExtension("mp4");
                addExtension("qt");
                break;
            case PARSER_QCP:
                addExtension("qcp");
                break;
            case PARSER_FLAC:
                addExtension("fl");
                addExtension("flac");
                break;
            case PARSER_FLV:
                addExtension("flv");
                break;
            case PARSER_MP2TS:
                addExtension("m2ts");
                addExtension("ts");
                break;
            case PARSER_3G2:
                addExtension("3g2");
                break;
            case PARSER_MP2PS:
                addExtension("m2p");
                addExtension("mpeg");
                addExtension("mpg");
                addExtension("mpga");
                addExtension("vob");
                break;
            case PARSER_AIFF:
                addExtension("aif");
                addExtension("aiff");
                break;
            case PARSER_APE:
                addExtension("ape");
                break;
            case PARSER_AAC:
                addExtension("aac");
                break;
            case PARSER_MP3:
                addExtension("mp3");
                break;
            case PARSER_DTS:
                addExtension("dts");
                break;
            case PARSER_MHAS:
                addExtension("mhas");
                break;
            default:
                break;
        }
    }
    // 最后加了一个NULL空数据项到数组最后项中
    addExtension(NULL);
    return extensions;
}

addExtension(“ogg”)实现分析：

// [vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]
static void addExtension(const char* extension)
{
    if (total_extensions < MAX_FILE_EXTENSIONS) {
        extensions[total_extensions++] = extension;
    }
}

extensions 数组指针全局变量定义：
[vendor/qcom/proprietary/commonsys-intf/mm-parser/Android_adaptation/src/QComExtractorFactory.cpp]文件中

static const char *extensions[MAX_FILE_EXTENSIONS];

// 最终支持50个文件格式类型
#define MAX_FILE_EXTENSIONS 50

因此从上面的 GetExtensions() 方法分析可以知道，这里定义了高通私有解复用模块支持的文件类型格式情况。

本章结束：
通过本系列章节的分析，我们可以清晰的理解和掌握，Android底层音视频播放媒体提取器【MediaExtractor】的解复用模块demuxers是如何进行模块化（集成）加载实现和注册过程的。

小白兔LHao
关注
专栏目录
Android Stagefright MPEG4Extractor分析
08-26 3785
http://www.cnblogs.com/shaobin0604/archive/2011/08/16/2141388.html   视频播放的基本流程                             video track    +-------------
android 提取方法,Android开发 多媒体提取器MediaExtractor详解_入门篇
weixin_28728495的博客
05-25 855
前言MediaExtractor字面意思是多媒体提取器,它在Android的音视频开发里主要负责提取视频或者音频中的信息和数据流(例如将视频文件,剥离出音频与视频).本章博客将讲解一些入门简单的东西.如何分别音频和视频轨道和获取视频里的一些信息.我将在其他章节里讲解其他MediaExtractor使用方法.获取轨道在一个多媒体视频里,可以包含多个数据流(一般是视频与音频各一个,但是音频可以多个)....
Android12 MultiMedia框架之MediaExtractorService
最新发布
Android-Graphics&Display
07-01 985
上节学到setDataSource()时会创建各种Source，source用来读取音视频源文件，读取到之后需要demux出音、视频、字幕数据流，然后再送去解码。那么负责进行demux功能的media extractor模块是在什么时候阶段创建的？这里暂时不考虑APP创建的情况，以前面学过的GenericSource为例，它是在prepare阶段被创建的。本节暂时不分析GenericSource创建extractor的流程，先来看看MediaExtractorService的启动过程。
android mediaextractor实例代码
05-28
android mediaextractor实例代码
Multimedia框架解析之MediaExtractor源码分析（二）
06-13 1150
Multimedia框架解析之MediaExtractor源码分析（二）
[Android GMS 认证] CTS 问题列表之 CtsSecurityTestCases
zhms的专栏
10-27 1358
run cts -m CtsSecurityTestCases -t android.security.cts.StagefrightTest#testStagefright_cve_2015_6600 --skip-preconditions  这是高通闭源部分的问题，向高通要patch。 LINUX/android/vendor/qcom/proprietary/prebuilt_HY11...
Android13 相机ITS测试与问题分析（三）
hjlgs的博客
07-31 717
介绍Android13 相机ITS分析步骤、问题分析
php利用ffmpeg提取视频中音频与视频画面的方法详解
10-19
1. **libavformat**：这个库负责处理各种音视频封装格式，它包含了demuxers（解复用器）和muxers（复用器）。demuxers用于解析不同格式的输入文件，提取音视频流，而muxers则用于将这些流封装成新的文件格式。 2. *...
Android-音视频学习系列-(四)-一键编译-32-64-位-FFmpeg-4-2-2
2401_84544434的博客
04-29 561
bin/sh#帮组选项#标准选项#–disable 代表关闭状态；–enable 代表开启状态#我们最终编译好的动态静态库位置，必须设置#开启静态库#关闭动态库#可以优化库的大小#我们不需要使用程序，不需要在Windows中执行，某.exe程序，我们只需要在代码中使用 [此命令操作的是下面三项]#使用FFmpeg命令#播放器#模块选项。
FFplay文档解读-9-解复用器
irainsa的博客
11-10 605
解复用器是FFmpeg中配置的元素，可以从特定类型的文件中读取多媒体流。配置FFmpeg构建时，默认情况下会启用所有支持的分离器。可以使用configure选项列出所有可用的列表。可以使用configure选项禁用所有解复用器，并使用选项选择性地启用单个解复用器，或使用选项禁用它。ff *工具的选项-demuxers将显示已启用的多路分离器列表。使用-formats可以查看已启用的分路器和多路复用器的组合列表。下面介绍一些当前可用的分路器。
Android 9.0 MediaPlayer播放流程分析
zjy764219923的专栏
11-28 2864
MediaPlayer流程分析
vendor-qcom-proprietary-mm-camera
02-02
vendor-qcom-proprietary-mm-camera 原生代码，包含qcom camera-hal isp接口等
2、Linuix\Android进行视频获取和推流服务器(FFMPEG4.4&Android7.0)
sxj731533730
05-29 1732
基本思想：进行手机端android的N21编码转视频流和C++端的FFMEGG视频推流（真心不会写android，东拼西凑的代码~） 一、（1）创建Android的Native基础工程--完成 （2）在基础的工程之上，创建页面imageview布局，留给视频流显示 对应的code代码 <?xml version="1.0" encoding="utf-8"?> <androidx.constraintlayout.widget.ConstraintLayout xmlns:a
Android MediaExtractor
liuning1985622的博客
05-06 527
MediaExtractor是Android系统中的媒体解封装库，它可以从视频或音频文件中提取媒体轨道的数据，例如视频、音频、字幕等，并将其分离出来，提供给应用程序进行解码、处理和播放。需要注意的是，MediaExtractor只能解封装媒体文件中的音视频等媒体轨道，而不能解析整个媒体文件的结构。如果需要解析整个媒体文件的结构，需要使用其他库或框架。MediaExtractor支持的格式包括但不限于MP4、3GP、MKV、FLV等。break;
Android N Audio播放五：如何选择Extractor
光着脚丫行一生的专栏
02-23 3516
我们在Android N Audio播放三：prepare大揭秘介绍了在prepare的过程中会创建Extractor, Extractor的主要作用是从容器格式中把音频和视频剥离出来，为之后的解码提供音频流和视频流，要知道。音频和视频的解码是分离的， 所以Extractor这一步非常重要。1. Extractor流程图 　　如惯例，我们还是先上流程图，对这个过程涉及到的类有个大概的了解。
Android native crash解析
张晖的专栏
08-15 4783
当某个进程发生crash时会出现下面的错误日志，它可能出现在logcat日志或者/data/tombstones目录下的tombstone文件中 --------- beginning of crash 10-24 00:29:11.558 8660 8934 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x1c in tid 8934 (MainThread) 10-24 00:29:11.620 468 468 F DE
Android控制音频播放速度及获取raw资源
Ser_Bad的博客
12-21 4512
最近遇到一个控制音频播放速度的问题，常用的方法是使用SoundPool。但是这个方法有一个问题就是在我的努比亚努比亚手机上只能播放3秒，我没有在源码里面找到设置的地方，但是打印的日志信息里面有这么一条：D/MMParserExtractor: Using default parser out buffer size = 3000，而且只能播放本地文件或者保存在raw中文件，无法直接播放网络文件，只
Android音视频开发（三）——MediaExtractor和MediaMuxer的使用
indeedes的博客
05-23 4853
了解了音视频的编解码过程，我们接下来使用一下经常跟MediaCodec一起搭配的MediaExtractor和MediaMuxer。最后会使用一个简单的demo来了解具体了解这两个工具类的使用过程。这一节我们就先不讲MediaCodec了，放到下节的demo。 一、MediaExtractor Android提供了一个MediaExtractor类，可以用来分离容器中的视频track和音频track。 主要API介绍： setDataSource(String path)：即可以设置本地文件又
简易多媒体流分析工具参数详解与选项指南
5. `-muxers` 和 `-demuxers`: 分别列出可用的包装器（muxers）和解包装器（demuxers），它们在处理多流文件时起着关键作用，可以创建或拆分不同的媒体流。 6. `-devices`: 列出系统的音频/视频输入和输出设备，这...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值