涉及硬件的音视频能力,比如采集、渲染、硬件编码、硬件解码,通常是与客户端操作系统强相关的,就算是跨平台的多媒体框架也必须使用平台原生语言的模块来支持这些功能
本系列文章将详细讲述移动端音视频的采集、渲染、硬件编码、硬件解码这些涉及硬件的能力该如何实现
本文为该系列文章的第 2 篇,将详细讲述在 iOS 平台下如何实现视频的硬件编码
往期精彩内容,可参考
前言
视频编码,就是对视频数据进行压缩,压缩后的数据可以封装在容器内,形成视频文件,也可以进行网络传输,来实现视频会议、直播等业务场景。常见的编码格式有 H.264/AVC、H.265/HEVC、H266/VVC、AV1 等等
为什么要压缩,因为未压缩的视频数据实在是太大了。最直观的例子:分辨率 1080p + 帧率 24 + 时长 2 小时的电影中,未经压缩的视频数据,使用最常用的 RGB 颜色表示方式,占用空间约为 1920 * 1080 * 3 * 24 * 7200 = 1001 GB,快要达到 1 TB 的数据量了。因此视频数据不做压缩,是没有现实意义的,存储和传输的成本会高到离谱
在 iOS 平台,Apple 提供的硬件编码功能,目前仅支持 H.264 和 H.265,本文也将介绍这 2 种格式的硬件编码该如何实现。在阅读本文之前,建议预先了解下 H.264 和 H.265 的码流结构这些原理性的内容,方便后续更好的理解本文内容
整体流程
本文所介绍的编码流程,如下图所示
数据变化的过程,如下图所示
系统框架
用到了 VideoToolbox,引入头文件
#import <VideoToolbox/VideoToolbox.h>
初始化编码器
构造 source_image_buffer_attributes
-
kCVPixelBufferOpenGLESCompatibilityKey、kCVPixelBufferMetalCompatibilityKey,无脑设置为 true
-
kCVPixelBufferIOSurfacePropertiesKey 要设置成非 NULL 的值,简单来说能够让编码器更高效的读取 CVPixelBuffer 中的图像数据
-
编码器支持的格式只有 NV12,也就是 kCVPixelFormatType_420YpCbCr8BiPlanarFullRange
选择编码器类型
-
H.264 使用 kCMVideoCodecType_H264
-
H.265 使用 kCMVideoCodecType_HEVC
const size_t attributes_size = 4;
CFTypeRef keys[attributes_size] = {
kCVPixelBufferOpenGLESCompatibilityKey,
kCVPixelBufferMetalCompatibilityKey,
kCVPixelBufferIOSurfacePropertiesKey,
kCVPixelBufferPixelFormatTypeKey
};
CFDictionaryRef io_surface_ref = CFDictionaryCreate(kCFAllocatorDefault, nullptr, nullptr, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
OSType pixelFormat = kCVPixelFormatType_420YpCbCr8BiPlanarFullRange;
CFNumberRef pixel_format_ref = CFNumberCreate(nullptr, kCFNumberLongType, &pixelFormat);
CFTypeRef values[attributes_size]