iOS浅谈播放器架构

主流业务场景协议与痛点

• 短视频：http，海量码流格式、容器格式需要支持
• 秀场类直播：rtmp、http-flv、hls，延时、卡顿
• 摄像头监控：rtsp、延时、丢帧

协议	传输方式	封装格式	延时	数据流	H5直播	应用场景
HLS	http	m3u8/ts	10s以上	ts切片	支持	直播拉流
RTMP	tcp	flv	2s左右	连续流	不支持	采集推流
HTTP-FLV	http	flv	2s左右	连续流	支持	直播拉流

系统自带播放器的局限性

• 支持的协议有限
• 支持的码流格式有限
• 支持的容器格式有限
• 不支持流式播放
• 关键模块封装的严实，无法自定义和调试，排查问题困难

播放器核心架构

• FFmpeg负责解协议解封装得到AVPacket根据类型分包到音视频压缩数据队列
• 音视频解码器解码出AVFrame，iOS硬解码出来直接是CVPixelBufferRef格式，放入音视频渲染队列
• 音频帧使用AudioUnit渲染，根据系统回调喂数据，视频帧根据同步帧率控制，进行渲染，渲染引擎同时支持Metal、openGLES

FFMpeg裁剪包

• FFmpeg负责解协议、解容器同时支持协议容器格式任意裁剪
• 基础包用于常规业务
• 可以根据特定业务类型自定义裁剪包
• 全量包用特殊业务

解协议、解封装、解码

• 建立链接获取字节流
• 创建解析器得到媒体流信息包括音视频格式、时长、码率、帧率等信息
• 创建解复用器循环读取压缩数据包放入压缩数据队列
• 根据码流信息创建解码器得到yuv和pcm放入带渲染队列

Buffer队列

• 抵抗网络抖动
  降低卡顿率，没有Buffer队列的数据流：IO->Parser->Demuxer->Decoder串行执行，当网络抖动的时候会出现CDN缓存的较多的数据（现在主流设计只会缓存几帧），导致TCP发送队列爆满而产生被动丢帧，导致网络恢复的时候下发到客户端的数据不完整而产生花屏
• 抵抗解码抖动
  解码某些复杂码流的时候，某些帧可能耗时比较久，如果解码器卡住，永阳IO也会阻塞
• Buffer队列设计引入的问题
  Buffer越大，内对占用越高、延时越高

因此需要根据不同业务场景配置相应的buffer策略

• 点播
  缓存大小可以适当的大一些，但也要控制好内存，移动网络下长度控制在15秒以内，wifi下可以控制在30秒内
• 直播

场景	策略模式	详情
秀场	流畅模式	正常缓存播放
语音房	加速模式	大于delaytime，倍速播放
IOT	低延时模式	大于delaytime，丢帧

音视频渲染

• 视频渲染挑战
  iOS支持openGLES，但是2018年的WWDC上，苹果公司发布了正式版的iOS12，同时宣布弃用openGLES并且在后续的iOS版本中会逐步替换底层库的相关代码使之向metal演变

1、Metal支持的操作系统：iOS、macOS X
2、Metal的硬件要求：A7处理器，ARM64以上，就是iphone5s以上的机型，不支持x86
3、Metal支持的系统版本：Metal：iOS8，MetalKit：iOS9

因此需要支持模拟器和低版本的系统，需要实现两套方案，需要设计openGLES与Metal的适配器以供播放器控制自由切换

• 音频渲染挑战
  iOS系统支持流式播放的音频框架有opengAL、audioQueue、audioUnit
  openAL所有实例共享一个上下文，不符合播放器多实例的特性，并且一个实例发生错误，所有实例均不能在使用；openAL、audioQueue都是封装的audioUnit，audioUnit更接近硬件，延迟最低性能最佳

1、设置app是否与其他应用混音
2、手机静音app是否正常播放出声音
3、电话或其他应用抢占音频设备事件处理
4、动态切换音频路由
5、是否支持录音，录音同时是否支持播放

音频中断事件处理复杂，当中断发生时如果音频权限同时被修改会收不到中断恢复消息，从而导致音频播放卡住，因此需要程序回到前台统一处理

播放器状态机

播放器通用接口

• 创建/销毁播放器（支持多实例）
• 参数动态配置（渲染模式、解码方式等）
• 发送指令 （播放、暂定、seek等）
• 原始码流回调（支持外部渲染）
• 状态消息回调（缓冲、播放完成、错误等）