本文主要分享播放器的性能优化，本文只是方法论的总结，不会涉及具体的方式，如果想深入学习播放器优化请查看：
https://mp.weixin.qq.com/s/oL22a68Tmr2ViE3DK6Qk1g
https://mp.weixin.qq.com/s/K8DLM4X-sMghAaX5y1zFuA
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性能。
