Android：MediaCodec基本原理_android mediacodec

最近需要使用MediaCodec做一些工作，因此对MediaCodec做了些研究和代码编写，在此先对MediaCodec的一些基础原理、工作流程、常用API等做个初步总结，方便后续开发过程中查阅。

---

1.MediaCodec简介

1.1 MediaCodec来历

Android从最初的API 1.0版本开始，集成了一种使用起来比较简单，用于播放音视频文件，但是只支持MP4、3GPP两种媒体格式的MediaPlayer，为了播放不支持的格式，许多开发人员不得不在开发过程中集成FFmpeg软件解码器

Android 4.1(API16)，MediaCodec首个版本推出，开发者在应用层就能直接调用底层编解码器，实现丰富的音视频功能

Android 4.3(API18)，MediaCodec引入Surface和OpenGLES，可以用OpenGLES对数据进行渲染，使用摄像头的预览数据作为输入

Android 5.0，API21，引入了异步模式，MediaCodec可以对输入数据和输出数据进行异步处理

1.2 MediaCodec是什么？

MediaCodec对应用端提供Java Api，其内部则通过调用各native方法实现对Android底层多媒体编解码器的调用，完成上层应用对音视频文件的编码和解码

开发者用到的是MediaCodec.java，它是android.media框架中的一个类

MediaCodec.java 位于Android源码：/frameworks/base/media/java/android/media/

谷歌developer网站上关于MediaCodec的详细注解：

MediaCodec  |  Android Developers

1.3 android.media

android.media框架是Framework中的多媒体管理模块，它并不是紧密耦合的单个模块，而是多个media相关功能组件的联合

AndroidN之前，framework中android.media的所有模块（包括播放、录制、camera、audio等）都在mediaserver进程中

AndroidN开始，出于安全性考虑（“stagefright安全漏洞“），mediaserver拆分为以下几个进程：
1）mediaserver：包括播放功能Mediaplayer和录制功能Mediarecoder；
2）mediacodec：音视频编解码功能；
3）mediaextractor：视频文件解封装；
4）cameraserver：相机服务；
5）audioserver：音频输出模块；
6）mediadrm：数字版权加解密；

也就是说MediaCodec是Android Media框架下，从MediaServer拆分出来的一个专门用于音视频编解码的进程 

---

2.MediaCodec工作机制

2.1 关联功能类

MediaCodec.java只是Framework中android.media里的一个类，在使用MediaCodec Java API对音视频文件进行编解码时，需要联合其他media功能文件一起使用，这一点在谷歌的官方注解网站里也有说明

常用的联合使用的功能类主要有如下：

 android.media.MediaExtractor;
 android.media.MediaSync;
 android.media.MediaMuxer;
 android.media.MediaFormat;
 android.media.MediaCrypto;
 android.media.MediaDrm;
 android.media.MediaCodec.BufferInfo;
 android.media.Image;
 android.media.AudioTrack;
 android.view.Surface;
 ......

2.2 MediaCodec工作流程

官网注解图：

MediaCodec的工作流程就是：处理输入数据、产生输出数据

MediaCodec运行过程中的数据传输，可以看成两路数据流：Input流、Output流
  ● Input流：客户端输入的待编码或解码的数据
  ● Output流：客户端输出的已编码或解码的数据

MediaCodec使用两组Buffer队列，通过同步或异步方式处理两路数据流：
  ● 包含一组InputBuffer(格式ByteBuffer)的InputBufferQueue
  ● 包含一组OutputBuffer(格式ByteBuffer)的OutputBufferQueue

1）Client也就是调用者从MediaCodec的InputBufferQueue中获取空的InputBuffer，写入要编码或解码的数据，提交给MediaCodec

2）MediaCodec收到数据进行处理，处理完毕后，将其转存到OutputBufferQueue中空的OutputBuffer(拷贝过程由mediacodec内部完成，调用者只需要关注OutputBufferQueue中空闲Buffer索引的变化)，同时释放InputBuffer，将它重新放回到InputBufferQueue

3）Client从MediaCodec的OutputBufferQueue中获取到一个空的OutputBuffer，读取数据进行使用，待Client处理完数据后，释放OutputBuffer并将其放回OutputBufferQueue

上述过程不断重复，
直至MediaCodec将数据处理完毕后，手动释放OutputBuffer

另外需要先注解一下的是：

同步模式：编解码器对Input和Output的数据处理是同步的，
                  数据输入和数据输出依次进行，
                  上一次数据输入后才能输出数据，
                  上一次数据输出后才能再次进行数据输入。

异步模式：编解码器对Input和Output的数据处理是异步的，
                  数据输入和数据输出操作相互独立，
                  底层服务判断何时可以进行输入/输出，然后进行相应回调，
                  开发者在回调中进行数据输入/输出处理。

2.3 MediaCodec Buffer与底层交互

MediaCodec Buffer与底层Acodec，以及OpenMAX标准的交互流程：

---

3.MediaCodec状态转换

3.1 MediaCodec的几种状态

MediaCodec有三种状态：Stopped、Executing、Released
其中Stopped与Executing状态又分别包含三个子状态

所以MediaCodec状态可以细分为如下：
1) 停止态(Stopped)：
      1.1) 未初始化状态（Uninitialized）
      1.2) 配置状态（Configured）
      1.3) 错误状态（Error）
2) 执行态(Executing)：
      2.1) 刷新状态（Flushed）
      2.2) 运行状态（ Running）
      2.3) 流结束状态（End-of-Stream）
3) 释放态(Released)

MediaCodec在不同的数据处理模式下状态间的转换会有些许差别，
接下来我们分别对同步模式和异步模式下的状态转换做一些分析

3.2 同步模式下的状态转换

官网示图：

 

1) createDecoderByType(...) / createEncoderByType(...) / createByCodecName(...)
调用三个方法中的任意一个创建一个MediaCodec对象实例后，
MediaCodec处于Stopped：Uninitialized子状态

2) MediaCodec.configure(...)配置，切换到Stopped：Configured子状态

3) MediaCodec.start()启动，切换到Executing：Flushed子状态。
MediaCodec此时拥有全部InputBuffer和OutputBuffers的所有权，Client无法操作这些Buffers，
但是MediaCodec在Flush状态下并不进行任何内部数据传送和编解码处理

4) MediaCodec.dequeueInputBuffer()请求到一个有效的InputBuffer Index, 第一个InputBuffer出队列时，
MediaCodec立即进入到了Executing：Running子状态

5) Executing：Running状态下，MediaCodec进行数据处理(解码、编码)工作，完成生命周期的主要阶段

6) MediaCodec.queueInputBuffer(... , MediaCodec.BUFFER_FLAG_END_OF_STREAM)被调用，输入端带有"End-Of-Stream"标记的InputBuffer加入InputBufferQueue，MediaCodec随即进入Executing：End of Stream子状态，且不再接受新的InputBuffer数据，
但是仍然会处理完之前InputBufferQueue中未处理的InputBuffer并产生OutputBuffer，直到"End-Of-Stream"标记到达输出端，数据处理的过程也随即终止

7) Executing状态下，MediaCodec.flush()，切换到Executing：Flushed子状态

8) Executing状态下，MediaCodec.stop()和MediaCodec.reset()，切换到Stopped：Uninitialized子状态

9) MediaCodec运行出错时会切换到Stopped：Error状态，可以调用MediaCodec.reset()进行重置，使其再次可用

10) MediaCodec数据处理任务完成或不再需要使用MediaCodec时，MediaCodec.release()方法释放其资源，MediaCodec切换到Released状态

3.3 异步模式下的状态转换

官网示图：

异步模式下状态转换与同步模式下大同小异，主要有两点区别：

1) MediaCodec.start()启动，会直接切换到Executing：Running子状态；

2) MediaCodec.flush()切换到Executing：Flushed子状态后，必须调用MediaCodec.start()才能切换回Executing：Running子状态。

其他情况下均与同步模式下相同，就不在此赘述

---

4.MediaCodec主要API和数据格式：

4.1 主要API：

编解码器创建和配置:
createDecoderByType()：根据特定mime类型(如"video/avc")创建编解码器(MediaCodec实例)
createEncoderBytype(): 同上
createByCodecName：根据组件的确切名称(如OMX.google.mp3.decoder)创建编解码器，使用MediaCodecList可以获取组件的名称
configure()：对编解码器进行配置，使编解码器切换到Stopped：Configured状态

常见的mime类型多媒体格式如下：
● “video/x-vnd.on2.vp8” - VP8 video (i.e. video in .webm)
● “video/x-vnd.on2.vp9” - VP9 video (i.e. video in .webm)
● “video/avc”                  - H.264/AVC video
● “video/mp4v-es”          - MPEG4 video
● “video/3gpp”                - H.263 video
● “audio/3gpp”                - AMR narrowband audio
● “audio/amr-wb”            - AMR wideband audio
● “audio/mpeg”               - MPEG1/2 audio layer III
● “audio/mp4a-latm”       - AAC audio (note, this is raw AAC packets, not packaged in LATM!)
● “audio/vorbis”              - vorbis audio
● “audio/g711-alaw”       - G.711 alaw audio
● “audio/g711-mlaw”      - G.711 ulaw audio

编解码器状态控制：
start()：编码器启动，切换到Executing：Flushed状态
stop()：编码器结束，返回到Stopped：Uninitialized状态
release()：释放实例资源

Surface创建和配置：
createInputSurface()：创建输入缓冲Surface
setOutputSurface()：设置输出缓冲Surface

Buffer操作：
getInputBuffers()：获取InputBufferQueue，返回ByteBuffer[ ]
dequeueInputBuffer()：从InputBufferQueue中取InputBuffer
queueInputBuffer()：Client往InputBuffer写入数据后，将InputBuffer加入到InputBufferQueue
getOutputBuffers()：获取OutputBufferQueue，返回ByteBuffer[ ]
dequeueOutputBuffer()：从OutputBufferQueue中取OutputBuffer
releaseOutputBuffer()：释放ByteBuffer数据

4.2 数据类型和载体

1) Mediacodecde的数据流有两种载体：ByteBuffer和Surface

    ● 使用ByteBuffer作为数据载体时，可以用Image类和getInput/OutputImage(int)获取原始视频帧

    ● 使用Surface来获取/呈现原始的视频数据时，Surface使用本地的视频Buffer，不需要进行ByteBuffers拷贝，编解码器的效率更高

    ● 通常在使用Surface的时候，无法访问原始的视频数据，但是可以使用ImageReader访问解码后的原始视频帧

2) Mediacodec接受三种数据类型：

2.1）压缩数据：
压缩数据可以作为解码器的输入、编码器的输出，
但是需要指定数据格式，这样MediaCodec才知道如何处理这些压缩数据.

压缩数据支持的格式有：
   ● MediaFormat.KEY_MIME支持的所有格式类型
   ● 对于视频类型，通常是一个单独的压缩视频帧
   ● 对于音频数据，通常是一个单独的访问单元

无论是视频还是音频，buffer都不会在任意字节边界上开始或结束，而是在帧/访问单元边界上开始或结束，除非它们被BUFFER_FLAG_PARTIAL_FRAME标记

2.2）原始音频数据：PCM音频数据帧

原始音频Buffer包含PCM音频数据的整个帧，这是每个通道按通道顺序的一个样本。
每个样本都是一个 AudioFormat#ENCODING_PCM_16BIT

2.3）原始视频数据：
在ByteBuffer模式下，视频buffer根据它们的MediaFormat#KEY_COLOR_FORMAT进行布局.
可以从getCodecInfo(). MediaCodecInfo.getCapabilitiesForType.CodecCapability.colorFormats获取支持的颜色格式。

视频编解码器支持三种颜色格式:   
   ● native raw video format：CodecCapabilities.COLOR_FormatSurface，
                                                  可以与输入/输出的Surface一起使用

   ● flexible YUV buffers：例如CodecCapabilities.COLOR_FormatYUV420Flexible，
                                           可以使用getInput/OutputImage(int)与输入/输出Surface一起使用，
                                           也可以在ByteBuffer模式下使用

   ● other,specific formats：通常只支持ByteBuffer模式；
                                               有些颜色格式是厂商特有的，其他定义在CodecCapabilities；
                                               对于等价于flexible格式的颜色格式，可以使用getInput/OutputImage(int)；

---

5.结语

MediaCodec的基本原理就先介绍到这里，本篇主要是理论讲解，先对MediaCodec的运用有个初步的认知，暂未涉及实践开发和Demo代码演示，后续博文会逐步跟进。

关于MediaCodec，网上优秀的资料和博文也很多，在学习MediaCodec过程中查阅了大量资料，
链接就不一一列举了，其中主要优秀博文链接有：

MediaCodec基本原理及使用_有心好书的博客-CSDN博客_mediacodecMediaCodec的使用介绍 - 简书
MediaCodec基础入门_Kayson12345的博客-CSDN博客
Android MediaExtractor + MediaCodec 实现简易播放器 - 简书
Android MediaCodec 状态(States)转换分析 - 二的次方 - 博客园