Android 13 - Media框架（8）- MediaExtractor

news2024/12/29 9:38:05

上一篇我们了解了 GenericSource 需要依赖 IMediaExtractor 完成 demux 工作，这一篇我们就来学习 android media 框架中的第二个服务 media.extractor，看看 IMediaExtractor 是如何创建与工作的。

1、MediaExtractorService

media.extractor 和 media.player 是属于同一层级的 binder service，都用于提供媒体播放支持，media.player 用于提供播放器功能，而 media.extractor 主要用于本地文件播放的解封装工作。

MediaExtractorService 相关代码位于：
frameworks/av/services/mediaextractor
frameworks/av/media/libmedia
frameworks/av/media/libstagefright

media.extractor 中提供服务的主体是 MediaExtractorService ，创建 IMediaExtractor 需要借助 MediaExtractorService 的力量，这一点和 media.player 的设计是一致的，创建 IMediaPlayer 需要借助 MediaPlayerService 的力量。这两个 service 起着创建和管理实际工作实例的功能。

MediaExtractorService 所继承的 BnMediaExtractorService 由 aidl 文件生成，IMediaExtractorService.aidl 在 libmedia 目录下，总共有3个方法可供使用：

interface IMediaExtractorService {
    IMediaExtractor makeExtractor(IDataSource source, @nullable @utf8InCpp String mime);
    IDataSource makeIDataSource(in FileDescriptor fd, long offset, long length);
    @utf8InCpp String[] getSupportedTypes();
}

接下来看 MediaExtractorService 中到底包含哪些内容。首先来看构造函数：

MediaExtractorService::MediaExtractorService() {
    MediaExtractorFactory::LoadExtractors();
}

构造函数调用了 MediaExtractorFactory::LoadExtractors 将平台上所有的 extractor lib 加载到 MediaExtractorService 进程：

void MediaExtractorFactory::LoadExtractors() {
    Mutex::Autolock autoLock(gPluginMutex);
    
    std::shared_ptr<std::list<sp<ExtractorPlugin>>> newList(new std::list<sp<ExtractorPlugin>>());


        RegisterExtractors("/apex/com.android.media/lib"
#ifdef __LP64__
                "64"
#endif
                "/extractors", &dlextinfo, *newList);

    } else {
        ALOGE("couldn't find media namespace.");
    }

    RegisterExtractors("/system/lib"
#ifdef __LP64__
            "64"
#endif
            "/extractors", NULL, *newList);

    RegisterExtractors("/system_ext/lib"
#ifdef __LP64__
            "64"
#endif
            "/extractors", NULL, *newList);

    newList->sort(compareFunc);
    gPlugins = newList;

    for (auto it = gPlugins->begin(); it != gPlugins->end(); ++it) {
        if ((*it)->def.def_version == EXTRACTORDEF_VERSION_NDK_V2) {
            for (size_t i = 0;; i++) {
                const char* ext = (*it)->def.u.v3.supported_types[i];
                if (ext == nullptr) {
                    break;
                }
                gSupportedExtensions.push_back(std::string(ext));
            }
        }
    }
}

lib 加载总共分为2步：

  1. 到 /apex/com.android.media/lib/extractor /system/lib/lib /system_ext/lib 这三个目录下寻找名字中包含 extractor.so 的 lib，打开这些 lib 并用 dlsym 找到 lib 中的 GETEXTRACTORDEF 函数，最后将 libHandle，GETEXTRACTORDEF 的返回值 ExtractorDef 以及 path 封装成一个 ExtractorPlugin 存到 list 当中；
  2. 遍历 ExtractorPlugin 读取 ExtractorDef 中定义的可以支持的扩展名，存储到一个列表中。

初学的时候看这里觉得晕晕乎乎的，一层套一层让人很难理解，但是从框架的角度来看就很清除很多。

所有的 extractor 都要遵循设计规则，实现 GETEXTRACTORDEF 函数，函数的返回值是一个 ExtractorDef 对象，ExtractorDef 声明在 MediaExtractorPluginApi.h 中：

struct ExtractorDef {
    // version number of this structure
    const uint32_t def_version;

    // A unique identifier for this extractor.
    // See below for a convenience macro to create this from a string.
    media_uuid_t extractor_uuid;

    // Version number of this extractor. When two extractors with the same
    // uuid are encountered, the one with the largest version number will
    // be used.
    const uint32_t extractor_version;

    // a human readable name
    const char *extractor_name;

    union {
        struct {
            SnifferFunc sniff;
        } v2;
        struct {
            SnifferFunc sniff;
            // a NULL terminated list of container mime types and/or file extensions
            // that this extractor supports
            const char **supported_types;
        } v3;
    } u;
};

以下是结构体中成员的含义：

  • def_version：这个结构体的版本；
  • extractor_uuid：当前 extractor 独一无二的 id，可以使用 constUUID 方法来生成 ，使用方法查看该方法注释；
  • extractor_version：extractor 的版本，如果两个 extractor uuid 相同，那么加载时只会存储高版本的那个；
  • extractor_name：extractor 的名字，同样可以由我们自己定义；
  • u：它是一个联合体，我们只关注 v3，v3 中有一个 SnifferFunc，这就是后面选择 extractor 的依据；supported_types 表示当前 extractor 所支持的 mine type 或者 文件后缀，必须要以 NULL结尾。

MediaExtractorFactory::LoadExtractors 那么多步骤核心就是或者每个 extractor lib 所定义的 ExtractorDef。

使用 dumpsys media.extractor 查看服务的信息，可以看到加载到的 extractor 的名称，版本，路径和支持解析的文件类型，这些都是从 ExtractorDef 中获取到的。

generic_x86:/ $ dumpsys media.extractor
Available extractors:
              AAC Extractor: plugin_version(3), uuid(4fd80eae03d24d729eb948fa6bb54613), version(1), path(/apex/com.android.media/lib/extractors/libaacextractor.so), supports: aac
              AMR Extractor: plugin_version(3), uuid(c86639c92f3140aca715fa01b4493aaf), version(1), path(/apex/com.android.media/lib/extractors/libamrextractor.so), supports: amr awb
             FLAC Extractor: plugin_version(3), uuid(1364b048cc454fda9934327d0ebf9829), version(1), path(/apex/com.android.media/lib/extractors/libflacextractor.so), supports: flac fl
             MIDI Extractor: plugin_version(3), uuid(ef6cca0af8a243e6ba5fdfcd7c9a7ef2), version(1), path(/apex/com.android.media/lib/extractors/libmidiextractor.so), supports: imy mid midi mxmf ota rtttl rt
x smf xmf
              MP3 Extractor: plugin_version(3), uuid(812a3f6cc8cf46deb5293774b14103d4), version(1), path(/apex/com.android.media/lib/extractors/libmp3extractor.so), supports: mp2 mp3 mpeg mpg mpga
              MP4 Extractor: plugin_version(3), uuid(27575c6744174c548d3d8e626985a164), version(2), path(/apex/com.android.media/lib/extractors/libmp4extractor.so), supports: 3g2 3ga 3gp 3gpp 3gpp2 m4a m4r
m4v mov mp4 qt
      MPEG2-PS/TS Extractor: plugin_version(3), uuid(3d1dcfebe40a436da574c2438a555e5f), version(1), path(/apex/com.android.media/lib/extractors/libmpeg2extractor.so), supports: m2p m2ts mts ts
         Matroska Extractor: plugin_version(3), uuid(abbedd9238c44904a4c1b3f45f899980), version(1), path(/apex/com.android.media/lib/extractors/libmkvextractor.so), supports: mka mkv webm
              Ogg Extractor: plugin_version(3), uuid(8cc5cd06f772495e8a62cba9649374e9), version(1), path(/apex/com.android.media/lib/extractors/liboggextractor.so), supports: oga ogg opus
              WAV Extractor: plugin_version(3), uuid(7d61385858374a3884c5332d1cddee27), version(1), path(/apex/com.android.media/lib/extractors/libwavextractor.so), supports: wav

看到这里我会有一些疑问：为什么 MediaExtractor 要以服务的形式提供呢？

我想到的可能有这些：

  • 如果要有一个进程要使用 extractor，按照 MediaExtractorFactory 的加载方法，每个进程都要加载所有的 lib，这是很耗费时间的。放到 MediaExtractorService 一个地方加载，其他地方就都可以使用了。
  • 创建的所有的 IMediaExtractor 都可以用 MediaExtractorService 管理；
  • 如果要新增 extractor，只要按照设计规则实现，编译push到指定目录下就可以生效，不用修改加载部分的代码；

但是，我觉得 extractor 不需要以服务的形式存在，以服务的形式提供反而会损失性能，按照 ffmpeg 的方式，用一个函数指针列表来存储 ExtractorDef 效率应该也很高。

带着这个问题我们一起来看下面的内容。

2、MediaExtractorFactory

我们在上文已经对 MediaExtractorFactory 有了部分解，接下来我们将继续了解它的其他作用：

  1. 在 service 进程搜索加载所有的 extractor lib；
  2. 提供 Create 方法给 client 进程，封装 binder 调用；
  3. 帮助 service 进程创建 IMediaExtractor 实例；

第一点我们在上文已经了解过了，主要是通过 LoadExtractors 方法来加载 lib，获取 lib 中的GETEXTRACTORDEF 函数，这里就不再多做了解。

接下来回到 GenericSource 中看 Create 方法是如何使用的：

status_t NuPlayer::GenericSource::initFromDataSource() {
	sp<IMediaExtractor> extractor;
    sp<DataSource> dataSource;
    {
        Mutex::Autolock _l_d(mDisconnectLock);
        dataSource = mDataSource;
    }
	extractor = MediaExtractorFactory::Create(dataSource, NULL);
}

可以发现，并没有直接调用 MediaExtractorService::makeExtractor 来创建 IMediaExtractor 对象，而是调用的 MediaExtractorFactory::Create：

sp<IMediaExtractor> MediaExtractorFactory::Create(
        const sp<DataSource> &source, const char *mime) {
    // 1. 在调用进程创建 extractor
    if (!property_get_bool("media.stagefright.extractremote", true)) {
        // local extractor
        ALOGW("creating media extractor in calling process");
        return CreateFromService(source, mime);
    } else {
        // 2. 创建远程 extractor
        // remote extractor
        ALOGV("get service manager");
        sp<IBinder> binder = defaultServiceManager()->getService(String16("media.extractor"));

        if (binder != 0) {
            sp<IMediaExtractorService> mediaExService(
                    interface_cast<IMediaExtractorService>(binder));
            sp<IMediaExtractor> ex;
            mediaExService->makeExtractor(
                    CreateIDataSourceFromDataSource(source),
                    mime ? std::optional<std::string>(mime) : std::nullopt,
                    &ex);
            return ex;
        } else {
            ALOGE("extractor service not running");
            return NULL;
        }
    }
    return NULL;
}

Create 方法提供了创建 extractor 的两种方式：

  1. 本地 extractor：在调用进程创建 IMediaExtractor；
  2. 远程 extractor：调用 MediaExtractorService 创建远程 IMediaExtractor。

第一点说明我们在上一节最后的猜想是多余的，Android 已经提供了在调用进程创建 MediaExtractor 的方式，但是可能为了更方便管理，默认使用远程的版本。

两种模式的选择使用 media.stagefright.extractremote 属性来控制，若值为空 或者 true 就创建远程 extractor，否则创建本地 extractor。

这里还要提一下 DataSource，在 GenericSource::onPrepareAsync 中，如果上层传下来的是 url 不为空，那么就创建本地 DataSource；如果传递的是 fd，要用是远程 extractor 就创建远程 DataSource，否则创建本地 DataSource。

接下来我们只去关注平时用的比较多的情况：extractor 为远程创建，datasource 为本地创建。

回到 MediaExtractorFactory 中来，Create 方法最后会调用 MediaExtractorService 的 makeExtractor 创建远程 IMediaExtractor 对象：

::android::binder::Status MediaExtractorService::makeExtractor(
        const ::android::sp<::android::IDataSource>& remoteSource,
        const ::std::optional< ::std::string> &mime,
        ::android::sp<::android::IMediaExtractor>* _aidl_return) {
    ALOGV("@@@ MediaExtractorService::makeExtractor for %s", mime ? mime->c_str() : nullptr);

    sp<DataSource> localSource = CreateDataSourceFromIDataSource(remoteSource);

    MediaBuffer::useSharedMemory();
    // 1、创建 Extractor
    sp<IMediaExtractor> extractor = MediaExtractorFactory::CreateFromService(
            localSource,
            mime ? mime->c_str() : nullptr);

    ALOGV("extractor service created %p (%s)",
            extractor.get(),
            extractor == nullptr ? "" : extractor->name());
	// 2、存储 Extractor
    if (extractor != nullptr) {
        registerMediaExtractor(extractor, localSource, mime ? mime->c_str() : nullptr);
    }
    *_aidl_return = extractor;
    return binder::Status::ok();
}

makeExtractor 又会回到 MediaExtractorFactory 的调用，但是这时候已经进到到 Service 进程当中，CreateFromService 很简单，就是遍历加载的内容，调用 sniff 函数选择最合适的 extractor。

ExtractorDef.u.v3.sniff 函数返回的是函数指针，并不是一个具体的 extractor 对象。这是因为执行 sniff 函数会返回置信度，遍历完成后会选择置信度最高的那个 extractor，如果 sniff 执行完就返回一个具体的对象，那么遍历一次就会创建多个对象，创建多个对象再释放，这样的效率是很低的。

IMediaExtractor 创建完成后会调用 registerMediaExtractor 注册到一个容器中，以弱引用的形式存储，不会影响实例的生命周期。这个容器存储有最近十次播放用到的 extractor 信息，我们可以用 dumpsys media.extractor 来查看，如果对象没有释放那么 extractor 和 track 会输出 active，否则输出 deleted。

console:/ # dumpsys media.extractor
......
Recent extractors, most recent first:
  08-07 04:01:43: MPEG4Extractor for mime NULL, source TinyCacheSource(CallbackDataSource(486->490, RemoteDataSource(FileSource(fd(/storage/42BA-A9CA/Video/cd1.mp4), 0, 263428780)))), pid 490: active
    track {trID: (int32_t) 2, srte: (int32_t) 44100, mxBr: (int32_t) 40268, mime: (char*) audio/mp4a-latm, lang: (char*) und, inpS: (int32_t) 416, esds: (unknown type 1702061171, size 30), dura: (int64_t) 2601842358, aaot: (int32_t) 2, #chn: (int32_t) 2} : active
    track {widt: (int32_t) 1280, trID: (int32_t) 1, nfrm: (int32_t) 65041, mime: (char*) video/avc, lang: (char*) und, inpS: (int32_t) 79222, heig: (int32_t) 720, frmR: (int32_t) 25, dura: (int64_t) 2601640000, dWid: (int32_t) 1280, dHgt: (int32_t) 720, avcc: (unknown type 1635148643, size 46)} : active

3、IDataSource

我们都知道要通过 binder 传递对象，这个对象必须要实现 binder 接口（Bp/Bn那套）。由于 GenericSource 中创建的 DataSource 只是一个普通对象，所以是不能通过 binder 传递的。为了让 MediaExtractorService 进程能够使用这个 DataSource对象，MediaExtractorFactory 帮我们做了一层封装。

sp<IMediaExtractor> MediaExtractorFactory::Create(
...
	mediaExService->makeExtractor(CreateIDataSourceFromDataSource(source), mime ? 		std::optional<std::string>(mime) : std::nullopt, &ex);
...
}

MediaExtractorFactory 调用 CreateIDataSourceFromDataSource 把 DataSource 封装到 RemoteDataSource 中，再将 RemoteDataSource 通过 binder 传递给 MediaExtractorService。

sp<IDataSource> CreateIDataSourceFromDataSource(const sp<DataSource> &source) {
    if (source == nullptr) {
        return nullptr;
    }
    return RemoteDataSource::wrap(source);
}

先来看 IDataSource 声明的接口（声明与实现均位于 libmedia）：

class IDataSource : public IInterface {
public:
    DECLARE_META_INTERFACE(DataSource);
    
    virtual sp<IMemory> getIMemory() = 0;
    virtual ssize_t readAt(off64_t offset, size_t size) = 0;
    virtual status_t getSize(off64_t* size) = 0;
    virtual void close() = 0;
    virtual uint32_t getFlags() = 0;
    virtual String8 toString() = 0;
};
  1. getIMemory：获取缓冲区地址；
  2. readAt：从指定偏移位置读取数据；
  3. getSize：获取读取文件的大小；
  4. close：减少 DataSource 和 缓冲区对象 的引用；
  5. getFlags：获取 DataSource 的标志位；
  6. toString：获取当前 DataSource 的名称；

这里抛出一个疑问，为什么 IDataSource 要开 getIMemory 接口呢？

我们平时使用 binder 调用时一般只会传递几个参数，并且这些参数需要的内存比较小。如果我们需要通过 binder 传递大量数据，比如这里用 DataSource 读取大量数据传递给 IMediaExtractor 解析，要怎么办呢？

Android 已经为我们提供了共享内存类 IMemory，用这个类就可以让两个进程访问同一块内存，实现不同进程的数据拷贝，这里的 getIMemory 就是让远程代理获取本地对象创建的共享内存对象。

    explicit RemoteDataSource(const sp<DataSource> &source) {
        Mutex::Autolock lock(mLock);
        mSource = source;
        sp<MemoryDealer> memoryDealer = new MemoryDealer(kBufferSize, "RemoteDataSource");
        mMemory = memoryDealer->allocate(kBufferSize);
        if (mMemory.get() == nullptr) {
            ALOGE("Failed to allocate memory!");
        }
        mName = String8::format("RemoteDataSource(%s)", mSource->toString().string());
    }

RemoteDataSource 的构造函数中使用 MemoryDealer 创建了共享内存对象 Allocation，共享内存大小为 64 KB。

RemoteDataSource 是在 GenericSource 所在进程中创建的，所以 GenericSource 所在的 MediaPlayerService 进程为 server，调用者 MediaExtractor 所在的 MediaExtractorService 进程为 client。数据读取的流程如下：

  1. client 进程调用 readAt方法；
  2. server 进程将数据写到共享内存；
  3. client 将数据从共享内存拷贝出来，完成一次 readAt 读取。

继续往下看，MediaExtractorService 收到传递过来的 IDataSource 对象后，会对他进行封装:

::android::binder::Status MediaExtractorService::makeExtractor(
...
	sp<DataSource> localSource = CreateDataSourceFromIDataSource(remoteSource);
...
}

sp<DataSource> CreateDataSourceFromIDataSource(const sp<IDataSource> &source) {
    if (source == nullptr) {
        return nullptr;
    }
    return new TinyCacheSource(new CallbackDataSource(source));
}

从 CreateDataSourceFromIDataSource 可以看到对 IDataSource 进行了两层封装，第一层是 CallbackDataSource，第二层是 TinyCacheSource。

CallbackDataSource 是直接调用 IDataSource 的，由于共享内存大小有限，一次最多读取 64 KB，如果我们要一次读取更多的数据，就要多次调用 IDataSource.readAt 方法，CallbackDataSource 的 readAt 方法帮助我们完成了多次读取调用的封装。

ssize_t CallbackDataSource::readAt(off64_t offset, void* data, size_t size) {
......
    size_t totalNumRead = 0;
    size_t numLeft = size;
    const size_t bufferSize = mMemory->size();

    while (numLeft > 0) {
        size_t numToRead = std::min(numLeft, bufferSize);
        ssize_t numRead =
            mIDataSource->readAt(offset + totalNumRead, numToRead);
        // A negative return value represents an error. Pass it on.
        if (numRead < 0) {
            return numRead == ERROR_END_OF_STREAM && totalNumRead > 0 ? totalNumRead : numRead;
        }
        // A zero return value signals EOS. Return the bytes read so far.
        if (numRead == 0) {
            return totalNumRead;
        }
        if ((size_t)numRead > numToRead) {
            return ERROR_OUT_OF_RANGE;
        }
        CHECK(numRead >= 0 && (size_t)numRead <= bufferSize);
        memcpy(((uint8_t*)data) + totalNumRead, mMemory->unsecurePointer(),
            numRead);
        numLeft -= numRead;
        totalNumRead += numRead;
    }
    return totalNumRead;
}

第二层封装 TinyCacheSource 从名字就可以知道是做缓冲区的作用，读取的数据会存到缓冲区中，使用时优先从缓冲区中读取，如果数据不够再真正去读取，这里就不再粘贴代码了。

再回到 MediaExtractorFactory 创建 IMediaExtractor 的地方：

sp<IMediaExtractor> MediaExtractorFactory::CreateFromService(
        const sp<DataSource> &source, const char *mime) {
    ......
        CMediaExtractor *ret = ((CreatorFunc)creator)(source->wrap(), meta);
	......
}

调用 sniff 返回的函数指针时，向下传的 DataSource 又做了一层C语言风格的封装变成 CDataSource，这一层完全可以不不看，如果想学习C语言风格的面向对象编程可以了解一下。

我们以 MPEG2TSExtractor 为例，看看 sniff 返回的函数指针是什么：

return [](
      CDataSource *source,
      void *) -> CMediaExtractor* {
      return wrap(new MPEG2PSExtractor(new DataSourceHelper(source)));};

调用这个函数指针最终会进入到真正的 extractor 构造函数中，这里又对 CDataSource 进行了封装，成为了 DataSourceHelper。

DataSourceHelper 就不仅仅只封装了，它还扩充了一些便利的方法，例如 getUInt16、getUInt24、getUInt32、getUInt64，用来一次读取 2bytes、3bytes、4bytes、8bytes。

到这里 DataSouce 就阅读完毕了，如果用时序图来表达调用顺序，这么多层的嵌套画出来的时序图估计别人一看就晕了。

我这里依旧用框架图来表示他们的层级结构：
请添加图片描述

4、IMediaExtractor

IMediaExtractor 的层级结构在上面的图中已经画出来了，它比 IDataSource 要简单很多，CMediaExtractor 和 MediaExtractorCUnwrapper 这两层完全可以忽略，只是接口封装而已，IMediaExtractor 就不再做过多了解。

5、IMediaSource

MediaExtractor 会解析出当前播放码流中的 track， 调用 getTrack 方法会为指定 track 创建 IMediaSource，调用 IMediaSource 读取的数据就是该 track 所包含的数据。

每个 extractor 都有自己的 MediaSource，它们都继承于 MediaTrackHelper，但是内部实现各不相同。我们这里不会关注 MediaSource 具体是如何实现的，重点是了解 IMediaSource 的框架。

以下是我绘制的 IMediaSource 的框架图：

请添加图片描述

RemoteMeiaSource 封装了 MediaTrack，最内部的实现是 MediaTrackHelper。MediaTrackHelper 中有一个成员 MediaBufferGroupHelper，这个成员需要通过 MediaTrackHelper 的构造函数设定，在它的外层 MediaTrack 的 start 方法中创建并设定下去：

status_t MediaTrackCUnwrapper::start() {
    if (bufferGroup == nullptr) {
        bufferGroup = new MediaBufferGroup();
    }
    return reverse_translate_error(wrapper->start(wrapper->data, bufferGroup->wrap()));
}

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;
    }
    ((MediaTrackHelper*)data)->mBufferGroup = new MediaBufferGroupHelper(bufferGroup);
    return ((MediaTrackHelper*)data)->start();
};

MediaBufferGroup 其实是一个 BufferPool，里面储存着一个个 MediaBuffer 对象，MediaBuffer 封装有 shared memory（IMemory）或者是普通 memory，这里的设计应该是为了内存复用，并且减少拷贝次数，接下来们来看具体是如何实现的。

在 extractor 中会调用 MediaBufferGroup 的 init 方法，设定内部 MediaBuffer 的数量，以及内部 buffer size 的大小，同时分配这些buffer：

void MediaBufferGroup::init(size_t buffers, size_t buffer_size, size_t growthLimit) {
    mInternal->mGrowthLimit = growthLimit;

    if (mInternal->mGrowthLimit > 0 && buffers > mInternal->mGrowthLimit) {
        ALOGW("Preallocated buffers %zu > growthLimit %zu, increasing growthLimit",
                buffers, mInternal->mGrowthLimit);
        mInternal->mGrowthLimit = buffers;
    }

#if !defined(NO_IMEMORY) && !defined(__ANDROID_APEX__)
    if (buffer_size >= kSharedMemoryThreshold) {
        ALOGD("creating MemoryDealer");
        // Using a single MemoryDealer is efficient for a group of shared memory objects.
        // This loop guarantees that we use shared memory (no fallback to malloc).

        size_t alignment = MemoryDealer::getAllocationAlignment();
        size_t augmented_size = buffer_size + sizeof(MediaBuffer::SharedControl);
        size_t total = (augmented_size + alignment - 1) / alignment * alignment * buffers;
        sp<MemoryDealer> memoryDealer = new MemoryDealer(total, "MediaBufferGroup");

        for (size_t i = 0; i < buffers; ++i) {
            sp<IMemory> mem = memoryDealer->allocate(augmented_size);
            if (mem.get() == nullptr || mem->unsecurePointer() == nullptr) {
                ALOGW("Only allocated %zu shared buffers of size %zu", i, buffer_size);
                break;
            }
            MediaBuffer *buffer = new MediaBuffer(mem);
            buffer->getSharedControl()->clear();
            add_buffer(buffer);
        }
        return;
    }
#else
    (void)kSharedMemoryThreshold;
#endif

    // Non-shared memory allocation.
    for (size_t i = 0; i < buffers; ++i) {
        MediaBuffer *buffer = new MediaBuffer(buffer_size);
        if (buffer->data() == nullptr) {
            delete buffer; // don't call release, it's not properly formed
            ALOGW("Only allocated %zu malloc buffers of size %zu", i, buffer_size);
            break;
        }
        add_buffer(buffer);
    }
}

如果 buffer size 大于 4KB，那么给 MediaBuffer 分配共享内存，如果 buffer size 小于 4KB，那么就分配普通内存。当调用 IMediaSource 的 read 或者 readMultiple 方法时，会调用 MediaBufferGroup acquire_buffer 获取一个 buffer，并将 demux 后的数据写入到这个 buffer 当中。

为什么 IMediaSource read 不用一块共享内存来传递，而要用多块 MediaBuffer 来传递呢？这是因为 demux 后的数据是以 帧 为单位存储的，我们希望每次拷贝都是一帧，用单独的 MediaBuffer 管理会更方便。

回到 IMediaSource.cpp，这里是 IMediaSource 的 Bn 实现，我们来看 readMultiple 是如何做的：

case READMULTIPLE: {
				// 1、读取一帧数据
				ret = read((MediaBufferBase **)&buf, useOptions ? &opts : nullptr);
                // Even if we're using shared memory, we might not want to use it, since for small
                // sizes it's faster to copy data through the Binder transaction
                // On the other hand, if the data size is large enough, it's better to use shared
                // memory. When data is too large, binder can't handle it.
                //
                // TODO: reduce MediaBuffer::kSharedMemThreshold
                MediaBuffer *transferBuf = nullptr;
                const size_t length = buf->range_length();
                size_t offset = buf->range_offset();
                // 2、如果数据长度大于阈值，并且使用的是共享内存
                if (length >= (supportNonblockingRead() && buf->mMemory != nullptr ?
                        kTransferSharedAsSharedThreshold : kTransferInlineAsSharedThreshold)) {
                    if (buf->mMemory != nullptr) {
                        ALOGV("Use shared memory: %zu", length);
                        transferBuf = buf;
                    }
                }
                // 3、将 buffer 返回
                if (transferBuf != nullptr) { // Using shared buffers.
                    uint64_t index = mIndexCache.lookup(transferBuf->mMemory);
                    if (index == 0) {
                        index = mIndexCache.insert(transferBuf->mMemory);
                        reply->writeInt32(SHARED_BUFFER);
                        reply->writeUint64(index);
                        reply->writeStrongBinder(IInterface::asBinder(transferBuf->mMemory));
                    } else {
                        reply->writeInt32(SHARED_BUFFER_INDEX);
                        reply->writeUint64(index);
                    }
                    reply->writeInt32(offset);
                    reply->writeInt32(length);
                    buf->meta_data().writeToParcel(*reply);
                    transferBuf->addRemoteRefcount(1);
                    if (transferBuf != buf) {
                        transferBuf->release(); // release local ref
                    } else if (!supportNonblockingRead()) {
                        maxNumBuffers = 0; // stop readMultiple with one shared buffer.
                    }
                } else {
                    reply->writeInt32(INLINE_BUFFER);
                    reply->writeByteArray(length, (uint8_t*)buf->data() + offset);
                    buf->meta_data().writeToParcel(*reply);
                    inlineTransferSize += length;
                    if (inlineTransferSize > kInlineMaxTransfer) {
                        maxNumBuffers = 0; // stop readMultiple if inline transfer is too large.
                    }
                }
                // 5、释放本地 buffer
                buf->release();
}

这里的代码有点长，但是逻辑并不复杂：

  1. 调用 read 方法将 demux 后的数据读到 MediaBuffer 中；
  2. 如果数据长度短，用内存拷贝会更快，如果数据长则用共享内存会快，另一方面如果数据长度过长，binder 将无法处理；
  3. 返回数据时会判断数据长度，如果用了共享内存，但是数据长度短，接下来将 buffer 返回时还是会以拷贝的方式返回；
  4. 以共享内存的方式返回时，需要增加远程的引用计数，防止 MediaBuffer 被重复使用。
  5. 释放本地 buffer，将本地 buffer 返回到 MediaBufferGroup；

我们要注意的是 MediaBuffer 里面使用了引用计数，但是并没有继承于 RefBase。在这里，调用 MediaBuffer 的 release 方法，让他的引用计数为 0 时，会有 Callback 发到 MediaBufferGroup，通知有空闲的 buffer 可以使用。buffer 可用的条件是 远程和本地 的引用计数之和为 0，所以上层将 buffer 拷贝完成之后需要调用 release，将远程的引用计数减一。

到这儿 IMediaSource 的了解就结束了，它内部维护了一套生产者-消费者机制，这边讲的可能不是那么详细，但是了解了大致框架，相信其他内容就很容易看懂了。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/929427.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

【ArcGIS微课1000例】0071：普通最小二乘法 (OLS)回归分析案例

【ArcGIS微课1000例】0071：普通最小二乘法 (OLS)回归分析案例

严重声明：本文来自专栏《ArcGIS微课1000例：从点滴到精通》，为CSDN博客专家刘一哥GIS原创，原文及专栏地址为：(https://blog.csdn.net/lucky51222/category_11121281.html)，谢绝转载或爬取！！！ 文章目录 一、空间自回归模型二、ArcGIS普通最小二乘法回归（OLS）一、空间自…
阅读更多...
企业ADManager Plus软件的使用案例

企业ADManager Plus软件的使用案例

引言&#xff1a; 在当今数字化时代&#xff0c;企业的活动主要依赖于信息技术和计算机系统。作为关键的IT基础架构组件之一&#xff0c;Active Directory&#xff08;AD&#xff09;在维护和管理用户、计算机和资源方面发挥着关键作用。AD的高效管理对于确保企业的平稳运行至…
阅读更多...
HDFS 集群读写压测

HDFS 集群读写压测

文章目录 虚拟机设置HDFS 写数据测试HDFS 读数据测试删除压测产生的数据 虚拟机设置 如果你是在虚拟机中使用集群&#xff0c;那你你需要先对每台服务器进行网络设置&#xff0c;模拟真实网络传输速率。 如下所示&#xff1a; 将其设置为百兆网&#xff0c;每台服务器都要进行…
阅读更多...
基于Android的课程教学互动系统 微信小程序uniapp

基于Android的课程教学互动系统 微信小程序uniapp

教学互动是学校针对学生必不可少的一个部分。在学校发展的整个过程中&#xff0c;教学互动担负着最重要的角色。为满足如今日益复杂的管理需求&#xff0c;各类教学互动程序也在不断改进。本课题所设计的springboot基于Android的教学互动系统&#xff0c;使用SpringBoot框架&am…
阅读更多...
云计算存储类型

云计算存储类型

一、共享存储模式 NAS: ①一种专门用于存储和共享文件的设备&#xff0c;它通过网络连接到计算机或其他设备&#xff0c; 提供了一个中心化的存储解决方案 ②存储网络使用IP网络 &#xff0c;数据存储共享基于文件 ③本质上为:NFS和CIFS文件共享服务器 ④提供的不是一个磁盘块…
阅读更多...
uniapp结合Canvas+renderjs根据经纬度绘制轨迹（二）

uniapp结合Canvas+renderjs根据经纬度绘制轨迹（二）

uniapp结合Canvasrenderjs根据经纬度绘制轨迹 文章目录 uniapp结合Canvasrenderjs根据经纬度绘制轨迹效果图templaterenderjsjs数据结构 ​ 根据官方建议要想在 app-vue 流畅使用 Canvas 动画&#xff0c;需要使用 renderjs 技术&#xff0c;把操作canvas的js逻辑放到视图层运…
阅读更多...
优化物料编码规则，提升物料管理效率

优化物料编码规则，提升物料管理效率

导 读 ( 文/ 2358 ) 物料是生产过程的必需品。对物料进行身份的唯一标识&#xff0c;可以更好的管理物料库存、库位&#xff0c;更方便的对物料进行追溯。通过编码规则的设计&#xff0c;可以对物料按照不同的属性、类别或特征进行分类&#xff0c;从而更好地进行库存分析、计划…
阅读更多...
win10 maven 安装环境变量设置不成功

win10 maven 安装环境变量设置不成功

maven 按照正常步骤设置环境变量 输入命令总是不能正常现实mvn的版本 解决方案: 1.删除掉设置的用户环境变量 2.将maven的完整目录写入系统变量path中 3.将该路径放到所有变量的最前面 4.点击确定,重新打开cmd 输入 mvn -v 正常了
阅读更多...
C语言刷题指南（四）

C语言刷题指南（四）

&#x1f4d9;作者简介&#xff1a; 清水加冰&#xff0c;目前大二在读&#xff0c;正在学习C/C、Python、操作系统、数据库等。 &#x1f4d8;相关专栏&#xff1a;C语言初阶、C语言进阶、C语言刷题训练营、数据结构刷题训练营、有感兴趣的可以看一看。 欢迎点赞 &#x1f44d…
阅读更多...
摆动序列【贪心算法】

摆动序列【贪心算法】

摆动序列 如果连续数字之间的差严格地在正数和负数之间交替&#xff0c;则数字序列称为 摆动序列 。第一个差&#xff08;如果存在的话&#xff09;可能是正数或负数。仅有一个元素或者含两个不等元素的序列也视作摆动序列。 class Solution {public int wiggleMaxLength(int…
阅读更多...
Windows下 MySql通过拷贝data目录迁移数据库的方法

Windows下 MySql通过拷贝data目录迁移数据库的方法

MySQL数据库的文件目录下图所示&#xff0c; 现举例说明通过COPY文件夹data下数据库文件&#xff0c;进行数据拷贝的步骤&#xff1b;源数据库运行在A服务器上&#xff0c;拷贝到B服务器&#xff0c;假定B服务器上MySQL数据库已经安装完成&#xff0c;为空数据库。 首先进入A服…
阅读更多...
Java 程序打印 OpenCV 的版本

Java 程序打印 OpenCV 的版本

我们可以使用 Java 程序来使用 OpenCV。 OpenCV 的使用需要动态库的加载才可以。 加载动态库 到 OpenCV 的官方网站上下载最新的发布版本。 Windows 下载的是一个可执行文件&#xff0c;没关系&#xff0c;这个可执行文件是一个自解压程序。 当你运行以后会提示你进行解压。…
阅读更多...
百度“AI智障”到AI智能体验之旅

百度“AI智障”到AI智能体验之旅

目录 前言一、百度PLATO1.抬杠第一名2.听Ta瞎扯淡3.TA当场去世了4.智障与网友的高光时刻 二、文心一言1.设计测试用例2.随意发问3.手机端约会神器 三、体验总结&#xff1a;四、千帆大模型 前言 最近收到了文心一言3.5大模型的内测资格&#xff0c;正巧之前也体验过它的前身&q…
阅读更多...
分析系统 - 使用Python爬虫

分析系统 - 使用Python爬虫

在竞争激烈的市场环境中&#xff0c;了解和分析竞争对手的销售策略和市场表现对于企业的成功至关重要。本文将介绍如何利用Python爬虫建立低成本的销售竞争对手分析系统&#xff0c;探索其方法、工具和好处&#xff0c;并同时解决可能出现的问题。 销售竞争对手分析的目标是获取…
阅读更多...
PyTorch 模型性能分析和优化 - 第 2 部分

PyTorch 模型性能分析和优化 - 第 2 部分

动动发财的小手&#xff0c;点个赞吧&#xff01; 这是有关分析和优化在 GPU 上运行的 PyTorch 模型主题的系列文章的第二部分。在第一篇文章中&#xff0c;我们演示了使用 PyTorch Profiler 和 TensorBoard 迭代分析和优化 PyTorch 模型的过程以及巨大潜力。在这篇文章中&…
阅读更多...
36、springboot --- 对 tomcat服务器 和 undertow服务器 配置访客日志

36、springboot --- 对 tomcat服务器 和 undertow服务器 配置访客日志

springboot 配置访客日志 ★ 配置访客日志&#xff1a; 访客日志&#xff1a; Web服务器可以将所有访问用户的记录都以日志的形式记录下来&#xff0c;主要就是记录来自哪个IP的用户、在哪个时间点、访问了哪个资源。 Web服务器可将所有访问记录以日志形式记录下来&#xff…
阅读更多...
Vue2向Vue3过度核心技术进阶语法

Vue2向Vue3过度核心技术进阶语法

目录 1 v-model简化代码1.目标&#xff1a;2.如何简化&#xff1a;3.代码示例 2 sync修饰符1.作用2.场景3.本质4.语法5.代码示例6.总结 3 ref和$refs1.作用2.特点&#xff1a;3.语法4.注意5.代码示例 4 异步更新 & $nextTick1.需求2.代码实现3.问题4.解决方案 1 v-model简化…
阅读更多...
MES管理系统如何让传统汽车行业从“制造”走向“智造”

MES管理系统如何让传统汽车行业从“制造”走向“智造”

在传统制造业中&#xff0c;“数字化转型”是一个老生常谈的话题&#xff0c;然而&#xff0c;许多传统制造业仍处于“信息化”的阶段&#xff0c;距离真正的数字化还有很长的路要走。如果要在所有传统制造行业中寻找那些可以成为转型“先行者”的领域&#xff0c;那么深度与广…
阅读更多...
水果flstudio好用吗？中文版FL21最新版本如何下载

水果flstudio好用吗？中文版FL21最新版本如何下载

FL Studio21版是一款功能强大的音乐制作软件&#xff0c;广泛应用于电子音乐、流行音乐、电影配乐等领域。它提供了丰富多样的音频合成和编辑工具&#xff0c;使音乐制作变得更加灵活多样。无论是初学者还是专业音乐制作人&#xff0c;都可以通过直观的界面和丰富的音频特效来实…
阅读更多...
【IMX6ULL驱动开发学习】12.Linux SPI驱动实战：DAC驱动设计流程

【IMX6ULL驱动开发学习】12.Linux SPI驱动实战：DAC驱动设计流程

基础回顾&#xff1a; 【IMX6ULL驱动开发学习】10.Linux I2C驱动实战&#xff1a;AT24C02驱动设计流程_阿龙还在写代码的博客-CSDN博客 【IMX6ULL驱动开发学习】11.Linux之SPI驱动_阿龙还在写代码的博客-CSDN博客 一、编写驱动 查看芯片手册&#xff0c;有两种DAC数据格式&a…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023