简介
MediaCodec是 Android media 基础框架的一部分，通常和 MediaExtractor, MediaSync, MediaMuxer, MediaCrypto, MediaDrm, Image, Surface和AudioTrack 一起使用。
MediaCodec_1.png
这张图描述了MediaCodec的整体工作流程，一般情况下，由客户端向MediaCodec申请一个空的输入ByteBuffer，进行数据填充，再将ByteBuffer发送给MediaCodec，MediaCodec会采用异步的方式处理这些输入的数据，并将处理后的数据填充到输出Buffer中，消费者取到输出Buffer进行消费后，需将缓冲区释放，返还给MediaCodec。
数据
数据载体模式：
-
ByteBuffer模式：3种数据类型都可使用ByteBuffer模式。这种模式下，通常可以使用Image类和getInput/OutputImage(int)获取原始视频帧，下面会具体列举到。
-
Surface模式：当处理原始视频数据时，应该考虑使用Surface，而不是ByteBuffer来作为数据载体，这样可以提高编解码器性能。因为，Surface使用的是更底层的视频缓冲区，而不是将数据映射或复制到ByteBuffer中，效率更高。这种模式下，可以使用ImageReader类来访问原始视频帧，并且它仍然比ByteBuffer模式高效。
数据类型：
1）压缩数据：作为解码器的输入数据或者编码器的输出数据
- 指定格式：通过MediaFormat.KEY_MIME来指定或获取格式，编解码器才知道如何处理这些数据。
- 视频数据：一般情况下，输入给解码器或从编码器得到的一个ByteBuffer，都会是完整的一帧数据。除非设置了BUFFER_FLAG_PARTIAL_FRAME标记，它表示了缓冲区只包含帧的一部分，解码器会对数据进行批处理，直到没有该标志的缓冲区出现，才开始解码。比如H264解码，必须将分割符和NALU单元作为一个完整的数据帧，传给解码器才能正确解码。
- 音频数据：音频的要求则要稍微宽松，一个ByteBuffer可能包含多个编码的音频访问单元。
2） 原始音频数据：ByteBuffer包含PCM音频数据的整个帧，这是每个声道按声道顺序的一个样本，每个PCM音频样本都是16位带符号整数或浮点数。格式为AudioFormat.ENCODING_PCM_16BIT才能做处理。
- 解码器输出：通过getOutputFormat()来获取MediaFormat
- 编码器输入：通过getInputFormat()来获取MediaFormat
获取音频采样数据的示例代码如下：
/**
* 根据声道获取采样数据
*/
short[] getSamplesForChannel(MediaCodec codec, int bufferId, int channelIx) {
//获取输出缓冲区
ByteBuffer outputBuffer = codec.getOutputBuffer(bufferId);
//获取音频编码格式
MediaFormat format = codec.getOutputFormat(bufferId);
//转换字节顺序和Short类型
ShortBuffer samples = outputBuffer.order(ByteOrder.nativeOrder()).asShortBuffer();
//获取声道数
int numChannels = format.getInteger(MediaFormat.KEY_CHANNEL_COUNT);
if (channelIx < 0 || channelIx >= numChannels) {
return null;
}
//获取存储采样数据
short[] res = new short[samples.remaining() / numChannels];
for (int i = 0; i < res.length; ++i) {
res[i] = samples.get(i * numChannels + channelIx);
}
return res;
}
3） 原始视频数据：在ByteBuffer模式下，视频缓冲区根据MediaFormat.KEY_COLOR_FORMAT来进行布局。通过getCodecInfo().getCapabilitiesForType().colorFormats可以获取到支持的颜色格式数组，它包含3种颜色格式：
-
native raw video format: KEY_COLOR_FORMAT为COLOR_FormatSurface，表示该数据将是GraphicBuffer元数据的引用，在OMX中(即软编解码)中，被称为OMX_COLOR_FormatAndroidOpaque，这类格式的数据可以作为Surface模式的输入和输出。
-
flexible YUV buffers：比如CodecCapabilities.COLOR_FormatYUV420Flexible，Surface模式和ByteBuffer模式2中模式，都可以作为输入和输出。
-
other, specific formats: 除了以上2种，只支持ByteBuffer模式，在MediaCodecInfo.CodecCapabilities中可以看到许多不同的格式，只要后缀为flexible类型的，如，CodecCapabilities.COLOR_FormatRGBFlexible， 都可以使用Image类的getInput/OutputImage(int)来获取原始视频帧。
Build.VERSION_CODES.LOLLIPOP_MR1（5.1）以后，编解码器都支持YUV420P
生命周期和状态
MediaCodec有3种状态：Stopped，Executing和Released，其中Stopped和Released又各自细分成3种子状态，如下图所示：
MediaCodec_4.png
1）Stopped：
- Uninitialized：当通过工厂方法了成功创建编解码器后，此时处于Uninitialized子状态
- Configured：通过configure方法配置编解码器，此时处于Configured子状态，接着，需要调用start方法来启动，让编解码器进入Executing状态的Flushed子状态，才能输入数据给编解码器处理
- Error：
2）Executing：
- Flushed：执行start方法后，此时处于Flushed子状态
- Running ：当第一个输入缓冲区被出队，编解码器便进入Running子状态，这意味着，大部分时间编解码器都处于此状态
- End-of-Stream：当给编解码器发送一个带有End-of-Stream标记的Buffer后，编解码器就切换为End-of-Stream子状态，此时，编解码器不再接收输入数据，但仍旧会继续输出，直到end-of-stream标记输出
3）Released：
- Released：Stopped和Executing都可切换至此状态，当使用编码器操作完成后，应该调用release方法，使编解码器进入此状态
状态重置：
- flush：在Executing状态下，调用flush方法，来使编解码器回到Flushed子状态
- stop：在Executing状态下，调用stop方法，使编解码器进入Uninitialized子状态，此时可以调用configure方法来重新配置，进入下一轮循环
- reset：在某些情况下，编解码器会出现异常，此时应该使用reset而不是stop方法，使编解码进入Uninitialized状态，事实上，reset可以在任何时候被调用，如果异常发生后，不准备重新使用编解码器，那应该调用release进行释放
创建
通过编解码器类型和编解码器名字2种方式，可以创建编解码器，它们分别对应以下工厂方法：
//根据编码器类型创建解码器
public static MediaCodec createEncoderByType(@NonNull String type)
//根据解码器类型创建解码器
public static MediaCodec createDecoderByType(@NonNull String type)
//根据编解码器名字创建编解码器
public static MediaCodec createByCodecName(@NonNull String name)
MediaFormat包含了许多类型，如下：
public final class MediaFormat {
。。。。。
//视频类型
public static final String MIMETYPE_VIDEO_VP8 = "video/x-vnd.on2.vp8";
public static final String MIMETYPE_VIDEO_VP9 = "video/x-vnd.on2.vp9";
public static final String MIMETYPE_VIDEO_AV1 = "video/av01";
public static final String MIMETYPE_VIDEO_AVC = "video/avc";
public static final String MIMETYPE_VIDEO_HEVC = "video/hevc";
//音频类型
public static final String MIMETYPE_AUDIO_AMR_NB = "audio/3gpp";
public static final String MIMETYPE_AUDIO_AMR_WB = "audio/amr-wb";
public static final String MIMETYPE_AUDIO_MPEG = "audio/mpeg";
public static final String MIMETYPE_AUDIO_AAC = "audio/mp4a-latm";
public static final String MIMETYPE_AUDIO_QCELP = "audio/qcelp";
public static final String MIMETYPE_AUDIO_VORBIS = "audio/vorbis";
public static final String MIMETYPE_AUDIO_OPUS = "audio/opus";
。。。。。
}
在创建解码器时，如果是本地文件或者网络流，可以配合使用MediaExtractor解封装器来做格式提取，如下：
//mTrackIndex为视频轨索引获取格式
MediaFormat decoderFormat = mediaExtractor.getTrackFormat(mTrackIndex);
//创建解码器
MediaCodec decoder = MediaCodec.createDecoderByType(decoderFormat.getString(MediaFormat.KEY_MIME));
在创建编码器时，可以直接指定期望的编码类型，如下：
//指定格式
MediaFormat encoderFormat = MediaFormat.createVideoFormat(MediaFormat.MIMETYPE_VIDEO_AVC, width, height);
//创建编码器
MediaCodec encoder = MediaCodec.createEncoderByType(encoderFormat.getString(MediaFormat.KEY_MIME));
以上是硬编解码器的创建，如果创建失败，可以通过指定软解码器名字来创建，如下：
//创建软解码器
MediaCodec decoder = MediaCodec.createByCodecName("OMX.google.h264.decoder");
//创建软编码器
MediaCodec encoder = MediaCodec.createByCodecName("OMX.google.h264.encoder");
通常，以"OMX.google."为前缀的名字，即为软编解码类型
初始化配置
void configure (MediaFormat format, Surface surface, MediaCrypto crypto, int flags)
void configure (MediaFormat format, Surface surface, int flags, MediaDescrambler descrambler)
-
MediaCrypto和MediaDescrambler：用于加解密处理，都是可空参数，如果不涉及加密和解密，它们没有区别，会执行同一个重载方法
-
flags：传入MediaCodec.CONFIGURE_FLAG_ENCODE时（它的值为1），用来指定创建编码器，奇怪的是MediaCodec没有定义一个类似MediaCodec.CONFIGURE_FLAG_DECODE的常量用于创建解码器，这里通常直接传入0来指定创建解码器
-
Surface：调用releaseOutputBuffer(int index, boolean render)方法将render设置为true，解码器会将输出数据渲染到此处指定的Surface，当Surface不再使用或显示时，缓冲区会自动释放给编解码器
以下为编解码配置的示例代码：
//解码器配置
decoder.configure(decoderFormat, new Surface(new SurfaceTexture(getTextureId())), null, 0);
decoder.start()
这里指定了解码器最终输出渲染的表面，用来输出到开辟好的纹理空间
//编码器配置
encoder.configure(encoderFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
Surface surface = encoder.createInputSurface()
encoder.start()
编码器创建的Surface只能用于硬件加速api的渲染输入，如OpenGL，这就是Surface模式的用法，比如编码器创建了自己的Surface，可以用来关联EGL做为编码器的数据输入，替代ByteBuffer输入方式。
还有另一种方式，也可以使用createPersistentInputSurface ()来创建Surface，其他的编码器随后可以调用setInputSurface(Surface)方法来继续使用这个Surface，但同一时间内，只能一个编解码器使用。
createInputSurface和setInputSurface方法必须在configure方法之后，start方法之前调用，否则抛IllegalStateException异常。
持久化表面必须使用createPersistentInputSurface创建，否则抛IllegalArgumentException异常。
特殊数据
某些格式如，AAC和MPEG4，H.264和H.265要求帧数据的前缀，包含设置数据或编解码器特定数据的缓冲区，如sps和pps。处理此类压缩格式时，必须在start方法之后且任何帧数据之前，将这些数据输送给编解码器。这类数据用BUFFER_FLAG_CODEC_CONFIG来做标记。
通常不使用ByteBuffer来直接提交，而是在configure方法时通过MediaFormat进行设置，它在start方法调用后，会直接提交给编解码器。编解码器同样会输出到输出缓冲区中，因此，在进行编码往Muxer写入数据时，携带BUFFER_FLAG_CODEC_CONFIG标记的数据不用再次写入，它应该通过MediaFormat传递给Muxer。
数据处理
1）同步方式：
系统版本5.0之前只能使用同步方式来处理，整个过程如开头的流程图所示，下面以解码流程为例：
/**
* 解封装
*/
private int drainExtractor(long timeoutUs) {
if (mIsExtractorEOS) return DRAIN_STATE_NONE;
int trackIndex = mExtractor.getSampleTrackIndex();
if (trackIndex >= 0 && trackIndex != mTrackIndex) {
return DRAIN_STATE_NONE;
}
//步骤1
int result = mDecoder.dequeueInputBuffer(timeoutUs);
if (result < 0) return DRAIN_STATE_NONE;
if (trackIndex < 0) {
mIsExtractorEOS = true;
mDecoder.queueInputBuffer(result, 0, 0, 0, MediaCodec.BUFFER_FLAG_END_OF_STREAM);
return DRAIN_STATE_NONE;
}
//步骤2
ByteBuffer buffer = mDecoder.getInputBuffer(result);
int sampleSize = mExtractor.readSampleData(buffer, 0);
boolean isKeyFrame = (mExtractor.getSampleFlags() & MediaExtractor.SAMPLE_FLAG_SYNC) != 0;
//步骤3
mDecoder.queueInputBuffer(result, 0, sampleSize, mExtractor.getSampleTime(), isKeyFrame ? MediaCodec.BUFFER_FLAG_KEY_FRAME : 0);
mExtractor.advance();
return DRAIN_STATE_CONSUMED;
}
步骤1：从解码器获取输入缓冲区的id
- timeoutUs == 0，立即返回
- timeoutUs < 0，无限期等待
- timeoutUs > 0，等待“timeoutUs”微秒超时
步骤2：根据缓冲id获取输入缓冲区
步骤3：将充满数据的输入缓冲求传递给解码器，最后的flags标记有几种类型
- BUFFER_FLAG_KEY_FRAME：是否关键帧
- BUFFER_FLAG_CODEC_CONFIG：是否sps和pps等特殊数据，通常应该用MediaFormat做传递
- BUFFER_FLAG_PARTIAL_FRAME：通常一个ByteBuffer包含一帧完整视频数据，除非指定该标志，出现该标记解码器会批量处理多个缓冲区，直到没有该标记出现，才进行解码，大多数情况下不会使用
- BUFFER_FLAG_END_OF_STREAM：结束输入数据给解码器，除非调用flush方法，否则不要再向编解码器输入缓冲区，可以在最后一个带有有效数据的缓冲区上加上此标记，也可以用一个空的缓冲区
来传递，此时的pts可为0
下面从解码器获取输出数据：
private int drainDecoder(long timeoutUs) throws InterruptedException {
if (mIsDecoderEOS) return DRAIN_STATE_NONE;
//1
int result = mDecoder.dequeueOutputBuffer(mBufferInfo, timeoutUs);
switch (result) {
case MediaCodec.INFO_TRY_AGAIN_LATER:
return DRAIN_STATE_NONE;
case MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED:
case MediaCodec.INFO_OUTPUT_FORMAT_CHANGED:
return DRAIN_STATE_SHOULD_RETRY_IMMEDIATELY;
}
//2
if ((mBufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0) {
mEncoder.signalEndOfInputStream();
mIsDecoderEOS = true;
mBufferInfo.size = 0;
}
//3
boolean doRender = (mBufferInfo.size > 0);
mDecoder.releaseOutputBuffer(result, doRender);
......
return DRAIN_STATE_CONSUMED;
}
步骤1：从解码器获取输出缓冲区和缓冲区信息，result返回缓冲区索引或常量值
- INFO_TRY_AGAIN_LATER：获取超时
- INFO_OUTPUT_BUFFERS_CHANGED：表明输出缓冲区数据已更改，在5.0前，此时用getOutputBuffers方法获取缓冲区数组，5.0后，此方式已过期，可以忽略
- INFO_OUTPUT_FORMAT_CHANGED：表明输出格式已更改，后续数据将采用新的格式，此时可以通过getOutputFormat方法来获取新的格式，随后如果不出现超时，通常开始返回正确的输出缓冲区索引
步骤2：接受到带有BUFFER_FLAG_END_OF_STREAM标记的缓冲区，表明所有解码数据已输出完成，不会再有输出，signalEndOfInputStream方法通知编码器输入结束
步骤3：使用完输出缓冲区后，调用releaseOutputBuffer释放回给解码器，doRender为true，则缓冲区的数据会渲染到在configure方法中配置的Surface
可以不立即queueinputbuffer/releaseOutputBuffer到编解码器，但持有input/outputbuffer可能会使编解码器停止工作，并且此行为取决于设备。 编解码器有可能在产生输出缓冲区之前暂停，直到所有未完成的缓冲区queueinputbuffer/releaseOutputBuffer。 因此，用户最好每次获得缓冲区后执行释放操作。
2）异步方式：
在系统版本5.0及以上增加了异步处理方式，同步方式仍可以使用，但官方推荐首选异步方式，它的流程状态和同步方式稍微有些不同，再调用start方法后，状态自动切换为Running子状态，并且在调用flush方法后，必须再次调用start使状态流转为Running状态，才能开始输入数据。
image.png
异步方式的代码示例如下：
MediaCodec codec = MediaCodec.createByCodecName(name);
MediaFormat mOutputFormat; // member variable
codec.setCallback(new MediaCodec.Callback() {
@Override
void onInputBufferAvailable(MediaCodec mc, int inputBufferId) {
ByteBuffer inputBuffer = codec.getInputBuffer(inputBufferId);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
@Override
void onOutputBufferAvailable(MediaCodec mc, int outputBufferId, …) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is equivalent to mOutputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
}
@Override
void onOutputFormatChanged(MediaCodec mc, MediaFormat format) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
mOutputFormat = format; // option B
}
@Override
void onError(…) {
…
}
});
codec.configure(format, …);
mOutputFormat = codec.getOutputFormat(); // option B
codec.start();
// wait for processing to complete
codec.stop();
codec.release();
setCallback方法必须在configure方法之前被调用，并且不应该再使用getInputBuffers，getOutputBuffers，dequeueInputBuffer和dequeueOutputBuffer方法。
最后
当编解码器使用Surface模式作为数据输入源或输出源时，对应的缓冲区无法访问：
-
输出源：使用输出Surface时，数据处理几乎与ByteBuffer模式相同。但是，输出缓冲区将不可访问，并表示为空值。例如，getOutputBuffer / Image（int）将返回null，getOutputBuffers将返回仅包含null的数组。
-
输入源：使用输入Surface时，没有可访问的输入缓冲区，因为缓冲区会自动从输入表面传递到编解码器。调用dequeueInputBuffer会抛出IllegalStateException，并且getInputBuffers返回一个不可写入的伪造ByteBuffer数组。调用signalEndOfInputStream以信号流结束后，输入表面将立即停止向编解码器提交数据。
网友评论