目录:

  (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 释放硬件缓冲区,该缓冲区提供一个选择:输出或者不输出到屏幕。

                                   

Android 软硬解 软解硬解有什么区别_Android

        

          此示例代码使用 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 软硬解 软解硬解有什么区别_移动开发_02

          有关详细代码,请参阅 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多媒体软件生态系统。