ffplay---源码分析（八）：音视频同步---原理

https://blog.csdn.net/bingqingsuimeng/article/details/9980579?utm_source=blogxgwz4

https://blog.csdn.net/weixin_33774615/article/details/85906663?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param

https://blog.csdn.net/titer1/article/details/39613123

数据接收（网络/本地）->解复用->音视频解码->音视频同步->音视频输出。
在音频流和视频流中，其播放速度都是有相关信息指定的：
　　视频：帧率，表示视频一秒显示的帧数。
　　音频：采样率，表示音频一秒播放的样本的个数。
声卡和显卡均是以一帧数据来作为播放单位，如果单纯依赖帧率及采样率来进行播放，在理想条件下，应该是同步的，不会出现偏差。
以一个44.1KHz的AAC音频流和24FPS的视频流为例：
一个AAC音频frame每个声道包含1024个采样点，则一个frame的播放时长(duration)为：(1024/44100)×1000ms = 23.22ms；一个视频frame播放时长(duration)为：1000ms/24 = 41.67ms。理想情况下，音视频完全同步，音视频播放过程如下图所示：

实际情况下导致偏差的原因：
　　1、一帧的播放时间，难以精准控制。音视频解码及渲染的耗时不同，可能造成每一帧输出有一点细微差距，长久累计，不同步便越来越明显。（例如受限于性能，42ms才能输出一帧）
　　2、音频输出是线性的，而视频输出可能是非线性，从而导致有偏差。
　　3、媒体流本身音视频有差距。（特别是TS实时流，音视频能播放的第一个帧起点不同）

所以，解决音视频同步问题，引入了时间戳：
首先选择一个参考时钟（要求参考时钟上的时间是线性递增的）；
编码时依据参考时钟上的给每个音视频数据块都打上时间戳；
播放时，根据音视频时间戳及参考时钟，来调整播放。
所以，视频和音频的同步实际上是一个动态的过程，同步是暂时的，不同步则是常态。以参考时钟为标准，放快了就减慢播放速度；播放快了就加快播放的速度。
音视频同步本质：不是理想状态中的完全同步，而是将误差限制在一定范围内

PTS

在B帧的视频中：（相对于系统参考时间戳SCR而言）
DTS，Decoding Time Stamp，解码时间戳；
PTS，Presentation Time Stamp，显示时间戳。
　　
而音频的PTS=DTS，而视频在没有B帧时PTS=DTS，在有B帧时PTS≠DTS