音视频采集推流时间戳记录方案

音视频同步更多文章

深入理解音视频pts，dts，time_base以及时间数学公式_视频pts计算-CSDN博客

ffplay音视频同步分析_ffplay 音视频同步-CSDN博客

音视频采集打时间戳设计

实时音视频数据的采集和处理场景。具体来说:

采集阶段:

• 在音视频数据采集过程中,需要为每一帧数据计算出时间戳。
• 可以采用"起始时间=系统时间"的方式,计算第一帧的时间戳,后续帧按照固定的帧间隔累加得到。
• 同时引入动态校正机制,检测累计时间戳与系统时间的偏差,及时修正时间戳。

传输阶段:

• 将计算好的时间戳与音视频数据一起传输到客户端。

播放阶段:

• 客户端接收到数据后,先将其缓存一段时间。
• 然后根据附带的时间戳信息,按照正确的时间顺序进行播放。
• 客户端可以进一步利用时间戳信息来调整缓冲区,以适应网络环境的变化。

这种时间戳设计方案的核心思路就是:

1. 在采集端尽量保证时间戳的准确性和稳定性。后续讲解如何设计稳定和准确的方案
2. 将时间戳信息传输到客户端,利用它来进行缓冲和时间校正。
3. 通过客户端和服务器端的协作,最终实现音视频数据的平滑播放。

        这是实时音视频领域常用的一种时间戳管理策略,能够很好地应对系统负载变化、小数误差累积等问题。

方案推导

第一方案 直接系统时间模式

初始化 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异常 推流端的数据传输速率不稳定，存在网络传输过程中的抖动。

 

 学习资料分享

0voice · GitHub