引言
调用系统 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 提供两个属性
kVTCompressionPropertyKey_MaxKeyFrameInterval帧率控制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 左右导致画面模糊。
原因
- 帧率不稳定时会影响码率；
- 帧率稳定，但帧携带的 pts 时间戳是不稳定的（由于丢帧补帧逻辑，导致 pts 会有问题，比如：重复、甚至回退），依然会导致码率低；
方案
丢帧、补帧逻辑解耦，pts 不依赖录屏出帧和丢帧、补帧逻辑，直接编码器获取当前的时间戳传入编码器。
总结
通过对这篇文章的阅读，相信大家对编码的基本概念、iOS VT 硬编的使用、实际工作中可能遇到的难题都有一定的了解了，如果大家有更多的问题或者经验欢迎留言交流。
ios
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。