关于视频编码:iOS-VideoToolbox-硬编指南

引言

调用零碎 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 & 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 能够承载的数据类型。

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 详解》