购物网站功能报价,网站策划与建设阶段应该做什么,建设企业网站技术解决方案,自助网站建设公司音视频同步更多文章
深入理解音视频pts#xff0c;dts#xff0c;time_base以及时间数学公式_视频pts计算-CSDN博客
ffplay音视频同步分析_ffplay 音视频同步-CSDN博客 音视频采集打时间戳设计
实时音视频数据的采集和处理场景。具体来说:
采集阶段:
在音视频数据采集过…音视频同步更多文章
深入理解音视频ptsdtstime_base以及时间数学公式_视频pts计算-CSDN博客
ffplay音视频同步分析_ffplay 音视频同步-CSDN博客 音视频采集打时间戳设计
实时音视频数据的采集和处理场景。具体来说:
采集阶段:
在音视频数据采集过程中,需要为每一帧数据计算出时间戳。可以采用起始时间系统时间的方式,计算第一帧的时间戳,后续帧按照固定的帧间隔累加得到。同时引入动态校正机制,检测累计时间戳与系统时间的偏差,及时修正时间戳。
传输阶段:
将计算好的时间戳与音视频数据一起传输到客户端。
播放阶段:
客户端接收到数据后,先将其缓存一段时间。然后根据附带的时间戳信息,按照正确的时间顺序进行播放。客户端可以进一步利用时间戳信息来调整缓冲区,以适应网络环境的变化。
这种时间戳设计方案的核心思路就是:
在采集端尽量保证时间戳的准确性和稳定性。后续讲解如何设计稳定和准确的方案将时间戳信息传输到客户端,利用它来进行缓冲和时间校正。通过客户端和服务器端的协作,最终实现音视频数据的平滑播放。 这是实时音视频领域常用的一种时间戳管理策略,能够很好地应对系统负载变化、小数误差累积等问题。
方案推导
第一方案 直接系统时间模式 初始化 starttime systime frameTimeStamp systime - start time 缺陷涉及到音频硬件采样不稳定操作系统调度和网络传输的时间导致ts准确度不够问题且没用纠正机制。 第二种方案 帧间隔模式 初始化 starttime systime frameTimeStamp current systime - start timeCompute 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; sysd23ms
接收端时间戳记录:
接收到的帧信息包含: 帧序号、pts时间戳、pts_duration帧间隔同样记录了相邻帧的系统时间间隔 sys_duration
分析接收端时间戳:
(1) ptsd(pts_duration)波动大,说明采集帧间隔不稳定(2) pts稳定,但sysd(sys_duration)波动大。说明在数据发送过程中,速率不够稳定比如 [recv] audio:1-pts:20ms-ptsd:24ms; sysd23ms 200ms
总结核心思路是:
在发送端和接收端同时记录时间戳信息,包括pts时间戳和系统时间通过对这些时间戳数据的分析,可以全面诊断出音视频同步过程中的各种问题 ptsd异常 采集端的帧间隔不稳定pts稳定下 sysd异常 推流端的数据传输速率不稳定存在网络传输过程中的抖动。 学习资料分享
0voice · GitHub
