1、解决问题:
- 声音、画面是否同步?
- 声音比画面快了还是慢了?
2、特定场景:
点播自身视频的特点:
- 交叉存储异常的情况,也就是视频自身封装异常或者流异常这两种特殊情况;
- 只有视频流或者音频流;
同步策略:视频帧快播/慢播;丢帧处理;
3、解决方案:
现有的播放流程描述:
- A网络数据下载 ----- 缓冲队列 ---- 音画同步 ----- pending队列 ----- 推送视频帧解码渲染
- V网络数据下载 ----- 缓冲队列 ---- 音画同步 ----- pending队列 ----- 音频帧拉取解码输出
对画质和感官要求比较高的游戏回放、直播obs推流等,对网络质量的要求就更高,娱乐业务相对要求就低些;那如何计算当前音、画的播放状态就成了同步的关键因素;
音画同步时计算,VideoDecodeDelta和AudioDecodeDelta的相对值;因为解码渲染存在一定的延时,音频硬件设备自身也存在一定的延时,再加上网络抖动,音画同步的处理就成了一个难题。基于时间戳的播放过程中,仅仅对早到的或晚到的数据块进行等待或快速处理,有时候是不够的。如果想要更加主动并且有效地调节播放性能,需要引入一个反馈机制,也就是要将当前数据流速度太快或太慢的状态反馈给“源”,让源去放慢或加快数据流的速度。要解决这个问题,本文提出了以下操作: