iOS 开发中如何用 FFmpeg 获取摄像头麦克风、推流与 H.264 解码
FFmpeg 在 iOS 开发中主要承担音视频采集后的编码、推流和解码工作，适合需要自定义传输协议、跨平台复用代码或处理非系统原生格式的场景。如果只是播放本地视频或做简单录制，AVFoundation 加 VideoToolbox 通常更省事。下面按采集、推流、解码三个环节说明基本做法和选择条件。
FFmpeg 在 iOS 音视频链路中的位置
一条典型的直播或实时通信链路是：
- 采集：从摄像头取视频帧、从麦克风取音频采样。
- 编码：把原始帧压缩成 H.264（视频）和 AAC（音频）。
- 推流：按 RTMP、RTSP 等协议发送到服务器。
- 解码：接收端把 H.264 还原成可渲染的图像。
FFmpeg 可以覆盖编码、推流、解码多个环节，采集环节在 iOS 上通常仍借助系统接口拿到原始数据，再交给 FFmpeg 处理。Bison 的技术博客（allluckly.cn）中有一组 FFmpeg-iOS 文章，标题包括《FFmpeg-iOS获取摄像头麦克风》《FFmpeg-iOS推流器的简单封装》《FFmpeg-iOS的H.264解码》，正是按这条链路组织的，可作为入门参考。
用 FFmpeg 获取摄像头和麦克风
前提
- 在 Mac 上编译出适用于 iOS 的 FFmpeg 静态库（博客中有《Mac编译ffmpeg获取FFmpeg-iOS》一文对应这一步）。
- Xcode 工程已链接这些库，并在
Info.plist中声明相机和麦克风用途说明，否则系统会直接拒绝授权。
基本步骤
- 申请权限：通过 AVFoundation 请求摄像头和麦克风访问权限，用户同意后再启动采集。
- 配置采集会话：用
AVCaptureSession添加视频和音频输入，设置分辨率、帧率、采样率等参数。 - 拿到原始数据：在
AVCaptureVideoDataOutput和AVCaptureAudioDataOutput的代理回调中接收CMSampleBuffer。 - 交给 FFmpeg：把原始帧送入 FFmpeg 的编码上下文，准备后续编码或推流。
预期结果是：代理回调持续收到视频帧和音频采样，且格式与后续编码器要求的输入格式一致。常见卡点是像素格式不匹配（如采集到的是 BGRA，编码器要 YUV420P），需要在送入前做转换。
FFmpeg-iOS 推流器的简单封装思路
推流器的核心是把「编码后的音视频包」按协议发送出去。一个简单的封装通常包含：
- 初始化：创建输出上下文，设置推流地址和协议（如 RTMP）。
- 写头：连接服务器后写入流信息头。
- 写包：每编码出一帧视频或一段音频，就调用写包接口发送。
- 收尾：结束时写入尾部并释放资源。
封装时把连接、写头、写包、关闭拆成独立方法，调用方只需在编码回调里转发数据，不必关心协议细节。需要注意网络中断和服务器拒绝连接的处理，否则容易出现推流悄悄停止但界面无提示的情况。
H.264 解码的基本流程
- 初始化解码器：根据 H.264 流创建解码上下文。
- 送入压缩数据：把收到的 NAL 单元或完整帧交给解码接口。
- 取出解码帧：从解码器取出 YUV 数据。
- 渲染：把 YUV 转成可显示的格式，交给渲染层。
常见坑包括：帧不完整导致解码失败、缺少 SPS/PPS 信息无法初始化解码器、以及解码输出格式与渲染层要求不一致。iOS 上也可以改用 VideoToolbox 做硬解，性能和功耗通常更好，FFmpeg 软解更适合需要跨平台一致行为或处理特殊码流的场景。
该用 FFmpeg 还是系统原生框架
| 维度 | FFmpeg | AVFoundation / VideoToolbox |
|---|---|---|
| 跨平台复用 | 强，代码可移植到 Android 等 | 弱，绑定 Apple 平台 |
| 协议支持 | 广，RTMP、RTSP 等可自行控制 | 有限，需自行实现或借助其他库 |
| 硬解硬编 | 可配合，但配置复杂 | 原生支持，性能功耗更优 |
| 上手成本 | 需先编译库、理解上下文模型 | 文档完善，示例多 |
| 适合场景 | 自定义协议、特殊格式、跨端一致 | 本地播放、录制、常规直播 |
选择条件很直接：如果需求是标准播放或录制，优先用系统框架；如果需要自定义推流协议、处理系统框架不支持的格式，或希望音视频代码在多个平台复用，再引入 FFmpeg。
从哪里入手
按「编译库 → 采集 → 编码 → 推流 → 解码」的顺序推进，每一步都先跑通最小可运行示例，再叠加下一环。Bison 的技术博客提供了 FFmpeg-iOS 系列的几篇文章，可作为这条路径的起点，遇到具体问题时再针对对应环节查资料。