青山渺渺

从这一章开始，我们会基于同步SimplePlayer改造出一个简单的异步播放器（AsyncSimplePlayer），通过一步步的代码实现，我们能够更清晰地学习NuPlayer的实现方式。我们将从简单的框架实现入手，根据需求逐步分析并完善我们的AsyncSimplePlayer。在本节中，我们会先简要介绍播放器所需的模块及其作用，然后开始实现简单解码器模块。

MediaCodec是Android系统为上层应用提供的硬件编解码类，它封装了ACodec和CCodec，隐藏了底层组件的实现细节，向上层应用提供了统一且易用的硬件编解码接口。由于MediaCodec是为上层应用提供的接口，因此我们不会对其内部实现进行深入探讨，本篇文章将先简单介绍MediaCodec的异步消息处理机制、缓冲区管理以及API的使用这三部分内容，然后通过SimplePlayer了解MediaCodec的同步模式用法，为异步模式的播放器实现打下基础。

这一篇我们对组件的控制过程（flush、resume、stop和release）做简单分析。

上一篇文章讲完了输出数据的回传过程，这一节我们再来过一遍数据渲染流程。

上篇文章CCodecBufferChannel::onWorkDone刚讲一半就扯到extraBuffer了，这一篇我们接着讲完onWorkDone的剩余部分。

本节主要对数据的输出过程做简单梳理，组件的处理过程可以参考SimpleC2Component和C2SoftHevcDec这两章内容，本节不做展开。

这一节我们一起过一下组件的启动与数据写入过程。

接下来的几篇文章，我们将对组件的创建、配置、启动、数据写入、数据处理、数据渲染、flush、release过程做完整的流程分析。本篇我们将一起阅读组件的创建与配置过程。

在这一篇文章中，我们将以C2SoftHevcDec为例，了解Codec2组件应该如何实现SimpleC2Component提供的接口，看完这一节我们应该对如何实现Codec2组件有清晰的思路。

在上一篇文章中，我们了解了SimpleC2Component提供的接口的含义。这一节，我们将以C2SoftHevcDec为例，探讨Codec2组件的参数应该如何定义。

在 Android Codec2（九）组件实现分析 一文中， 我们了解了Codec2组件的实现框架，接下来这一章我们将深入探讨组件的实现细节。

本节内容会对input buffer的追踪过程进行解析， 追踪分为上层（CCodecBufferChannel->PipelineWatcher）与组件层（Component->InputBufferManager）两部分。

这一节我们将对Codec2的跨进程数据传输相关的内容做简单了解。

在这一篇文章中，我们将一起探讨CCodec的输出端口管理类OutputBuffers。与之前学习的InputBuffers截然不同，OutputBuffers并不涉及buffer的分配工作，所以它有一套新的buffer管理方法，另外OutputBuffers还提供了reorder（重排序）功能。

在这一篇文章中，我们将了解C2GraphicBlock、C2BufferQueueBlockPoolData与C2GraphicView的实现。

上一篇文章对一些前置内容进行了介绍，这篇文章我们将继续阅读C2BufferQueueBlockPool的buffer分配相关内容。

我们在前面两篇文章中认识了C2PooledBlockPool以及C2LinearBlock，要注意的是C2PooledBlockPool除了可以被用于生产C2LinearBlock（1D）外，也可以用于生产C2GraphicBlock（2D）。在这一篇文章中，我们将对C2BlockPool的另一个子类C2BufferQueueBlockPool展开了解，它是专门用于生产C2GraphicBlock的。同样都可以生产C2GraphicBlock，它们又有什么区别呢？

CCodec使用CCodecBuffers来对输入/输出端口上的buffer进行管理，这一篇文章我们将一起了解InputBuffers，也就是输入端口的buffer管理方法。

在阅读Codec2框架代码时，我们可能会发现好几个名称中都带有“buffer”的类，如MediaCodecBuffer、ABuffer、CCodecBuffers、Codec2Buffer以及C2Buffer。它们分别是什么？各自承担着什么功能？它们之间有何联系？本文将围绕这三个问题展开了解。

在上一篇文章的结尾，我们看到fetchLinearBlock方法最终创建了一个C2LinearBlock对象。这一节，我们将深入了解C2LinearBlock是什么，它的作用是什么，以及它是如何被创建的。

在这篇文章中，我们首先将了解C2BlockPool是什么，随后会探讨C2BlockPool与buffer pool以及C2Allocator之间的关系。最后，我们将深入了解C2BlockPool的一个子类—C2PooledBlockPool的具体实现方式，以及它是如何分配buffers的。

Codec2框架通过引入bufferpool，实现了全新的buffer分配与传递机制。在本文中，我们将一起了解bufferpool框架的实现。

这一篇文章我们一起来瞧瞧2D（Graphic） buffer分配器C2AllocatorGralloc是如何工作的。

Codec2框架采用了全新的Buffer分配机制C2Allocator，这一篇文章我们一起来瞧瞧C2DmaBufAllocator是如何工作的。

上一篇文章我们一起了解了Codec2 Data Process过程中的Delay，buffer count计算方法和C2AllocatorStore，这一篇文章我们接着分析CCodecBufferChannel的start方法。

CCodecBufferChannel是整个Codec2框架最复杂的部分，涉及到input buffer分配，input/output buffer的处理，内部封装了一些全新的机制，比如reorder、pipeline control等。本篇内容主要对CCodecBufferChannel的start流程进行了解，涉及到的C2BlockPool、C2Allocator、InputBuffers、OutputBuffers本篇不做展开。

Codec2组件的运行参数都存储在Interface中，这些参数由厂商预先设定，并力求达到最优（best effort），因此非必要情况下不建议进行修改。在CCodec中，我们很少看到对组件参数的修改，这与ACodec对组件配置的过程形成了明显的对比。CCodecConfig在Codec2框架中主要起着参数存储的作用，参数来自于两部分：从组件实例读取的厂商预定义的参数和上层应用配置下来的参数。CCodecConfig还有另外一个重要功能：向上层提供参数反射，实现非标准参数的设定，这部分我们不做了解。

CCodec继承于CodecBase，向下封装了Codec2Client，向上提供接口给MediaCodec调用。CCodec包含CCodecBufferChannel和CCodecConfig两大子模块，相较ACodec而言，CCodec的职责划分与消息处理逻辑做了很大改动。本节将简单剖析CCodec中的部分设计思路，为后续的数据处理流程分析做准备。

Codec2Client隐藏了Codec2 HAL的调用细节，并在HAL接口的基础上重新做了抽象和封装然后提供给sfPlugin使用，在这一篇文章中我们将对Codec2Client的设计结构进行简单分析。

在上一篇文章中，我们详细梳理了HIDL层组件的创建过程。在这一篇文章中，我们将以C2SoftMpeg2Dec为例简单了解SW C2Component的实现架构。

在这一篇文章中，我们将先了解SW ComponentStore HIDL层的Codec2组件创建过程，然后了解组件实现架构。

上一篇文章我们了解了接口参数的定义，这一节我们简单梳理一下参数获取、配置以及参数反射过程。

通过前面几篇文章的学习，我们知道了Codec2参数结构，以及如何定义一个Codec2参数。接下来的几篇文章我们将简单了解上层是如何请求组件支持的参数、如何配置参数，以及参数是如何反射给上层的。本篇文章我们将了解接口参数实例化。

这一节我们来看看简单参数的定义方式。

DEFINE_AND_DESCRIBE_C2STRUCT和C2FIELD是不能分开的，使用时必须要按顺序依次调用这两个宏定义。宏定义比较复杂，我们以C2StoreIonUsageStruct为例直接看展开后的样子。好家伙，难道这就是宏魔法吗？！

Codec2框架在C2Config.h中预先定义了很多参数，接下来我们用几个例子来看看参数是如何定义的，以便我们能够根据需求自定义新的参数。

本篇文章我们会先简单了解Android Framework提供的Codec2软件编解码服务（SW Codec Service）的启动过程，然后分析C2Store的设计结构。

在正式学习Codec2框架之前，我们应该先对它的设计理念和设计思路有简单的了解，相比OpenMAX框架，Codec2修改了哪些地方，有哪些由于原先框架的部分，这样学习起来才更有针对性。Codec2的处理模型使用了Frame-based Processing（基于帧的处理），该模型有几个特点，输入帧与输出帧之间有强相关，N帧输入对应着N帧输出且输入与输出之间的延迟为0。Codec2的参数都是被类型化了，是基于C风格的结构体的，大多说的参数只有一个字段，并且可以暴露给app。

ACodec之所以复杂，主要是因为状态太多。在上一篇文章中，我们学习了在ExecutingState下对buffer的处理。ExecutingState可能会切换到OutputPortSettingsChangedState、FlushingState，或者当组件被释放时，进入UninitializedState。接下来，我们将探讨这些情况下的buffer处理流程。

本篇文章我们一起来分析Executing状态下的数据处理流程。首先对上一篇文章做勘误：实际在调用allocateOutputBuffersFromNativeWindow分配buffer时我们会看到，一开始确实是分配了nBufferCountActual个buffer，但是后面又调用cancelBufferToNativeWindow销毁掉了备用的。可能有人要问，前面调用了useBuffer把备用的buffer也共享给了组件，会不会有问题呢？