本文首要分享播映器的性能优化，本文只是方法论的总结，不会触及具体的方法，假如想深化学习播映器优化请检查：
mp.weixin.qq.com/s/oL22a68Tm…
mp.weixin.qq.com/s/K8DLM4X-s…
1.播映指标
- 播映成功率
- 播映成功次数 / 播映总次数
- 视频播映首帧（秒开率）
- 调用start ~ 视频首帧送入Render
- 首帧在1s的次数 / 总次数
- 视频播映卡顿率
- 卡顿总时长 / 观看时长
- seek拖动卡顿
- seek拖动卡顿次数 / seek总次数
视频播映成功率现在都比较高了，一般都是自建的源或许运用头部云平台的服务，不会存在格局不支持的问题了。
现在比较重要的两个指标便是视频播映首帧和视频播映卡顿率
2.视频首帧优化
- TCP恳求衔接复用
- 恳求的域名可以枚举出来，可以预衔接，后续复用
- 预建解码器
- 后台下发视频信息，预先创建解码器
- 解码器复用
- 预烘托
- 首先将首帧烘托出来
- 预加载
- 头部设置probesize和analyzeduration设置恳求的巨细，保证预先恳求满足的数据以供后续烘托
- 指定格局
- 指定特定的解封装格局
- 指定特定的解码格局
- 边下边播
- 本地代理实现边下边播，可以复用之前缓存
- video-id复用
- 同一个视频url会经常变，可是video-id不变，用video-id作为视频缓存的key
- 低码率首帧加载
- 开端播映运用低码率的片源，等后续播映稳定切换到高码率的片源
3.视频卡顿优化
- 解决烘托卡顿
- 播映帧烘托不能有耗时操作，例如视频播映中美颜、滤镜等操作不能耗时
- 加载Buffer优化
- 网络好的情况下缓冲Buffer调大点
- 网络差的情况下缓冲Buffer调小点
- 多码率习惯
- HLS多码率习惯，弱网情况下核算load buffer自动切换到低码率
- 丢帧控制
- 极端情况下适当丢帧，丢帧要优先丢非参考帧，或许得话丢一整个GOP的数据，避免呈现花屏
- 音视频同步
- 推流端推的视频timestamp和音频timestamp有问题，拉流端音视频同步存在问题，导致播映卡顿，需要推流端校准
4.Seek优化
拖动进度条是一个比较重要的优化项，ffmpeg中的av_seek_frame有下面几种选项：
- AVSEEK_FLAG_BACKWARD：第一个 Flag 是 seek 到恳求的时刻戳之前最近的关键帧。通常情况下，seek 以 ms 为单位，若指定的 ms 时刻戳刚好不是关键帧（大几率），会自动往回 seek 到最近的关键帧。虽然这种 flag 定位并不是非常精确，但可以较好地处理掉马赛克的问题，因为 BACKWARD 的方法会向回查找关键帧处，定位到关键帧处。
- AVSEEK_FLAG_BYTE ：第二个 Flag 是 seek 到文件中对应的方位（字节表示），和 AVSEEK_FLAG_FRAME 完全一致，但查找算法不同。
- AVSEEK_FLAG_ANY：第三个 Flag 是可以 seek 到任意帧，不一定是关键帧，因此运用时或许呈现花屏（马赛克），但进度和手滑完全一致。
- AVSEEK_FLAG_FRAME：第四个 Flag 是 seek 的时刻戳对应 frame 序号，可以理解为向后找到最近的关键帧，与 BACKWARD 的方向是相反的。
- 当时播映时刻点是cur_time，拖动到的时刻点是seek_time，假如seek_time和cur_time在同一个GOP内部，那就不需要清空video frame queue中数据，优化seek性能。
