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(译文)
        
          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 MediaPlayer 和 MediaCodec 的区别和联系(一)
          有关详细代码,请参阅 Android 源码中的 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 MediaPlayer 和 MediaCodec 的区别和联系(一)
          有关详细代码,请参阅 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多媒体软件生态系统。
 
  三、参考链接
上一篇:zoj 3706 Break Standard Weight(dp)


下一篇:MRC BlOCK ARC