由于高清视频的分辨率远远高于一般格式视频，使得高清视频的码率非常高。再加上VC-1和H.264编码的压缩率很高，解码运算的运算量很大。因此常规地直接用CPU解码（即常说的“软解”）会极大地消耗CPU的运算能力，一些较老的CPU软解H.264时CPU占用率往往高达90％以上，更老的可能就放不动了。
“硬解”是硬件解码的简称。简单而言，硬件解码就是通过显卡的视频加速功能对高清视频进行解码。因此硬解能够将CPU从繁重的视频解码运算中释放出来，使电脑具备流畅播放高清视频的能力。显卡的GPU/VPU要比CPU更适合这类大数据量的、低难度的重复工作。视频解码工作从处理器那里分离出来，交给显卡去做，这就叫做“硬解码”，例如NVIDIA的PureVideo、AMD的UVD技术等等。与之对应的，以前那种纯粹依靠CPU来的方式则是“软解码”。不过受到技术条件的限制，纯粹的“硬解码”在现阶段是不存在的，CPU依然在发挥一部分作用，只不过硬解码时GPU/VPU已经成为运算的主力。
谁更“好”？
软解码是在显卡本身不支持或者部分不支持硬件解码的前提下，将解压高清编码的任务交给CPU，这是基于硬件配置本身达不到硬解压要求的前提下，属于一个折中的无奈之举。那这么说是不是软解压就一无是处了呢？不，这要是情况而定。对于一个不看、或者不经常看高清的用户而言，如果专门为很少用到的功能进行过多支出，那无疑是一种浪费；而在保证正常应用的前提下，还能在偶尔看一下高清的时候自己的电脑配置不至于播放不了，或者播放不流畅，那么这时候一颗性能不算太次的CPU就大有用武之地了，好在现在早已是双核，甚至多核CPU的时代，这个已经不是问题。总结软解码的好处，就是成本低廉，几乎不用二次投入，就可以享受高清带来的乐趣和震撼。
硬解码的优势是不言而喻的，一款支持VC-1、H.264和MPEG-2格式硬件加速的显卡或者集成显卡主板是高清爱好者的上佳选择。由于解压缩的任务基本全部交给了显示芯片，CPU就可以如释重负，轻松上阵，承担更多的其他任务，这尤其对于经常需要多任务运行的用户更为重要，如果让他们使用CPU负担解压任务的同时，再运行3个QQ、2个UC，运行BT、迅雷等一大堆任务，这将是一件不可想象的事情，但是如果换成硬解压方案，这又是一件很轻松的事情，看看吧，差别就是这么大。不过硬解压也并不都是优点，它也有缺憾的，比如硬件的支出，其余配置基本相同的前提下，就会比软解压方案多一些，这对于配置预算很有限的用户来说更是一个摆在面前的实际问题。另外，多了一块独立显卡，就会增加功耗，尤其是像GTX 280、HD 4870之类的高端显卡，动不动就是上百瓦，另外还要牵扯到电源的功率是否可以应付、机箱的散热是否能达到要求等等，这些都更增加了用户的整体预算。
列举了软解压和硬解压两者的优、劣，最终还是不好确定哪个好哪个坏，还是那句话，“适合的，就是最好的”。配机预算有限，只是偶尔欣赏一下高清的用户，使用软解压方案即可；而对于高清爱好者，同时兼顾大型3D游戏的用户，一款支持多种高清格式的主流显卡或者性能不算很弱的集成主板是他们的最终选择。
谁的播放效果更好？
由于硬件解码尤其是全程解码是新推出的技术，所以在大部分人心目中硬件解码要比软件解码先进，因此在自己显卡支持硬件解码的情况下会千方百计地开启硬件解码设置。其实硬解解码并不是必须的，因为硬件解码的出现是当CPU性能不足以应付视频解码需求时的一种解决方案，主要作用是降低CPU占用率，如果在CPU能流畅播放高清视频硬解的作用也就不明显了。这里有人可能会说降低CPU占有率可以降低能耗，硬解确实可以降低CPU功耗，但是显卡的功耗是会增加的，而且就目前情况来看，显卡的功耗已经大幅超过CPU了，所以靠硬解来降低系统能耗是不太可能的。也有很多人而觉得让CPU处于空闲比较好，但是CPU占有率高就是电脑的使用率高，不然买这么贵的CPU就没有必要了。
从使用角度来讲的硬件解码则有三大缺点，一是画面质量比不上软件解码，根据测试表明，软解码画面质量明显优于早期显卡的硬件解码，与最新最强显卡硬件解码播放高清相比也略占上风；二是硬件解码需要播放软件中设置，且对字幕等支持不好；三是早期支持硬解码的显卡还存在着各种各样的小毛病。当然随着技术进步这些问题可能会得到解决，但是到时CPU的性能也就更高了，软解高清的能力也许就像现在软解DVD一样了。比如现在的9600GT除了新增的“动态对比度增强”和“色彩增强”这两项视频优化技术之外，NVIDIA还提供了“去交织”、“反锯齿”和“降噪”等高清视频最重要的画面后期处理技术，并且支持双视频流解码性能超强，但是Intel Core i7 性能也令人咋舌，可以在没有任何缓存或预处理措施的情况下即时处理总容量达到200GB，合计像素数为224万亿的RAW格式照片，估计播放HDTV根本就是小菜一碟。
当然，硬件解码对CPU性能较差的人来说还是十分重要的。但是，并不是有硬件解码的显卡就一定要用的，在Core 2 Duo下使用MPlayer + CoreAVC播放高清时即使开启反交错等滤镜也可以流畅播放。在这种情况下其实并不需要硬解。是否需要使用硬解应该视情况而定，不需要一味求新，因为这些新的概念多数是硬件厂商的营销策略。
软解：兼容性好，适用更多平台，播放高清视频CPU负载大
硬解：与平台相关，播放高清视频更加清晰顺畅
区别点
我们在计算机上播放的视频文件都是经过压缩的，因为这样有利于节约存储空间；那么在播放过程，就需要进行一个反射的解压缩过程。在以前这项工作都是由ＣＰＵ来完成的，对于普通分辨率的ＡＶＩ、ＲＭＶＢ等文件，绝大多数的ＣＰＵ都可以胜任；但是发展到高清视频（１０８０i／p）之后，数据解压缩的工作量比以前翻了数倍，这让很多处理器叫苦不迭。
随着技术的发展，工程师们发现显卡的ＧＰＵ／ＶＰＵ要比ＣＰＵ更适合这类大数据量的、低难度的重复工作。视频解码工作从处理器那里分离出来，交给显卡去做，这就叫做“硬解码”，例如ＮＶＤＩＡ的PureVideo、ＡＭＤ的ＵＶＤ技术等等；与之对应的，以前那种纯粹依靠ＣＰＵ来讲稿的方式则是“软解码”。不过受到技术条件的限制，纯粹的“硬解码”在现阶段是不存在的，ＣＰＵ依然在发挥一部分作用，只不过硬解码时ＧＰＵ／ＶＰＵ已经成为运算的主力。
- 软解码和硬解码的区别
- 软编码：使用CPU进行编码
- 硬编码：使用非CPU进行编码，如显卡GPU、专用的DSP、FPGA、ASIC芯片等
- 软编码和硬编码比较
- 软编码：实现直接、简单，参数调整方便，升级易，但CPU负载重，性能较硬编码低，低码率下质量通常比硬编码要好一点。
- 硬编码：性能高，低码率下通常质量低于软编码器，但部分产品在GPU硬件平台移植了优秀的软编码算法（如X264）的，质量基本等同于软编码。
- 目前的主流GPU加速平台
- 目前主流的GPU平台开发框架
- CUDA：NVIDIA的封闭编程框架，通过框架可以调用GPU计算资源
- AMD APP：AMD为自己的GPU提出的一套通用并行编程框架，标准开放，通过在CPU、GPU同时支持OpenCL框架，进行计算力融合。
- OpenCL：开放计算语言，为异构平台编写程序的该框架，异构平台可包含CPU、GPU以及其他计算处理器，目标是使相同的运算能支持不同平台硬件加速。
- Inel QuickSync：集成于Intel显卡中的专用视频编解码模块。
从iOS8开始，可能是苹果想通了，开放了硬解码和硬编码API，就是名为 VideoToolbox.framework的API，需要用iOS 8以后才能使用，iOS 7.x上还不行。
这套硬解码API是几个纯C函数，在任何OC或者 C++代码里都可以使用。
首先要把 VideoToolbox.framework 添加到工程里，并且包含以下头文件。
#include <VideoToolbox/VideoToolbox.h>
解码主要需要以下三个函数
VTDecompressionSessionCreate 创建解码 session
VTDecompressionSessionDecodeFrame 解码一个frame
VTDecompressionSessionInvalidate 销毁解码 session
首先要创建 decode session，方法如下：
OSStatus status = VTDecompressionSessionCreate(kCFAllocatorDefault,
decoderFormatDescription,
NULL, attrs,
&callBackRecord,
&deocderSession);
其中 decoderFormatDescription 是 CMVideoFormatDescriptionRef 类型的视频格式描述，这个需要用H.264的 sps 和 pps数据来创建，调用以下函数创建 decoderFormatDescription
CMVideoFormatDescriptionCreateFromH264ParameterSets
需要注意的是，这里用的 sps和pps数据是不包含“00 00 00 01”的start code的。
attr是传递给decode session的属性词典
CFDictionaryRef attrs = NULL;
const void *keys[] = { kCVPixelBufferPixelFormatTypeKey };
// kCVPixelFormatType_420YpCbCr8Planar is YUV420
// kCVPixelFormatType_420YpCbCr8BiPlanarFullRange is NV12
uint32_t v = kCVPixelFormatType_420YpCbCr8BiPlanarFullRange;
const void *values[] = { CFNumberCreate(NULL, kCFNumberSInt32Type, &v) };
attrs = CFDictionaryCreate(NULL, keys, values, 1, NULL, NULL);
其中重要的属性就一个，kCVPixelBufferPixelFormatTypeKey，指定解码后的图像格式，必须指定成NV12，苹果的硬解码器只支持NV12。
callBackRecord 是用来指定回调函数的，解码器支持异步模式，解码后会调用这里的回调函数。
如果 decoderSession创建成功就可以开始解码了。
VTDecodeFrameFlags flags = 0;
//kVTDecodeFrame_EnableTemporalProcessing | kVTDecodeFrame_EnableAsynchronousDecompression;
VTDecodeInfoFlags flagOut = 0;
CVPixelBufferRef outputPixelBuffer = NULL;
OSStatus decodeStatus = VTDecompressionSessionDecodeFrame(deocderSession,
sampleBuffer,
flags,
&outputPixelBuffer,
&flagOut);
其中 flags 用0 表示使用同步解码，这样比较简单。
其中 sampleBuffer是输入的H.264视频数据，每次输入一个frame。
先用CMBlockBufferCreateWithMemoryBlock 从H.264数据创建一个CMBlockBufferRef实例。
然后用 CMSampleBufferCreateReady创建CMSampleBufferRef实例。
这里要注意的是，传入的H.264数据需要Mp4风格的，就是开始的四个字节是数据的长度而不是“00 00 00 01”的start code，四个字节的长度是big-endian的。
一般来说从 视频里读出的数据都是 “00 00 00 01”开头的，这里需要自己转换下。
解码成功之后，outputPixelBuffer里就是一帧 NV12格式的YUV图像了。
如果想获取YUV的数据可以通过
CVPixelBufferLockBaseAddress(outputPixelBuffer, 0);
void *baseAddress = CVPixelBufferGetBaseAddress(outputPixelBuffer);
获得图像数据的指针，需要说明baseAddress并不是指向YUV数据，而是指向一个CVPlanarPixelBufferInfo_YCbCrBiPlanar结构体，结构体里记录了两个plane的offset和pitch。
但是如果想把视频播放出来是不需要去读取YUV数据的，因为CVPixelBufferRef是可以直接转换成OpenGL的Texture或者UIImage的。
调用CVOpenGLESTextureCacheCreateTextureFromImage，可以直接创建OpenGL Texture
从 CVPixelBufferRef 创建 UIImage
CIImage *ciImage = [CIImage imageWithCVPixelBuffer:pixelBuffer];
UIImage *uiImage = [UIImage imageWithCIImage:ciImage];
解码完成后销毁 decoder session
VTDecompressionSessionInvalidate(deocderSession)
硬解码的基本流程就是这样了，如果需要成功解码播放视频还需要一些H.264视频格式，YUV图像格式，OpenGL等基础知识。
还是有很多小细节要处理的，无法在这里一一说明了，有人有问题可以在评论里讨论。
从解码到播放，大约1000行代码左右，主要是OpenGL渲染的代码比较多。
苹果官方的示例代码：
WWDC - Apple Developer
苹果的例子下载链接实效了，我也找不到那个例子，我自己写了一个。
stevenyao/iOSHardwareDecoder · GitHub
