編碼分為硬編碼和軟編碼。

硬解碼：由顯卡核心GPU來對高清視頻進行解碼工作，CPU占用率很低，畫質效果比軟解碼略差一點，需要對播放器進行設置。

優點：播放流暢、低功耗

缺點：受視頻格式限制、功耗大、畫質沒有軟解碼好

軟解碼：由CPU負責解碼進行播放

優點：不受視頻格式限制、畫質略好于硬解

缺點：會占用過高的資源、對于高清視頻可能沒有硬解碼流暢(主要看CPU的能力)

下面我們具體說說硬解碼吧

蘋果在iOS 8.0系統之前，沒有開放系統的硬件編碼解碼功能，不過Mac OS系統一直有，被稱為Video ToolBox的框架來處理硬件的編碼和解碼，終于在iOS 8.0后，蘋果將該框架引入iOS系統。

由此，開發者便可以在iOS里面，調用Video Toolbox框架提供的接口，來對視頻進行硬件編解碼的工作，為VOIP視頻通話，視頻流播放等應用的視頻編解碼提供了便利。

（PS：按照蘋果WWDC2014 513《direct access to media encoding and decoding》的描述，蘋果之前提供的AVFoundation框架也使用硬件對視頻進行硬編碼和解碼，但是編碼后直接寫入文件，解碼后直接顯示。Video Toolbox框架可以得到編碼后的幀結構，也可以得到解碼后的原始圖像，因此具有更大的靈活性做一些視頻圖像處理。）

一，VideoToolbox基本數據結構。

Video Toolbox視頻編解碼前后需要應用的數據結構進行說明。

（1）CVPixelBuffer：編碼前和解碼后的圖像數據結構。

（2）CMTime、CMClock和CMTimebase：時間戳相關。時間以64-bit/32-bit的形式出現。

（3）CMBlockBuffer：編碼后，結果圖像的數據結構。

（4）CMVideoFormatDescription：圖像存儲方式，編解碼器等格式描述。

（5）CMSampleBuffer：存放編解碼前后的視頻圖像的容器數據結構。

圖1.1視頻H264編解碼前后數據結構示意圖

如圖1.1所示，編解碼前后的視頻圖像均封裝在CMSampleBuffer中，如果是編碼后的圖像，以CMBlockBuffe方式存儲；解碼后的圖像，以CVPixelBuffer存儲。CMSampleBuffer里面還有另外的時間信息CMTime和視頻描述信息CMVideoFormatDesc。

二，硬解碼使用方法。

通過如圖2.1所示的一個典型應用，來說明如何使用硬件解碼接口。該應用場景是從網絡處傳來H264編碼后的視頻碼流，最后顯示在手機屏幕上。

1，將H264碼流轉換成編碼前的CMSampleBuffer。

由圖1.1所示，解碼前的CMSampleBuffer = CMTime + FormatDesc + CMBlockBuffer。需要從H264的碼流里面提取出以上的三個信息。最后組合成CMSampleBuffer，提供給硬解碼接口來進行解碼工作。

H264的碼流由NALU單元組成，NALU單元包含視頻圖像數據和H264的參數信息。其中視頻圖像數據就是CMBlockBuffer，而H264的參數信息則可以組合成FormatDesc。具體來說參數信息包含SPS（Sequence Parameter Set）和PPS（Picture Parameter Set）。圖2.2顯示一個H264碼流的結構。

圖2.2 H264碼流結構

（1）提取sps和pps生成format description。

a，每個NALU的開始碼是0x00 00 01，按照開始碼定位NALU。

b，通過類型信息找到sps和pps并提取，開始碼后第一個byte的后5位，7代表sps，8代表pps。

c，CMVideoFormatDescriptionCreateFromH264ParameterSets函數來構建CMVideoFormatDescriptionRef。

（2）提取視頻圖像數據生成CMBlockBuffer。

a，通過開始碼，定位到NALU。

b，確定類型為數據后，將開始碼替換成NALU的長度信息（4 Bytes）。

c，CMBlockBufferCreateWithMemoryBlock接口構造CMBlockBufferRef。

（3）根據需要，生成CMTime信息。（實際測試時，加入time信息后，有不穩定的圖像，不加入time信息反而沒有，需要進一步研究，這里建議不加入time信息）

根據上述得到CMVideoFormatDescriptionRef、CMBlockBufferRef和可選的時間信息，使用CMSampleBufferCreate接口得到CMSampleBuffer數據這個待解碼的原始的數據。見下圖的H264數據轉換示意圖。