硬解码和软解码

 硬解码和软解码

1.硬件解码就是通过显卡的视频加速功能对高清视频进行解码。

       因此硬解码能够将CPU从繁重的视频解码运算中释放出来，使播放设备具备流畅播放高清视频的能力。显卡的GPU/VPU要比CPU更适合这类大数据量的、低难度的重复工作。视频解码工作从处理器那里分离出来，交给显卡去做，这就叫做“硬解码”。

2.与之对应的，以前纯粹依靠CPU来解码的方式则是“软解码”。

软解码是在显卡本身不支持或者部分不支持硬件解码的前提下，将解压高清编码的任务交给CPU，这是基于硬件配置本身达不到硬解压要求的前提下，属于一个折中的无奈之举
        对于一个超级电视而言，观看高清电影无疑是用户最大的诉求，而硬解码的优势就在于可以流畅的支持1080p甚至4K清晰度的电影播放，而不需要占用CPU，CPU就可以如释重负，轻松上阵，承担更多的其他任务。如果通过软解码的方式播放高清电影，CPU的负担较重，往往会出现卡顿、不流畅的现象。

3.视频解码有四个步骤，分别是VLD(流处理)、iDCT(频率转换) 、MoComp(运动补偿)和PostProc(显示后处理，解码去块滤波Deblocking)。

       通常我们所说的硬件加速或硬件解码，就是指视频解码的这几个步骤中，用显卡专用的解码引擎替代CPU的软件计算，降低CPU的计算负荷。

显卡的硬件解码引擎

微软规定的显卡硬件加速标准为DXVA2.0(DirectX Video Acceleration)，它将显卡硬件加速级别从高到低划分为四个等级，顺序为：VLD>iDCT>MoComp>PostProc。主要包括和以上四个步骤对应的流处理(BitstreamProcessing CAVLC/CABAC,前后自适应可变长度编码、前后自适应二进制算数编码)、逆变换(InverseTransform)、运动补偿(MotionCompensation)、解码去块滤波(Deblocking)。其中VLD加速包含了全部四步，iDCT加速包含了MoComp和PostProc；MoComp加速包含了PostProc。而对H.264视频解码则加上了FGT(FilmGrain Technology，电影胶片质感技术)后分为A～F的六个等级，F级的硬解级别最高。

解码去块滤波影响画质

       其实，无论是硬件解码还是软件解码，所进行的解码过程和解码结果都是完全一样的。他们的区别就是视频解码的工作是由处理器完成，还是由显卡来完成而已。因此，在理论上硬件解码和软件解码的效果应该是完全一样的。但是，也的确有用户在开启和关闭硬解码之后发现明显的画质区别，这个关键在于最后一个解码步骤PostProc(显示后处理，解码去块滤波操作Deblocking)。Deblocking的意思为解码去块，能够消除H.264压缩编码可能产生的马赛克现象，真实地还原视频图像。Deblocking对处理器提出了较高的要求，早期的GeForce6/7或RadeonX1000显卡在开启显卡硬件加速的状态下就会关闭解码去块滤波操作Deblocking，这时播放一些影片会看到较明显的马赛克现象，明显影响画面质量。而在其它编码格式的高清视频中，则没有相关的问题。

        硬解码最大的优点就是速度非常快（与软解码相比较而言，在相同条件下），再有就是省电。软解码在解码工过程中要借助软件提供的算法来取指，分析，运算解码等工作，相对来讲速度就降下来了，还非常费电。在这里，我再举几个例子吧，比如说电脑中的独立显卡（具有各种的处理，控制芯片，当然还有显存）和集成显示芯片，他们都可以处理图像数据，但是在具有独立显卡的机器中，CPU把全部的图形处理工作都交给了专门的显卡去完成（硬件完成，里面也有微指令控制系统，如同Firmware），而没有独立显卡的PC机中，CPU将不可推卸地完成大部分的图形图像的处理任务（软件程序控制CPU完成）,显示芯片负责少量的处理以及输出。

补充：Android当中的视频编码的4中实现方式分析

在所有的Android平台上进行视频编码都是一件很痛苦的事情，即使到了Android4.3，这种
状况依然没有很大的改变。在Android当中我们很难找到一个效率高同时又免费的将视频编成
AVC/H.264格式。对于Android5.0还没有更细微的研究，所以我们现在暂时先分析
android 4.4以前当中Android各个版本当中的视频编码实现机制。
从Android诞生之日起，MediaRecorder的相关API就没有大的改变过，也就是说从Android1.0到
现在的Android4.3之间一直没有很实用的关于视频编码的API被添加。但是Google自己开发的视频
聊天App--Google Talk对视频编码的处理十分出色。所以如果我们仔细的浏览一下AOSP就会发现那些
用于支持Google Talk实现的关于视频编码的部分的代码(当然Google Talk本身是不开源的。但是
支持Google Talk实现的那部分代码是位于AOSP当中的)。

如果我们想要录制高质量的视频，那么我们就需要深入的了解Android内部提供的关于视频编码的
实现。我们将会分析Android当中提供的MediaRecorder, OMXCodec, MediaCodec, Software encoding
一共4种方式。

(1) MediaRecorder

在很长的一段时间内，我们在Android当中只能使用这个API来录制视频。简单又稳定。但是这个API
只支持对来自Camera preview的frame进行编码。也就说如果你的permission节点当中没有声明
使用camera的权限，你甚至都不能使用MediaRecorder的API。
然后在Android 4.0当中，Google引入了一个隐藏的API，就是GRALLOC_BUFFER.如果我们使用的
是原生的Android系统的话，在ICS版本当中的Camera程序当中一定体验过一个短暂的人脸渐变动画(short-lived
face morphing feature).这个功能的实现是基于一个Hidden API实现的。这个隐藏的API
允许我们可以对来自Surface的frame进行编码。这个API在Android 4.3当中仍然是隐藏的。
关于如何使用Hidden API，网络上又很多教程，其中最简单的办法就是通过reflection。
但是使用隐藏的API本身有点不太稳定，毕竟有的OEM厂商会将AOSP当中的Hidden API删除掉，
例如某粮食品牌手机。

(2) OMXCodec

这种办法的编码过程(encoding)没有解码(decoding)过程稳定，但是比起来MediaRecorder的GRALLOC_BUFFER
来说稳定多了。
使用这种解决办法比使用MediaRecorder要灵活的许多，你可以在stagefright当中同时使用多个
MediaWriter，或者使用自己重新定制的MediaWriter。
如果你想做一些关于视频流(video streaming)的处理或者生成一些特殊的视频容器(video containers)，
这个API将会特别好使用。

(3) MediaCodec

这个API是Android 4.1当中才引入的。在Android 4.3当中被优化和改进了一些。
他可以像GRALLOC_BUFFER那样直接提供从surface当中编码视频帧(encode video frame).Google可能会在
以后逐渐的见GRALLOC_BUFFER移除掉，或者deprecate掉。因为Google现在已经发布了具有同样功能的
MediaCodec，但是依然将GRALLOC_BUFFER设置成@hide.
所以如果你的程序的target platform是4.3的话，请优先使用这个api。但是缺点就是文档比较少，教程
也少。在一些特定的设备上甚至都会直接崩掉。
将编码过的帧(frame)封装到一个合适的视频容器(video container)当中是一个很困难的过程，但是直接使用
MediaMutex提供的API功能又十分有限。
在Android 4.1+以上的平台上，MediaCodec需要不同的颜色格式(color formats)作为输入缓冲区(input buffer),
MediaCodec的性能还是很高的，但是没有MediaRecorder稳定，在某些特定的设备上和定制的ROM上会崩掉。

(4) Software encoding

以上提到的三种方法都是基于硬件的编码。软编码的方式相对来说就是更稳定，同时移植性也更好。当然
唯一的缺点就是太难了。还有一个致命的缺点就是跟硬编码相比太慢了，尤其是软编码720P以及以上的视频时，
基本上就挂了。
所以我们在这里也就是提提，当然如果你足够土壕可以购买商业的解决办法，真的是很贵。

所以说还是要多看源代码，即使我们不做系统级的开发，但是我们会将会经常发现SDK当中提供的API并不能
直接解决我们遇到的需求，不是性能达不到，就是干脆解决不了问题。所以我们需要仔细的查看AOSP的代码，
然后查看里面的实现，有一些Hidden API会解决我们的问题。或者查看他们的实现，然后自己单独的移植
出来都可以帮助我们解决问题。
以上只是从理论上进行粗略的分析。并没有提供详细的代码和实现方面的方向。所以我只是提供一个大致的方向。
可以顺着这个方向查看源代码，或者直接Google。
希望以上的文章能对你有所帮助。