调用系统 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:一段时间内图像变化不大的图像集我们就可以称之为一个序列,gop 就是一组视频帧,其中第一个 I 帧我们称为是 IDR 帧。
Reference:参考周期,指两个 P 帧之间的距离,iOS 硬件编码器中无法指定。
一个 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 好很多。
VBR:(Variable Bit Rate)可变码率,简单场景分配比较大的 QP,压缩率小,质量高。复杂场景分配较小 QP。得到基本稳定的视觉质量,因为人眼本来就对复杂场景不敏感,缺点在于输出码率大小不可控。
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 及关键接口的使用,如果对接口使用很清楚的同学可以直接跳过看提炼部分或后续章节。
第一步: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);
系统提供了 CMSampleBufferRef, CMSampleBufferRef = CMBlockBuffer + CMVideoFormateDesc + CMTime:
在设置编码器属性时,要充分考虑到属性与属性间的互斥性,以及属性与 h264\h265 的互斥性,如果不清楚这些,你写的编码器代码可能会导致最终的不确定性 bug 出现。
其实这个在上面有也有提到,这里再次强调一遍,因为这类问题没什么难道可言但排除起来又可能耗时耗力。
我们知道控制 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 不被允许,通过模拟实验最终我们发现需要满足以下几个条件,卡死会必现:
定性为系统性问题
确定要编码时再 create session,避开系统行为
在我们没有解决这个问题前,经常有线上用户反馈画面模糊的问题,跟过一些 case,共性是 h265 编码码率低,动态场景下码率 600 以下,静态场景甚至不到 100 都有可能,只能让用户重启手机解决问题。
后来我们进行了线下的测试找到了必现的手机,起初怀疑是跟系统版本和机型相关,尝试用相同机型和系统版本都没有复现,说明和系统版本、机型无关,接着我们用 WebRtc demo 进行测试发现输入 30 帧最终丢到了 5 帧,对比和我们使用方式的不同点在于 RealTime 的开启,而在直播 demo 上如果开启 RealTime 也会遇到丢帧问题,通过不断排查最终找到了解决方案。
hevc 硬编时间戳的处理精度有 bug,时间戳绝对值太大,会导致编码码率上不去、开启 RealTime 编码器甚至会丢帧,而时间戳过大的原因跟开机时间有关,这也可以解释重启手机能恢复的原因。
给编码器的 pts 去掉了最高位来避免该系统问题
录屏系统输出的帧率不稳定,动态时 60 帧、静态时 20 帧,静动态切换时帧率会很不稳定,业务会进行丢帧、补充逻辑,基于这个背景业务再放 h256 + 30 帧时会出现码率低到 900k 左右导致画面模糊。
丢帧、补帧逻辑解耦,pts 不依赖录屏出帧和丢帧、补帧逻辑,直接编码器获取当前的时间戳传入编码器。
通过对这篇文章的阅读,相信大家对编码的基本概念、iOS VT 硬编的使用、实际工作中可能遇到的难题都有一定的了解了,如果大家有更多的问题或者经验欢迎留言交流。
参考文献
《音视频压缩:H264码流层次结构和NALU详解》(https://cloud.tencent.com/developer/article/1746993)