音视频同步更多文章
深入理解音视频pts，dts，time_base以及时间数学公式_视频pts计算-CSDN博客
ffplay音视频同步分析_ffplay 音视频同步-CSDN博客
音视频采集打时间戳设计
实时音视频数据的采集和处理场景。具体来说:
采集阶段:
- 在音视频数据采集过程中,需要为每一帧数据计算出时间戳。
- 可以采用"起始时间=系统时间"的方式,计算第一帧的时间戳,后续帧按照固定的帧间隔累加得到。
- 同时引入动态校正机制,检测累计时间戳与系统时间的偏差,及时修正时间戳。
传输阶段:
- 将计算好的时间戳与音视频数据一起传输到客户端。
播放阶段:
- 客户端接收到数据后,先将其缓存一段时间。
- 然后根据附带的时间戳信息,按照正确的时间顺序进行播放。
- 客户端可以进一步利用时间戳信息来调整缓冲区,以适应网络环境的变化。
这种时间戳设计方案的核心思路就是:
- 在采集端尽量保证时间戳的准确性和稳定性。后续讲解如何设计稳定和准确的方案
- 将时间戳信息传输到客户端,利用它来进行缓冲和时间校正。
- 通过客户端和服务器端的协作,最终实现音视频数据的平滑播放。
这是实时音视频领域常用的一种时间戳管理策略,能够很好地应对系统负载变化、小数误差累积等问题。
方案推导
第一方案 直接系统时间模式
初始化 starttime = systime
frameTimeStamp = systime - start time
缺陷：涉及到音频硬件采样不稳定，操作系统调度和网络传输的时间，导致ts准确度不够问题且没用纠正机制。
第二种方案 帧间隔模式
初始化 starttime = systime
frameTimeStamp = current systime - start time
Compute TimeStamp = last FrameTimeStamp + duration
优点：能输出frame duration稳定的音视频时间戳。
缺陷：
- 系统负载过高时,实际帧采集间隔可能与理论设定不一致。这将导致计算出的时间戳与实际情况不符,影响播放效果。
- 帧间隔涉及到无限小数时,会随时间累积产生较大的误差。例如预计30帧，通常按帧间隔33毫秒处理，但实际是33.3333333毫秒。累积3333帧（约111秒）就出现1秒的误差。
第三种方案 帧间隔+直接系统时间模式
初始化 starttime = systime //起始时间=系统时间
frameTimeStamp = current systime - start time //第一帧时间戳= 系统时间--起始时间
Compute TimeStamp = last FrameTimeStamp + duration //后续帧TimeStamp=上一帧时间戳+ 帧间隔
T = current systime - starttime //当前系统时间 -- 起始时间
if( |Compute TimeStamp - T | >= duraiton/2 ) Compute TimeStamp = last FrameTimeStamp
//如果当前帧的计算时间戳(CurrentFrameTS)与系统时间差值(T)的绝对值大于等于一个半帧间隔,那么我们就应该将当前帧的时间戳直接设置为系统时间差值T。
解决：动态纠正，在第二方案基础上，解决了随着播放帧数，时间戳落后或提前现象。落点值 = T = current systime - starttime //当前系统时间 -- 起始时间。关键点是设置一个合理的校正阈值,这里我们使用了半帧间隔。
优点：能够实时纠正时间戳，只要系统正常运转，就能立即恢复正确的时间戳。
缺陷：帧间隔不均匀，能否正常播放依赖于终端解决方案。 比如，假如音频一帧间隔为24毫秒，被采集的回调时间可能为20 毫秒，28毫秒，27毫秒，21毫秒。
终端解决这个问题,可以从以下几个方面着手:
在客户端使用自适应缓冲机制:
- 根据实际采集帧率的波动情况,动态调整缓冲区大小,尽量平滑播放。
在服务器端进行帧率转换:
- 服务器可以对不同帧率的数据进行帧率转换,输出稳定的帧率。
- 这样可以屏蔽掉客户端设备性能的影响。
使用更加先进的时间戳校正算法:
- 例如利用机器学习等方法,预测并修正时间戳的偏差。
采集时间戳同步问题分析
在使用帧间隔+直接系统模式基础上，发送端时间戳记录:
- 记录每一帧音视频数据的pts时间戳和pts_duration帧间隔
- 同时记录相邻帧之间的系统时间间隔 sys_duration
- 这样可以分析在采集阶段,帧间隔的稳定性
分析发送端时间戳:
- (1) ptsd(pts_duration)波动大,说明采集帧间隔不稳定，可能是由于系统负载波动等因素引起的
- 帧间隔 pts_duration 波动很大,那么意味着每帧数据被实际采集的时间间隔是不稳定的。这通常是由于系统负载波动、硬件性能波动等因素引起的,导致采集过程不够稳定。
- (2) pts稳定,但sysd(sys_duration)波动大，说明在数据发送过程中,速率不够稳定可能是网络传输过程中出现了抖动.
- 这里的 pts 时间戳是相对稳定的,意味着数据在采集端生成时间戳是比较准确的。但是,相邻帧之间的系统时间间隔 sys_duration 却出现了波动,说明在数据发送过程中,速率不够稳定。这种情况通常是由于网络传输过程中出现了抖动,导致实际发送速率不够平滑。
- (3) sysd和ptsd的值应该较为一致，如果两者差异较大,说明在整个采集-传输过程中存在问题
- 比如： [send]audio:1-pts:20ms-ptsd:24ms; sysd=23ms
接收端时间戳记录:
- 接收到的帧信息包含: 帧序号、pts时间戳、pts_duration帧间隔
- 同样记录了相邻帧的系统时间间隔 sys_duration
分析接收端时间戳:
- (1) ptsd(pts_duration)波动大,说明采集帧间隔不稳定
- (2) pts稳定,但sysd(sys_duration)波动大。说明在数据发送过程中,速率不够稳定
- 比如： [recv] audio:1-pts:20ms-ptsd:24ms; sysd=23ms 200ms
总结核心思路是:
- 在发送端和接收端同时记录时间戳信息,包括pts时间戳和系统时间
- 通过对这些时间戳数据的分析,可以全面诊断出音视频同步过程中的各种问题
- ptsd异常 采集端的帧间隔不稳定
- pts稳定下 sysd异常 推流端的数据传输速率不稳定，存在网络传输过程中的抖动。
学习资料分享