iOS VideoToolbox 硬编指南

Posted 2023-03-29 字节跳动视频云技术团队

引言

调用系统 VideoToolbox 的 API 实现一个硬编很容易，仔细看看文档、了解 API 的使用实现一个基本功能相信难不倒大家。但实际工作中有许多细节，一不注意就会掉坑里，甚至有些系统性问题难以解决。本文一方面会介绍必备的基础知识，带大家对编码有一个基本的认识，另一方面也会分享直播 SDK 在 VT 硬编实现上遇到的问题和解决方案，希望能帮助到大家。

必备基础知识

帧概念

• I 帧（帧内编码图像帧）即帧内（Intra）图像，采用帧内编码，不参考其它图像，但可作为其它类型图像的参考帧。

• P 帧（预测编码图像帧）即预测（Predicted）图像，采用帧间编码，参考前一幅 I 或 P 图像，用作运动补偿。

• B 帧（双向预测编码图像帧）即双向预测（Bi-predicted）图像，提供最高的压缩比，它既需要之前的图像帧( I 帧或 P 帧)，也需要后来的图像帧( P 帧)，采用运动预测的方式进行帧间双向预测编码。

时间戳

• PTS：显示时间戳，主要用于视频的同步和输出，在渲染的时候使用，在没有 B frame 的情况下 DTS 和 PTS 的输出顺序是一样的。

• DTS：解码时间戳，主要用于视频的解码，在解码阶段使用。

• CTS = PTS - DTS。

示例：

gop	I	B	B	P	B	B	P
显示顺序	1	2	3	4	5	6	7
解码顺序	1	3	4	2	6	7	5
PTS	1	2	3	4	5	6	7
DTS	1	3	4	2	6	7	5

GOP & Reference

GOP：一段时间内图像变化不大的图像集我们就可以称之为一个序列，gop 就是一组视频帧，其中第一个 I 帧我们称为是 IDR 帧。

Reference：参考周期，指两个 P 帧之间的距离，iOS 硬件编码器中无法指定。

IDR

一个 GOP 的第一个帧称 IDR 帧（立即刷新帧），IDR 帧的作用是立刻刷新，使错误不致传播。从 IDR 帧开始, 重新算一个新的序列开始编码。而 I 帧不具有随机访问的能力，这个功能是由 IDR 承担。IDR 帧会导致 DPB (DecodedPictureBuffer 参考帧列表——这是关键所在）清空，而 I 不会。

IDR 帧一定是 I 图像，但 I 帧不一定是 IDR 图像。一个序列中可以有很多的 I 帧图像，I 帧图像之后的图像可以引用 I 帧图像之间的图像做运动参考。

码率控制

• ABR：平均目标码率，简单场景分配较低 bit，复杂场景分配足够 bit，使得有限的 bit 数能够在不同场景下合理分配，这类似 VBR。同时一定时间内，平均码率又接近设置的目标码率，这样可以控制输出文件的大小，这又类似 CBR。可以认为是 CBR 和 VBR 的折中方案，这是大多数人的选择。特别在对质量和视频带宽都有要求的情况下，可以优先选择该模式，一般速度是 VBR 的两倍到三倍，相同体积的视频文件质量却比 CBR 好很多。

  • 适用场景：ABR 在直播和低延时系统用的比较多，因为只编码了一次，所以速度快，同时兼顾了视频质量和带宽,对于转码速度有要求的情况下也可以选择该模式。
  • 特点：视频质量整体可控，同时兼顾了视频码率和速度，是一个折中方案，实际用的比较多；使用过程一般要让调用方设置，最低码率、最高码率和平均码率，这些值要尽可能设置合理点。

• VBR：（Variable Bit Rate）可变码率，简单场景分配比较大的 QP，压缩率小，质量高。复杂场景分配较小 QP。得到基本稳定的视觉质量，因为人眼本来就对复杂场景不敏感，缺点在于输出码率大小不可控。

  • 适用场景：VBR 适用于那些对带宽和编码速度不太限制，但是对质量有很高要求的场景。特别是在运动的复杂场景下也可以保持比较高的清晰度且输出质量比较稳定，适合对延时不敏感的点播，录播或者存储系统。
  • 特点：码率不稳定，质量基本稳定且非常高；编码速度一般比较慢，点播、下载和存储系统可以优先使用，不适合低延时、直播系统；这种模型完全不考虑输出的视频带宽，为了质量，需要多少码率就占用多少，也不太考虑编码速度。

• CBR：（Constant Bit Rate）恒定码率，一定时间范围内比特率基本保持的恒定，属于码率优先模型。

  • 适用场景：一般也不建议使用这种方式，虽然输出的码率总是处于一个稳定值，但是质量不稳定，不能充分有效利用网络带宽，因为这种模型不考虑视频内容的复杂性，把所有视频帧的内容统一对待。但是有些编码软件只支持固定质量或者固定码率方式，有时不得不用。用的时候在允许的带宽范围内尽可能把带宽设置大点，以防止复杂运动场景下视频质量很低，如果设置的不合理，在运动场景下直接就糊了。
  • 特点：码率稳定，但是质量不稳定，带宽有效利用率不高，特别当该值设置不合理，在复杂运动场景下，画面非常模糊，非常影响观看体验。

编码数据裸流

H264 的码流结构它主要有两种格式：Annex B 和 AVCC。Annex B 格式以 0x000001 或 0x00000001 开头，AVCC 格式以所在的 NALU 的长度开头，以 Annex B 为例。

但对于一个 H.264 裸流来说，就是一系列 NALU 的集合 ，每个 NALU 既可以表示图像数据，也可以表示处理图像所需要的参数数据。

NALU结构分为视频编码层（VCL）和网络适配层（NAL）:

视频编码层（ VCL 即 Video Coding Layer） :负责高效的视频内容表示,这是核心算法引擎，其中对宏块、片的处理都包含在这个层级上，它输出的数据是 SODB 。

网络适配层（ NAL 即 Network Abstraction Layer） :以网络所要求的恰当方式对数据进行打包和发送，比较简单，先报 VCL 吐出来的数据 SODB 进行字节对齐，形成 RBSP ，最后把 RBSP 数据前面加上 NAL 头则组成一个 NALU 单元。

NALU = NALU Header + RBSP

但严格来讲 NALU = NALU Header + EBSP，而 EBSP = 防竞争的 RBSP，H.264 规范规定，编码器吐出来的数据需要在每个 NALU 添加起始码：0x00 00 01或者0x00 00 00 01， 用来指示一个 NALU 的起始 ，0x000000 时，也可以表示当前 NALU 的结束，如果 NALU 内部存在 0x00 00 01 or 0x000000 时，就要通过插入一个新的字节 0x03 防竞争。

NALU Header = forbidden_bit(1bit) + nal_reference_bit(2 bits )（优先级）+ nal_unit_type(5 bits )（类型）

NALU类型：

NALU 的类型即 RBSP 可以承载的数据类型。

Nalu_Type	NALU内容	备注
0	未指定
1	非 IDR 图像编码的 slice	比如普通 I、P、B 帧
2	编码 slice 数据划分 A	2 类型时，只传递片中最重要的信息，如片头，片中宏块的预测模式等；一般不会用到；
3	编码 slice 数据划分 B	3 类型是只传输残差；一般不会用到；
4	编码 slice 数据划分C	4 时则只可以传输残差中的AC系数；一般不会用到；
5	IDR 图像中的编码 slice	IDR 帧，IDR 一定是 I 帧但是 I 帧不一定是 IDR 帧。
6	SEI 补充增强信息单元	可以存一些私有数据等；
7	SPS 序列参数集	SPS 对如标识符、帧数以及参考帧数目、解码图像尺寸和帧场模式等解码参数进行标识记录
8	PPS 图像参数集	PPS 对如熵编码类型、有效参考图像的数目和初始化等解码参数进行标志记录。
9	单元定界符	视频图像的边界
10	序列结束	表明下一图像为 IDR 图像
11	码流结束	表示该码流中已经没有图像
12	填充数据	哑元数据，用于填充字节
13-23	保留
24-31	未使用

VCL 输出的原始数据比特流 SODB 即 String Of Data Bits，其长度不一定是 8bit 的整数倍，为了凑成整数个字节，往往需要对 SODB 最后一个字节进行填充形成 RBSP， 最后一个不满 8bit 的字节第一 bit 位置 1 ，然后后面缺省的 bit 置 0 即可。

接着我们再从层次结构理解码率的构成

帧： 一副图像编码后的视频数据也叫做一帧，其中有 I 帧、B 帧、P 帧。

片： 一帧图像又可以划分为很多片，由一个片或者多个片组成。

宏块： 视频编码的最小处理单元，承载了视频的具体 YUV 信息，一片由一个或者多个宏块组成。

VideoToolbox

介绍一下 VideoToolBox 及关键接口的使用，如果对接口使用很清楚的同学可以直接跳过看提炼部分或后续章节。

使用说明

第一步：VTCompressionSessionCreate 创建视频编码器并设置编码器初始属性。

NSDictionary  *pixelBufferOptions = @ 
(NSString*) kCVPixelBufferPixelFormatTypeKey : @(cvPixelFormatTypeValue_), 
(NSString*) kCVPixelBufferWidthKey : @(frame_width_),
(NSString*) kCVPixelBufferHeightKey : @(frame_height_),
(NSString*) kCVPixelBufferOpenGLESCompatibilityKey : @YES,
(NSString*) kCVPixelBufferiosurfacePropertiesKey : @
;
            
CMVideoCodecType codecType = (avctx->codec_id == AVCodecID_H264 ? kCMVideoCodecType_H264: kCMVideoCodecType_ByteVC1);

err = VTCompressionSessionCreate(
kCFAllocatorDefault, //内存分配器，设置为默认分配
frame_width_, //pixel 的宽
frame_height_, //pixel 的高
codecType, //编码器类型（h264/h265）
encoderSpecifications,//指定必须使用特定的编码器.一般传NULL即可.video toolbox会自己选择
( __bridge CFDictionaryRef)pixelBufferOptions, //原始视频数据需要的属性，系统会根据这个创建一个pixel buffer pool 如传NULL将不会创建，可能会增加不必要的copy
NULL, //压缩后的内存分配器，固定传NULL
&compressionOutputCallback, //编码数据的输出回调
this , //传递的参数
&session//编码器session 对象
);
        
        if(err == noErr) 
            compressionSession_ = session;
            
            const int32_t v = gop_; // 4-second kfi
            
            CFNumberRef ref = CFNumberCreate(NULL, kCFNumberSInt32Type, &v);
//设置I帧间隔，目前是4
            err = VTSessionSetProperty(session, kVTCompressionPropertyKey_MaxKeyFrameInterval, ref);
            CFRelease(ref);
        
        
        if(err == noErr) 
            CFBooleanRef allowFrameReodering = avctx->has_b_frames ? kCFBooleanTrue : kCFBooleanFalse;
//为了对B帧进行编码，视频编码器必须对帧进行重新排序，默认为True。 将此设置为false可以防止帧重新排序。简单讲：用来设置是否编 B 帧，High profile 支持 B 帧，目前开启状态
            err = VTSessionSetProperty(session , kVTCompressionPropertyKey_AllowFrameReordering, allowFrameReodering);
        
        
        if(err == noErr && fps_ > 0) 
            const int fps = fps_;
            CFNumberRef ref = CFNumberCreate(NULL, kCFNumberSInt32Type, &fps);
//期望帧率，不用于控制帧率，只是作为提示提供给编码器，目前是15
            err = VTSessionSetProperty(session , kVTCompressionPropertyKey_ExpectedFrameRate, ref);
            CFRelease(ref);
        
        
        if(err == noErr) 
            const int v = bitrate_;
            CFNumberRef ref = CFNumberCreate(NULL, kCFNumberSInt32Type, &v);
//设置平均码率恒定（ABR）在一定的时间范围内达到设定的码率，但是局部码率峰值可以超过设定的码率
            err = VTSessionSetProperty(session, kVTCompressionPropertyKey_AverageBitRate, ref);
            CFRelease(ref);
    
            //kVTCompressionPropertyKey_DataRateLimits配置和输出B帧有冲突
            if (!avctx->has_b_frames) 
                if ( @available(iOS 8.2, *)) 
                    int v = bitrate_ * kLimitToAverageBitRateFactor / 8;
                    CFNumberRef bytes = CFNumberCreate(kCFAllocatorDefault, kCFNumberSInt32Type, &v); //字节数
                    v = 1; //1s
                    CFNumberRef duration = CFNumberCreate(kCFAllocatorDefault, kCFNumberSInt32Type, &v);
                    
                    CFMutableArrayRef limit = CFArrayCreateMutable(kCFAllocatorDefault, 2, &kCFTypeArrayCallBacks);
                    
                    CFArrayAppendValue(limit, bytes);
                    CFArrayAppendValue(limit, duration);
//用来设置硬性码率限制，实际做的就是设置码率的硬性限制是每秒码率不超过平均码率的 2 (kLimitToAverageBitRateFactor)倍                   
                    VTSessionSetProperty(session, kVTCompressionPropertyKey_DataRateLimits, limit);
                    CFRelease(bytes);
                    CFRelease(duration);
                    CFRelease(limit);
                
            

        
        
        if(err == noErr) 
//质量水平
// 1、Baseline Profile：基本画质。支持I/P 帧，只支持无交错（Progressive）和CAVLC； 
// 2、Extended profile：进阶画质。支持I/P/B/SP/SI 帧，只支持无交错（Progressive）和CAVLC；(用的少) 
// 3、Main profile：主流画质。提供I/P/B 帧，支持无交错（Progressive）和交错（Interlaced）， 也支持CAVLC 和CABAC 的支持； 
// 4、High profile：高级画质。在main Profile 的基础上增加了8x8内部预测、自定义量化、 无损视频编码和更多的YUV 格式；
            err = VTSessionSetProperty(session, kVTCompressionPropertyKey_ProfileLevel, profileLevel_string);
        
        
        if(err == noErr && !use_baseline_ && avctx->codec_id == AVCodecID_H264) 
//H.264压缩的熵编码模式。kVTH264EntropyMode_CAVLC(Context-based Adaptive Variable Length Coding) or kVTH264EntropyMode_CABAC(Context-based Adaptive Binary Arithmetic Coding)  CABAC通常以较高的计算开销为代价提供更好的压缩
            err = VTSessionSetProperty(session, kVTCompressionPropertyKey_H264EntropyMode, kVTH264EntropyMode_CABAC);
        
        
        if(err == noErr) 
//用来设置编码器的工作模式是实时还是离线
//实时:延迟更低，但压缩效率会差一些，要求实时性高的场景需要开启
//离线则编得慢些，延迟更大，但压缩效率会更高。本地录制视频文件可以使用离线模式
//目前是关闭状态
            err = VTSessionSetProperty(session, kVTCompressionPropertyKey_RealTime, enable_real_time_ ? kCFBooleanTrue : kCFBooleanFalse);
        
        
        if (err == noErr && avctx->has_b_frames) 
            if ( @available(iOS 12.0, *)) 
// 在一个GOP里面的某一帧在解码时要依赖于前一个GOP中的某一些帧，这种GOP结构叫做Open-GOP。一般码流里面含有B帧的时候才会出现Open-GOP，Open-GOP以一个或多个B帧开始，参考之前GOP的P帧和当前GOP的I帧
//我们通常用的是Close-GOP Close-GOP中的帧不可以参考其前后的其它GOP 一般以I帧开头
                err = VTSessionSetProperty(session, kVTCompressionPropertyKey_AllowOpenGOP, enable_open_gop_ ? kCFBooleanTrue : kCFBooleanFalse);
            
        
//准备编码        
        if(err == noErr) 
            err = VTCompressionSessionPrepareToEncodeFrames(session);
        

第二步：当视频数据来了以后，调用 VTCompressionSessionEncodeFrame 开始编码。

CMTime presentationTimeStamp = CMTimeMake(timestamp_ms, 1000);

CFDictionaryRef frameProperties = nullptr;
//强制产生I帧
if (forceKeyframe_) 
            CFTypeRef keys[] = kVTEncodeFrameOptionKey_ForceKeyFrame;
            CFTypeRef values[] = kCFBooleanTrue;
            frameProperties = CFDictionaryCreate(kCFAllocatorDefault, keys, values, 1, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
            forceKeyframe_ = false;

        
CMTime dur = CMTimeMake(1, fps_);
OSStatus status = VTCompressionSessionEncodeFrame(
session, //会话
pixelBuffer, //视频帧数据
presentationTimeStamp,//当前帧的pts
dur,//帧间隔时间
frameProperties,//帧的额外属性
nullptr,//固定设置nullptr
&flags//接受额外编码信息
);

第三步：处理编码后的输出回调数据。

static void compressionOutputCallback(void *outputCallbackRefCon,
                   void *sourceFrameRefCon,
                   OSStatus status,
                   VTEncodeInfoFlags infoFlags,
                   CMSampleBufferRef sampleBuffer) 

从编码器出来的数据从下面的 Callback 中拿到，系统为我们封装成了 CMSampleBufferRef ，我们要处理的数据都在其中，系统也很友好的提供了一些 get 方法方便我们获取想要的数据。

比如：

• 时间信息

CMTime dts = CMSampleBufferGetDecodeTimeStamp(sampleBuffer);
CMTime pts = CMSampleBufferGetPresentationTimeStamp(sampleBuffer);

• 参数信息

// 获取SPS信息 
size_t sparameterSetSize, sparameterSetCount; 
const uint8_t *sparameterSet; 
CMVideoFormatDescriptionGetH264ParameterSetAtIndex(format, 0, &sparameterSet, &sparameterSetSize, &sparameterSetCount, 0 );
 // 获取PPS信息 
 size_t pparameterSetSize, pparameterSetCount; 
 const uint8_t *pparameterSet; 
 CMVideoFormatDescriptionGetH264ParameterSetAtIndex(format, 1, &pparameterSet, &pparameterSetSize, &pparameterSetCount, 0 );

• 编码数据

CMBlockBufferRef block = CMSampleBufferGetDataBuffer(sampleBuffer);
char* bufferData;
size_t size;
CMBlockBufferGetDataPointer(block, 0, NULL, &size, &bufferData);

提炼总结

• iOS 11 系统开始对 H.265 的硬编硬解的支持。但是并不是所有的 iOS 设备升级到 iOS 11 都可以使用 H.265 的硬编/解功能，H.264 硬解最少需要 A9 芯片的 iPhone 6s/iPhone 6s Plus/iPhone SE，H.265 硬编则最少需要 A10 芯片的 iPhone 7/iPhone 7 Plus。

• 设置期望帧率，不用于控制帧率，只是作为提示提供给编码器，1s 输入多少帧就输出多少帧。

• iOS 硬编 H264不支持 opengop ,支持 opengop 的条件是：H265 + B 帧 + iOS12 系统，然而 iOS 编出的 I 帧都是 IDR 帧，因此 opengop 在 iOS 实际的设置中也没有起到作用，H265 也同样如此。

• kVTCompressionPropertyKey_DataRateLimits 配置和输出 B 帧有冲突，使用时需要注意，否则将编不出 B 帧。

• kVTCompressionPropertyKey_DataRateLimits 需要设置，否则 kVTCompressionPropertyKey_AverageBitRate 设置的码率不受控。

• 系统提供了 CMSampleBufferRef， CMSampleBufferRef = CMBlockBuffer + CMVideoFormateDesc + CMTime：

  • CMBlockBuffer 存放着 NALU 数据；
  • CMVideoFormateDesc 存放着 sps pps 信息；
  • CMTime 存放着 pts or dts 信息；

• 硬编出来的数据格式为 AVCC 格式，而自研 rtmp 库仅支持 AnnexB，所以我们需要做的是 AVCC 转 AnnexB。

避坑指南

属性设置失败

在设置编码器属性时，要充分考虑到属性与属性间的互斥性，以及属性与 h264\\h265 的互斥性，如果不清楚这些，你写的编码器代码可能会导致最终的不确定性 bug 出现。

其实这个在上面有也有提到，这里再次强调一遍，因为这类问题没什么难道可言但排除起来又可能耗时耗力。

• iOS 硬编 h264 不支持 opengop ,支持 opengop 的条件是：h265 + B 帧 + iOS12 系统；

• kVTCompressionPropertyKey_DataRateLimits 配置和输出 B 帧有冲突，使用时需要注意，否则将编不出 B 帧，且 kVTCompressionPropertyKey_DataRateLimits 在系统 8.2 及以上可用；

Gop不符合预期

我们知道控制 gop VT 提供两个属性

1. kVTCompressionPropertyKey_MaxKeyFrameInterval 帧率控制
2. kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration 时间间隔控制

起初用kVTCompressionPropertyKey_MaxKeyFrameInterval控制，当受到性能影响帧率不足预期帧率时 gop 自然也会受到一定影响，这也是影响gop的一个因素，后来我们引入kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration并想通过这两个共同控制 gop 行为，但最终的行为依然是不符合预期的，先看一下文档怎么说。

简单讲，文档告诉我们从一个关键帧到下一个关键帧的最长持续时间（秒）。默认为零，没有限制。当帧速率可变时，此属性特别有用。此 key 可以与kVTCompressionPropertyKey_MaxKeyFrameInterval一起设置，并且将强制执行这两个限制 - 每 X 帧或每 Y 秒需要一个关键帧，以先到者为准。

然而，当我们 fps 是 15， kVTCompressionPropertyKey_MaxKeyFrameInterval 设置 30 kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration设置 3.5s，按照文档理解 gop 间隔为 2s 帧率不过时也不会超过 3.5s，但我们发现 gop 是以 3.5s 生效的，并没有像文档中介绍的那样 comes first。

编码卡死

现象

编码器卡死问题一直以来是各个团队一个共性问题，目前看这类问题主要发生在多个编码器 session 共存的情况，一旦处理出现冲突就会卡住，怀疑是系统内部在等待共用的资源，而且这个问题可能存在于多种情况，目前我们还无法完全解决，这里可以提供一个主要路径的规避方案。

通过分析卡死的堆栈和用户行为情况，我们发现存在多个编码器 session 时卡死的概率会很高，当然并不是说多个 session 不被允许，通过模拟实验最终我们发现需要满足以下几个条件，卡死会必现：

• Encode Session A 和 Encode Session B 在不同的线程上被创建

• Encode Session A 的生命周期比 Encode Session B 长

• Encode Session A 创建后没有视频帧进行编码

• 当前没有问题，等再次启动 Session B 并编码时必现卡死

原因

定性为系统性问题

方案

确定要编码时再 create session，避开系统行为

码率编不上去

现象

在我们没有解决这个问题前，经常有线上用户反馈画面模糊的问题，跟过一些 case，共性是 h265 编码码率低，动态场景下码率 600 以下，静态场景甚至不到 100 都有可能，只能让用户重启手机解决问题。

后来我们进行了线下的测试找到了必现的手机，起初怀疑是跟系统版本和机型相关，尝试用相同机型和系统版本都没有复现，说明和系统版本、机型无关，接着我们用 WebRtc demo 进行测试发现输入 30 帧最终丢到了 5 帧，对比和我们使用方式的不同点在于 RealTime 的开启，而在直播 demo 上如果开启 RealTime 也会遇到丢帧问题，通过不断排查最终找到了解决方案。

原因

hevc 硬编时间戳的处理精度有 bug，时间戳绝对值太大，会导致编码码率上不去、开启 RealTime 编码器甚至会丢帧，而时间戳过大的原因跟开机时间有关，这也可以解释重启手机能恢复的原因。

方案

给编码器的 pts 去掉了最高位来避免该系统问题

录屏 h265 编码码率低

现象

录屏系统输出的帧率不稳定，动态时 60 帧、静态时 20 帧，静动态切换时帧率会很不稳定，业务会进行丢帧、补充逻辑，基于这个背景业务再放 h256 + 30 帧时会出现码率低到 900k 左右导致画面模糊。

原因

1. 帧率不稳定时会影响码率；

2. 帧率稳定，但帧携带的 pts 时间戳是不稳定的（由于丢帧补帧逻辑，导致 pts 会有问题，比如：重复、甚至回退），依然会导致码率低；

方案

丢帧、补帧逻辑解耦，pts 不依赖录屏出帧和丢帧、补帧逻辑，直接编码器获取当前的时间戳传入编码器。

总结

通过对这篇文章的阅读，相信大家对编码的基本概念、iOS VT 硬编的使用、实际工作中可能遇到的难题都有一定的了解了，如果大家有更多的问题或者经验欢迎留言交流。

参考文献

《音视频压缩：H264码流层次结构和NALU详解》（https://cloud.tencent.com/developer/article/1746993）

iOS硬编解码相关知识

参考技术A 实现直接、简单，参数调整方便，升级易，但CPU负载重，性能较硬编码低，低码率下质量通常比硬编码要好一点。

性能高，低码率下通常质量低于软编码器，但部分产品在GPU硬件平台移植了优秀的软编码算法（如X264）的，质量基本等同于软编码。

苹果在iOS 8.0系统之前，没有开放系统的硬件编码解码功能，不过Mac OS系统一直有，被称为Video ToolBox的框架来处理硬件的编码和解码，终于在iOS 8.0（即 WWDC 2014 513 ）后，苹果将该框架引入iOS系统。

H.264是新一代的编码标准，以高压缩高质量和支持多种网络的流媒体传输著称，在编码方面，我理解的理论依据是：参照一段时间内图像的统计结果表明，在相邻几幅图像画面中，一般有差别的像素只有10%以内的点,亮度差值变化不超过2%，而色度差值的变化只有1%以内。所以对于一段变化不大图像画面，我们可以先编码出一个完整的图像帧A，随后的B帧就不编码全部图像，只写入与A帧的差别，这样B帧的大小就只有完整帧的1/10或更小！B帧之后的C帧如果变化不大，我们可以继续以参考B的方式编码C帧，这样循环下去。这段图像我们称为一个序列（序列就是有相同特点的一段数据），当某个图像与之前的图像变化很大，无法参考前面的帧来生成，那我们就结束上一个序列，开始下一段序列，也就是对这个图像生成一个完整帧A1，随后的图像就参考A1生成，只写入与A1的差别内容。

需要注意的是：

一个序列的第一个图像叫做 IDR 图像（立即刷新图像），IDR 图像都是 I 帧图像。H.264 引入 IDR 图像是为了解码的重同步，当解码器解码到 IDR 图像时，立即将参考帧队列清空，将已解码的数据全部输出或抛弃，重新查找参数集，开始一个新的序列。这样，如果前一个序列出现重大错误，在这里可以获得重新同步的机会。IDR图像之后的图像永远不会使用IDR之前的图像的数据来解码。

一个序列就是一段内容差异不太大的图像编码后生成的一串数据流。当运动变化比较少时，一个序列可以很长，因为运动变化少就代表图像画面的内容变动很小，所以就可以编一个I帧，然后一直P帧、B帧了。当运动变化多时，可能一个序列就比较短了，比如就包含一个I帧和3、4个P帧。

I、B、P各帧是根据压缩算法的需要，是人为定义的,它们都是实实在在的物理帧。一般来说，I帧的压缩率是7（跟JPG差不多），P帧是20，B帧可以达到50。可见使用B帧能节省大量空间，节省出来的空间可以用来保存多一些I帧，这样在相同码率下，可以提供更好的画质。

说明：

I帧：红色；P帧：蓝色；B帧：绿色。

1、分组:把几帧图像分为一组(GOP，也就是一个序列),为防止运动变化,帧数不宜取多。

2、定义帧:将每组内各帧图像定义为三种类型,即I帧、B帧和P帧;

3、预测帧:以I帧做为基础帧,以I帧预测P帧,再由I帧和P帧预测B帧;

4、数据传输:最后将I帧数据与预测的差值信息进行存储和传输。

5、帧内（Intraframe）压缩也称为空间压缩（Spatial compression）。

当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息，这实际上与静态图像压缩类似。帧内一般采用有损压缩算法，由于帧内压缩是编码一个完整的图像，所以可以独立的解码、显示。帧内压缩一般达不到很高的压缩，跟编码jpeg差不多。

6、帧间（Interframe）压缩。

相邻几帧的数据有很大的相关性，或者说前后两帧信息变化很小的特点。也即连续的视频其相邻帧之间具有冗余信息,根据这一特性，压缩相邻帧之间的冗余量就可以进一步提高压缩量，减小压缩比。帧间压缩也称为时间压缩（Temporal compression），它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧差值（Frame differencing）算法是一种典型的时间压缩法，它通过比较本帧与相邻帧之间的差异，仅记录本帧与其相邻帧的差值，这样可以大大减少数据量。

7、有损（Lossy）压缩和无损（Lossy less）压缩。

无损压缩也即压缩前和解压缩后的数据完全一致。多数的无损压缩都采用RLE行程编码算法。

有损压缩意味着解压缩后的数据与压缩前的数据不一致。在压缩的过程中要丢失一些人眼和人耳所不敏感的图像或音频信息,而且丢失的信息不可恢复。几乎所有高压缩的算法都采用有损压缩,这样才能达到低数据率的目标。丢失的数据率与压缩比有关,压缩比越小，丢失的数据越多,解压缩后的效果一般越差。此外,某些有损压缩算法采用多次重复压缩的方式,这样还会引起额外的数据丢失。

DTS主要用于视频的解码,在解码阶段使用.

PTS主要用于视频的同步和输出.

在display的时候使用.在没有B frame的情况下.DTS和PTS的输出顺序是一样的。

下面给出一个GOP为15的例子,其解码的参照frame及其解码的顺序都在里面:

如上图：

I frame 的解码不依赖于任何的其它的帧.而p frame的解码则依赖于其前面的I frame或者P frame.B frame的解码则依赖于其前的最近的一个I frame或者P frame 及其后的最近的一个P frame.

在iOS中，与视频相关的Framework库有5个，从顶层开始分别是 AVKit -> AVFoundation -> VideoToolbox -> Core Media -> Core Video

其中VideoToolbox可以将视频解压到 CVPixelBuffer ,也可以压缩到 CMSampleBuffer 。
但是我们常用的是 CMSampleBuffer .

编码前和解码后的图像数据结构（未压缩光栅图像缓存区-Uncompressed Raster Image Buffer）

存放CVPixelBuffer

CFDictionary对象，可能包含了视频的宽高，像素格式类型（32RGBA, YCbCr420），是否可以用于OpenGL ES等相关信息

时间戳相关。时间以 64-big/32-bit形式出现。 分子是64-bit的时间值，分母是32-bit的时标(time scale)

时间戳相关。时间以 64-big/32-bit形式出现。 分子是64-bit的时间值，分母是32-bit的时标(time scale)。它封装了时间源，其中CMClockGetHostTimeClock()封装了mach_absolute_time()

时间戳相关。时间以 64-big/32-bit形式出现。CMClock上的控制视图。提供了时间的映射:CMTimebaseSetTime(timebase, kCMTimeZero); 速率控制:
CMTimebaseSetRate(timebase, 1.0);

编码后，结果图像的数据结构

编解码前后的视频图像均封装在CMSampleBuffer中，如果是编码后的图像，以CMBlockBuffe方式存储；解码后的图像，以CVPixelBuffer存储。

存放编解码前后的视频图像的容器数据结构。如图所示，编解码前后的视频图像均封装在CMSampleBuffer中，如果是编码后的图像，以CMBlockBuffer方式存储；解码后的图像，以CVPixelBuffer存储。CMSampleBuffer里面还有另外的时间信息CMTime和视频描述信息CMVideoFormatDesc。

实现步骤如下：

需要从H.264的码流里面提取出以上的三个信息。最后组合成CMSampleBuffer，提供给硬解码接口来进行解码工作。

在H.264的语法中，有一个最基础的层，叫做Network Abstraction Layer, 简称为NAL。H.264流数据正是由一系列的NAL单元(NAL Unit, 简称NAUL)组成的。

H264的码流由NALU单元组成,一个NALU可能包含有：

2)H.264属性合集-FormatDesc(包含 SPS和PPS),即流数据中，属性集合可能是这样的：

经过处理之后，在Format Description中则是：

需要注意的是：

要从基础的流数据将SPS和PPS转化为Format Desc中的话，需要调用 CMVideoFormatDescriptionCreateFromH264ParameterSets() 方法。

3)NALU header

对于流数据来说，一个NAUL的Header中，可能是0x00 00 01或者是0x00 00 00 01作为开头(两者都有可能，下面以0x00 00 01作为例子)。0x00 00 01因此被称为开始码(Start code).

总结以上知识，我们知道H264的码流由NALU单元组成，NALU单元包含视频图像数据和H264的参数信息。其中视频图像数据就是CMBlockBuffer，而H264的参数信息则可以组合成FormatDesc。具体来说参数信息包含SPS（Sequence Parameter Set）和PPS（Picture Parameter Set）.如下图显示了一个H.264码流结构：

（实际测试时，加入time信息后，有不稳定的图像，不加入time信息反而没有，需要进一步研究，这里建议不加入time信息）

根据上述得到CMVideoFormatDescriptionRef、CMBlockBufferRef和可选的时间信息，使用CMSampleBufferCreate接口得到CMSampleBuffer数据这个待解码的原始的数据。如下图所示的H264数据转换示意图。

显示的方式有两种：

1）、将CMSampleBuffers提供给系统的AVSampleBufferDisplayLayer 直接显示

使用方式和其它CALayer类似。该层内置了硬件解码功能，将原始的CMSampleBuffer解码后的图像直接显示在屏幕上面，非常的简单方便。

2）、利用OPenGL渲染

通过VTDecompression接口来，将CMSampleBuffer解码成图像，将图像通过UIImageView或者OpenGL上显示。

初始化VTDecompressionSession，设置解码器的相关信息。初始化信息需要CMSampleBuffer里面的FormatDescription，以及设置解码后图像的存储方式。demo里面设置的CGBitmap模式，使用RGB方式存放。编码后的图像经过解码后，会调用一个回调函数，将解码后的图像交个这个回调函数来进一步处理。我们就在这个回调里面，将解码后的图像发给control来显示，初始化的时候要将回调指针作为参数传给create接口函数。最后使用create接口对session来进行初始化。

上所述的回调函数可以完成CGBitmap图像转换成UIImage图像的处理，将图像通过队列发送到Control来进行显示处理。

调用VTDecompresSessionDecodeFrame接口进行解码操作。解码后的图像会交由以上两步骤设置的回调函数，来进一步的处理。

摄像头采集，iOS系统提供了AVCaptureSession来采集摄像头的图像数据。设定好session的采集解析度。再设定好input和output即可。output设定的时候，需要设置delegate和输出队列。在delegate方法，处理采集好的图像。

图像输出的格式，是未编码的CMSampleBuffer形式。

1）初始化VTCompressionSession

VTCompressionSession初始化的时候，一般需要给出width宽，height长，编码器类型kCMVideoCodecType_H264等。然后通过调用VTSessionSetProperty接口设置帧率等属性，demo里面提供了一些设置参考，测试的时候发现几乎没有什么影响，可能需要进一步调试。最后需要设定一个回调函数，这个回调是视频图像编码成功后调用。全部准备好后，使用VTCompressionSessionCreate创建session

2）提取摄像头采集的原始图像数据给VTCompressionSession来硬编码

摄像头采集后的图像是未编码的CMSampleBuffer形式，利用给定的接口函数CMSampleBufferGetImageBuffer从中提取出CVPixelBufferRef，使用硬编码接口VTCompressionSessionEncodeFrame来对该帧进行硬编码，编码成功后，会自动调用session初始化时设置的回调函数。

3）利用回调函数，将因编码成功的CMSampleBuffer转换成H264码流，通过网络传播。

相关资料传送：

iOS8系统H264视频硬件编解码说明

简单谈谈硬编码和软编码

I,P，B帧和PTS，DTS的关系