目录：
（1）概念解释 ： 硬解、软解
（2）Intel关于Android MediaCodec的相关说明
正文：
一、硬解、软解
（1）概念：
a、硬件解码：硬件解码是图形芯片厂商提出的用GPU资源解码视频流的方案
b、软件解码：相对于硬件解码，传统的软件解码是用CPU承担解码工作
（2）优点：
a、硬解：效率高、功耗低、热功耗低
b、软解：具备普遍适应性
（3）缺点：
a、硬解：（a）缺乏有力的支持（包括滤镜、字幕）、局限性较大（例如打开硬件解码后PC的节能方面的功能
失效cnq等）、设置较为复杂；
（b）需要硬件有硬件解码模块、相关的驱动配合、合适的播放软件以及对播放软件的正确设置，缺
一不可。否则无法开启硬件解码功能。
b、软解：主要靠算法解码，很耗费性能、耗电。
（4）示例（基于Android平台）：
a、硬解：Android自带播放器——VideoView
详述：
VideoView基于MediaPlayer（也是硬件解码）实现，但 MediaPlayer 封装的比较死，对于视频
编解码协议支持的较少。代表播放器：VideoView。
而 MediaCodec 则具备很高的拓展性，支持的协议较多，我们可以根据流
媒体的协议和设备硬件本身来自定义硬件解码。代表播放器：Google的 ExoPlayer。
b、软解：FFmpeg
详述：
FFmpeg官网： https://ffmpeg.org/
FFmpeg教程： 雷霄骅(leixiaohua1020)的专栏
基于FFmpeg的代表播放器：Bilibili 的 ijkplayer
二、Android* Hardware Codec — MediaCodec（译文）
Android有一个很棒的媒体库，为应用开发提供了无数的可能性。然而，直到最近，Android OS 还没有底层API用以直接编码和解码音频／视频，该底层API将几乎能使开发者创造任何东西。
幸运的是，最新的 Jelly Bean 发布了 Android.media.MediaCodec API。该API使用与 OpenMAX*（媒体行业中的著名标准）相同的原理和架构设计，有效地从纯粹的高级媒体播放器转换到低级编码器／解码器。
从 MediaPlayer 到 MediaCodec
Android自API level 1以来已包含 MediaPlayer。MediaPlayer提供了一种简单的方式来播放音频和视频。但是，它受限于它只提供三种媒体格式：MP4、3GPP 和 MKV（从Android 4.0开始）。为了播放不支持的格式，许多开发人员使用了FFmpeg软件解码器。
有一个x86二进制版本的FFmpeg可提供出色的性能。但是，包括 x86二进制文件 和 FFmpeg ARM* 二进制文件 都会产生一个很大的二进制镜像。
截至Android 4.1发布，MediaCodec为此问题提供了合理的解决方案。由于MediaCodec是使用 Java API 编写的，因此它允许接口访问底层系统编解码器，无论是硬件编解码器，还是结合音频编解码器，都是高度优化的软件编解码器。使用MediaCodec能获得合理性能优化并节省电量。
MediaCodec的函数调用流程
使硬件编解码器执行解码功能。开发人员使用 dequeueOutputBuffer 获取解码缓冲区，然后使用 releaseOutputBuffer 释放硬件缓冲区，该缓冲区提供一个选择：输出或者不输出到屏幕。
此示例代码使用 MediaExtractor 作为媒体格式解析器。由于 Android 支持的媒体格式有限，大多数开发人员使用 AVFormat（FFmpeg的一个组件）作为媒体格式解析器。MediaCodec的配置与此功能不同。开发人员需要使用MediaFormat.createVideoFormat来创建视频格式（如果使用MediaExtractor，则使用 getTrackFormat 来获取格式）。一些解码器（例如：H.264）需要额外的配置信息。可以使用 MediaFormat 或者 刷新帧 添加此信息。例如： H.264刷新帧是IDR帧，在该帧的报头中包括附加配置信息。
创建 H.264视频格式示例代码：
videoformat = MediaFormat.createVideoFormat(“video/avc”, width,height);
videoformat.setByteBuffer("csd-0", extra configure data);
将 OpenGL* 与 MediaCodec 一起使用
OpenGL被用来渲染 MediaCodec输出到屏幕。它在播放视频时添加一些视频特效也很有用。关键是 SurfaceTexture类。
SurfaceTexture包含在 API Level 15（Android 4.0.3）中。开发人员可以使用它将图像流式传输到给定的OpenGL纹理。因此，如果使用 SurfaceTexture配置 MediaCodec，输出缓冲区将被渲染到一个OpenGL纹理，而不是设备屏幕。因此，需要视频后处理。
开发人员需要添加 帧监听器（函数是setOnFrameAvailableListener）以获取图像更新消息，然后使用 updateTexImage 获取最新图像。OpenGL仅支持 RGB 颜色格式，但视频解码器的输出是 YUV 颜色格式，因此必须使用 GL_TEXTURE_EXTERNAL_OES 来支持 YUV 颜色格式。例如：要更改纹理类型，请使用函数 GLES20.glBindTexture(GL_TEXTURE_EXTERNAL_OES, textureId)。
请参阅 https://github.com/MasDennis/Rajawali/wiki/Tutorial-25-Video-Material 以获取有关如何将 SurfaceTexture 用于 MediaPlayer 的详细信息。MediaCodec使用相同的过程，因此，如果使用 SurfaceTexture 配置 MediaCodec，将实现相同的结果。
Support Pipeline on Android 4.3
包含在Android 4.3 中，在 InputSurface 和 OutputSurface 的帮助下，可以使用零拷贝完成代码转换管道，也就是说，所有解码视频内存都不会从GPU复制到CPU。编码器可以直接从管道获取内存处理程序。InputSurface 和 OutputSurface 将与当前的 OpenGL 环境绑定，而 OutputSurface 可以作为 SurfaceTexture 的一种“打包”。
工作流程如下：
有关详细代码，请参阅 Android 4.3源码中的 EncodeDecodeTest.java。资料来源： http://androidxref.com/4.3_r2.1/xref/cts/tests/tests/media/src/android/media/cts/EncodeDecodeTest.java
在英特尔®架构（IA）平台上使用MediaCodec时获得低延迟
在某些情况下，例如屏幕投影或云游戏，我们需要低延迟和高性能解码。使用硬件解码器，我们可以获得良好的性能，而用软件解码器的副作用即高延迟。
如果编码器为 H.264 ，则 MediaCodec 可能具有几帧的延迟（对于IA平台，它是7帧，而其他主或高配置上是3-5帧）。如果帧速率为30 FPS，则 7 帧将具有 200 毫秒的延迟。什么原因造成硬件解码器延迟？原因可能是主要或高配置文件具有B帧，并且如果解码器在B帧引用后续缓冲器时没有缓冲器，则播放将被阻止一小段时间。英特尔已经考虑了硬件解码器的这种情况，并为主要或高配置文件提供了7个缓冲区，但由于基线没有B帧，因此将其减少到零缓冲区用于基线。其他供应商可以为所有配置文件使用4个缓冲。
因此，在基于IA的Android平台上，解决方案是将编码器更改为基线配置文件。如果无法更改编码器配置文件，则可行的解决方法是更改解码器端的配置数据。通常，配置文件位于第五个字节，因此将基线配置文件更改为66将在IA平台上产生最低延迟。
结论
为IA平台编写Android媒体应用程序的开发人员应考虑使用本文所述的硬件解决方案，因为它在IA平台上表现最佳。 他们的客户将从强大的硬件中获得更多好处，反过来，这将为基于IA的Android设备构建一个h3多媒体软件生态系统。
