Android MediaPlayer 和 MediaCodec 的区别和联系（一）

目录：

　　（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（译文）

        　　原文链接：https://software.intel.com/en-us/android/articles/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的函数调用流程

        　　函数调用流程非常简单，请参照下图。配置完成后，开发人员使用 dequeueInputBuffer 获取硬件缓冲区ID。将解码原始缓冲区复制到输入队列后，使用 queueInputBuffer 使硬件编解码器执行解码功能。开发人员使用 dequeueOutputBuffer 获取解码缓冲区，然后使用 releaseOutputBuffer 释放硬件缓冲区，该缓冲区提供一个选择：输出或者不输出到屏幕。

   　　                              

        　　有关详细代码，请参阅 Android 源码中的 DecoderTest.java：

        　　http://androidxref.com/4.4.2_r1/xref/cts/tests/tests/media/src/android/media/cts/DecoderTest.java

 

        　　此示例代码使用 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 

        　　新的 InputSurface 和 OutputSurface 包含在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多媒体软件生态系统。

 

　　三、参考链接

                       https://blog.csdn.net/u010072711/article/details/52413766

                       https://baike.baidu.com/item/%E7%A1%AC%E4%BB%B6%E8%A7%A3%E7%A0%81

                       https://blog.csdn.net/biezhihua/article/details/53119327

                       https://software.intel.com/en-us/android/articles/android-hardware-codec-mediacodec

 

转载于:https://www.cnblogs.com/nmj1986/p/9288674.html