简介PLCameraStreamingKit 是 Pili 直播 SDK 的 iOS 推流端一个带采集模块的开源老版本面向需要快速搭建 RTMP 直播推流能力的移动开发者。该版本支持 H.264 与 AAC 编码硬编、软编均可运行集成美颜、背景音乐、水印等直播场景功能并提供丰富的数据与状态回调便于按业务二次封装。压缩包共 594 个文件、约 4.97MB以 355 个 h 头文件、101 个 md 文档、65 个 m 源文件与 27 个 c 文件为主体另有少量静态库、工程配置、崩溃上报代码兼顾接口声明、使用说明和底层实现。整套源码与预编译库搭配目录结构清晰既能快速嵌入现有工程也适合深入研究采集、编码、推流、异常恢复等模块的协作方式入门者可借助文档梳理推流链路进阶者可根据回调与配置项做软硬编切换、美颜和水印等定制开发。已有 638 人学习下载对关注 iOS 直播开发的人群有务实参考价值。 iOS 上做直播推流RTMP 协议和推流 SDK 几乎是绕不开的两个词。这几年从直播答题到教育双师从电商带货到户外连麦我见过太多团队拿着一份压缩包就开始集成结果被采集卡顿、延迟漂移、断流重连搞得焦头烂额。这篇博文就围绕“iOS RTMP 直播推流 SDK”这个主题把选型思路、核心代码、参数调优和排坑经验一次性讲透适合正在做 iOS 直播功能、或者准备自研推流模块的开发者参考。先说结论RTMP 虽然老但在国内直播场景下依然是最稳的推流协议没有之一。你要做的不是重复造轮子而是搞懂一个成熟 SDK 的关键节点然后把业务层做厚。下面直接进入正文。1. 项目背景与整体方案选型1.1 为什么 iOS 直播推流还是绕不开 RTMP很多人一上来就问“RTMP 是不是过时了为什么不用 WebRTC 或者 SRT”。我理解这种想法但放到真实业务里RTMP 的江湖地位依然稳固。核心原因有三个第一RTMP 基于 TCP传输可靠弱网环境下不会像 UDP 系协议那样出现大范围花屏和丢帧第二服务端生态成熟从 Nginx-RTMP 到腾讯云、阿里云的直播服务全部原生支持 RTMP 推流接入你拿到一个rtmp://地址就能跑通全链路第三播放端兼容性极好Flash 虽然没了但 HLS 转封装、FLV 播放方案已经非常成熟CDN 厂商对 RTMP 上行链路的优化也做得最透。做 iOS 直播推流 SDK本质上就是围绕 RTMP 做三件事采集、编码、传输。采集端拿到摄像头和麦克风的数据编码器压缩成 H.264 视频流和 AAC 音频流然后通过 RTMP 协议封装成 FLV 标签发到服务器。这个过程听起来简单但每个环节都有大量细节尤其是 iOS 系统对后台采集、屏幕采集、硬编硬解的权限和生命周期限制非常多原生 AVFoundation 框架虽然有现成接口但直接拿来做生产级推流远远不够。1.2 自研还是集成 SDK主流方案怎么选我见过不少团队一开始雄心勃勃想自研推流 SDK最后都灰溜溜换成了成熟方案。自研的最大坑不是编码而是长期维护成本。iOS 系统每年升级Camera 权限策略在变AAC 编码器的参数行为在变App 后台策略也在变这些都需要有人持续跟进。如果你的核心业务不是直播底层技术我建议优先集成成熟 SDK把精力放在业务层。目前 iOS 上主流的 RTMP 推流 SDK 有这几类一是商业 SDK功能全、文档好但要收费且受平台政策约束二是开源 SDK典型代表是 LFLiveKit代码结构清晰适合二次开发但停止维护很久需要自己适配新系统三是基于系统 VideoToolbox 和 AudioToolbox 自研轻量推流器。我的建议是MVP 阶段直接用开源的 LFLiveKit 跑通流程中期根据业务需求对采集模块做替换后期如果量大了再考虑自研传输层。下面这张表可以帮你快速定位方案成本可控性维护难度适用阶段商业SDK七牛/声网/腾讯高按量付费低低快速上线的产品开源SDKLFLiveKit等低中中中小型项目、自研基础完全自研极高高极高大厂、核心业务自控我自己的实践路径是先用开源 SDK 做了两个版本踩完所有坑之后把采集和编码部分替换成了自研代码传输层仍然用 RTMP。这样既保证了上线速度又能在出问题时快速定位。2. 推流 SDK 核心技术点拆解2.1 采集端分辨率、帧率、码率如何配比采集参数不是随便填的它直接影响画质、延迟和性能三者的平衡。我见过有人把分辨率拉到 1080p、码率开到 6000kbps结果中端 iPhone 发热严重帧率掉到 20fps画面还不如 720p 流畅。这里的核心逻辑是码率决定画质上限帧率决定流畅度分辨率决定细节量三者要匹配。实际项目中我常用的配比方案是直播场景推荐 720p 分辨率、30fps 帧率、码率 1500~2500kbps如果做游戏直播或屏幕录制画面静态区域多可以适当降低码率如果做户外运动直播画面变化剧烈码率需要适当上调。具体码率可以参考公式码率kbps ≈ 宽度 × 高度 × 帧率 × 0.07~0.1。比如 1280×720×30×0.08 ≈ 2211kbps这个值在大多数直播场景下画质和带宽的平衡都还不错。另外iOS 采集端要关注 AVCaptureSession 的预设值。不要直接设AVCaptureSessionPresetHigh这种笼统的值建议手动指定宽度和高度用AVCaptureSessionPreset1280x720同时开启videoSettings中的关键帧间隔设置。关键帧间隔GOP通常设置为帧率的 2 倍也就是 60 帧一个关键帧这样秒开和延迟都能兼顾。2.2 编码器H.264 硬编与软编的取舍iOS 上视频编码有两条路VideoToolbox 硬编和 x264 软编。硬编的优势是功耗低、速度快缺点是码率控制不够精细某些系统版本会有花屏问题软编的优势是参数可控、画质好缺点是 CPU 占用高中低端设备很容易发热降频。实际项目里我推荐默认走 VideoToolbox 硬编同时加一个开关允许用户在设置页切换软编。原因很简单硬编是 iOS 系统的原生能力集成成本低而且从 iPhone 6s 开始硬编质量已经非常稳定。实现硬编只需要三步创建VTCompressionSession设置kVTCompressionPropertyKey_ProfileLevel为kVTProfileLevel_H264_High_AutoLevel设置码率和帧率然后通过VTCompressionSessionEncodeFrame喂入像素缓冲区。有一个容易被忽略的坑硬编时一定要设置kVTCompressionPropertyKey_RealTime为true否则编码器会为了追求压缩率引入几百毫秒的延迟。另外kVTCompressionPropertyKey_MaxKeyFrameInterval设置的是帧数而不是秒数很多人在这里踩坑以为设了 2 就是两秒一个关键帧实际上是两帧一个关键帧浪费带宽。音频编码方面AAC 是直播标配。iOS 上可以用 AudioToolbox 的AudioConverter将 PCM 转成 AAC注意设置采样率 44100Hz、声道数 1直播场景单声道足够、码率 128kbps 左右即可。如果要做连麦再考虑双声道和更高码率。2.3 传输层RTMP 握手与 FLV 封装细节RTMP 传输层的核心是握手和 FLV 封装。握手是三个固定长度的块客户端先发 C0、C1服务器回 S0、S1、S2客户端再发 C2完成之后就可以收发命令消息了。很多人写推流 SDK 时直接用第三方库如 librtmp跳过握手细节但你要排查问题时还是得理解这个过程。FLV 封装相对简单视频标签和音频标签交替发送每个标签由 11 字节头部和负载组成。头部包含标签类型8 为音频9 为视频18 为脚本数据、数据长度、时间戳和流 ID。时间戳是毫秒为单位前一个字节存低 8 位后三个字节存高 24 位很多初级开发者在这里搞错字节序导致播放端时间轴错乱。我建议传输层直接使用成熟的 librtmp 库封装不要自己实现 RTMP 协议细节但必须理解协议结构。实际开发中把 librtmp 编译成静态库链接进 iOS 工程然后通过RTMP_Connect、RTMP_ConnectStream、RTMP_Write三个关键函数完成推流。RTMP_Write需要把编码后的 H.264 裸流先封装成 FLV 标签再写入这一层逻辑必须自己实现。3. 集成与实操从零构建推流 Demo3.1 工程配置与依赖引入假设你用 LFLiveKit 作为基础版本第一步是引入依赖。我建议用 CocoaPods 管理Podfile 里加一行pod LFLiveKit然后pod install。这里有个小坑LFLiveKit 在 iOS 14 以上会出现权限描述不完整的问题需要在 Info.plist 里补充NSCameraUsageDescription和NSMicrophoneUsageDescription否则摄像头和麦克风直接崩溃。如果你打算替换成自研采集和编码可以不引入完整 SDK只引入 librtmp 静态库。编译 librtmp 的时候要注意架构支持用 Xcode 12 以上版本编译时需要排除armv7s架构否则会报错。推荐直接用脚本编译arm64和x86_64双架构方便模拟器调试。3.2 推流流程核心代码以 LFLiveKit 为例核心推流代码可以这样写import LFLiveKit class LivePusherManager: NSObject { private lazy var session: LFLiveSession { let audioConfig LFLiveAudioConfiguration.default() let videoConfig LFLiveVideoConfiguration.defaultConfiguration( quality: .medium3, // 720p, 30fps, 2Mbps outputImageOrientation: .portrait ) let session LFLiveSession(audioConfiguration: audioConfig, videoConfiguration: videoConfig)! session.delegate self session.captureDevicePosition .front return session }() func startPush(urlString: String) { let stream LFLiveStreamInfo() stream.url urlString session.startLive(with: stream) } func stopPush() { session.stopLive() } }用系统原生 AVFoundation 也可以实现类似效果但需要自己管理 AVCaptureSession 的输出回调然后把 CMSampleBuffer 转成 CVPixelBuffer再喂给 VideoToolbox。这个流程我拆成三步配置AVCaptureSession添加视频输入和视频输出设置videoSettings为kCVPixelFormatType_32BGRA在captureOutput回调里拿到CMSampleBuffer通过CMSampleBufferGetImageBuffer获取CVPixelBuffer将CVPixelBuffer和音频CMSampleBuffer分别送入编码器。如果你用 LFLiveKit它内部已经封装好了这个流程你只需要处理生命周期和推流地址。3.3 参数配置与性能调优参数配置的核心目标是延迟和画质的平衡。我实测下来RTMP 推流 HLS 播放的正常延迟在 3~5 秒如果要做低延迟直播需要配合播放端的 FLV 方案延迟可以压到 1~2 秒。具体在 SDK 层可以做几个优化第一关闭 VideoToolbox 的 B 帧。B 帧虽然能提升压缩率但会引入额外的编码延迟和播放端解码复杂度。在VTCompressionSession里设置kVTCompressionPropertyKey_AllowFrameReordering为false强制编码器不产生 B 帧延迟能降低 300ms 左右。第二调整 GOP 大小。关键帧间隔越大码率越平稳但拉流端首帧等待越久。推荐 GOP 设为帧率的 2 倍即 60 帧这样播放端最多等 2 秒就能出画面。第三开启码率自适应。iOS 上可以通过监控当前 buffer 的堆积情况动态调整码率。简单做法是在编码器回调里记录CMSampleBuffer的时间戳如果发现解码端滞后超过 500ms就把码率降一档如果连续 5 秒没有丢帧再升一档。这样在弱网环境下能显著减少卡顿。音频参数方面AAC 编码建议使用kAudioFormatMPEG4AAC比特率根据场景选 96kbps 到 128kbps采样率 44100Hz。连麦场景需要开启AVAudioSession的kAudioSessionProperty_OtherAudioAvailable否则其他 App 的音频会被打断。4. 实际踩坑与问题排查实录4.1 延迟异常增大怎么排查推流 SDK 上线后反馈最多的问题就是延迟越来越大。我遇到过一次推流 30 分钟后播放端延迟从 3 秒涨到 10 秒最开始怀疑是网络问题后来查了服务端日志发现是客户端发送速度比服务器消费速度快导致服务器缓冲堆积。这种问题的排查思路是先看客户端本地是否堆积。在 RTMP 写入前加一个队列每写入一个 FLV 标签就记录队列长度如果队列长度持续增长说明是采集或编码速度跟不上或者网络发送阻塞。我常用的手段是在统计面板打点每 5 秒输出一次队列长度、当前码率、编码帧率三项数据一旦发现队列长度持续大于 30 帧就主动丢帧。另外注意时间戳的生成规则。RTMP 时间戳必须用采集时的CMSampleBuffer原始时间戳而不是当前发送时间。如果用了发送时间一旦网络抖动时间戳会跳变播放端会认为画面卡住触发追帧或快进延迟瞬间飙升。4.2 内存暴涨和发热问题iOS 推流 SDK 里内存暴涨一般有两个元凶一是采集端没有及时释放CMSampleBuffer导致视频帧堆积二是编码器回调队列和主线程之间没有做好同步造成并发访问冲突。我踩过的坑是 AVCaptureSession 的captureOutput回调默认在串行队列如果你在这个回调里做耗时操作比如转格式就会阻塞采集导致帧率下降。正确做法是回调里只做轻量处理立即把CMSampleBuffer转到自建的并发队列里做编码。同时注意在 iOS 17 及以上系统后台采集权限收得更紧App 切到后台时一定要停止推流否则会被系统直接杀掉。发热问题主要看 CPU 占用。用硬编时 CPU 占用一般在 20% 以下如果超过 40%大概率是编码配置不对比如没有设置RealTime属性或者 B 帧开启导致编码器性能下降。另外推流时不要同时开太多后台任务尤其是 CoreImage 滤镜GPU 占用过高会直接拖垮编码性能。4.3 断流重连策略怎么设计直播推流里断流是常态网络切换、服务器重启、App 被挂起都可能导致断流。重连策略设计得不好用户就会看到黑屏或卡住的画面。我推荐用“渐进式重连 手动重推”的组合。具体参数是断流后立刻重连一次失败后等 2 秒重连再失败等 5 秒再失败等 10 秒最多重连 5 次。如果 5 次都失败就不再自动重连提示用户手动操作。重连时需要重新走一遍 RTMP 握手流程并且把编码器重置否则有些硬编 session 在断网时会残留错误状态。另外一个容易忽略的点断流重连成功后要主动发一个关键帧。因为在断流期间播放端可能已经丢失了解码上下文如果继续发 P 帧播放端会花屏很久。在重连成功发送的第一个视频帧上要把kVTEncodeFrameOptionKey_ForceKeyFrame设为true强制编码器生成关键帧。4.4 常见问题速查表现象可能原因解决方案推流成功但播放黑屏关键帧间隔太大或首帧不是IDR设置GOP为帧率的2倍重连后强制发关键帧画面卡顿但CPU不高采集帧率不足或网络拥塞检查camera配置开启码率自适应声音和画面不同步音视频时间戳不一致统一用采集时间戳不要用发送时间弱网下延迟无限增长发送队列堆积主动丢帧降低码率加快关键帧节奏切后台后崩溃系统回收摄像头资源监听UIApplicationDidEnterBackgroundNotification主动停止推流硬编花屏编码器session状态错误重连时重建VTCompressionSession这些坑我在实际项目里基本都踩过一轮尤其时间戳和重连后的关键帧问题几乎每个做推流的人都会遇到。如果你正在集成这类 SDK建议先跑一遍上面的排查清单能省不少时间。最后再分享一个我自己的习惯每次推流 SDK 上线前我会专门写一个稳定性测试脚本用固定的 rtmp 测试地址连续推流 12 小时同时记录帧率、码率、CPU、内存和延迟五项指标。iOS 直播推流的坑往往不是某个功能不工作而是在长时间运行后暴露出来的资源泄漏和时序问题。提前压测比上线后救火要省心太多。本文还有配套的精品资源点击获取