播放：音视频同步算法
Playback: audio-video synchronization algorithm
我正在使用 ffmpeg 库创建一个非常基本的视频播放器，并且我已经完成了所有解码和重新编码，但我仍然停留在音频视频同步上。
我的问题是，电影的音频和视频流以音频和视频进入 "bursts" 的方式混合（交织）（许多音频数据包，然后是并列的视频帧），就像这样， 每个数据包都有自己的时间戳:
A A A A A A A A V V V V A A A A A A A V V V V ...
A: decoded and re-encoded audio data chunk
V: decoded and re-encoded video frame
据说可以防止没有视频就需要处理太多音频，反之亦然。
现在我要解码"bursts"并及时发送到audio/video播放组件，我有点迷失了细节。
- 有"standard"strategy/paradigm/pattern面对这种问题吗？
- 是否有 tutorials/documentation/books 解释要使用的技术？
- 在编码良好的电影中，muxing 能走多远？
因为我不期待这样的事情：
AAAAAAAAAAA .... AAAAAAAAAAAAA x10000 VVVVVVVVVVVVVV x1000
audio for the whole clip followed by video
或者这个：
VVVVVVVVVVVV x1000 AAAAAAAAAAA...AAAAAAAAA x1000
all video frames followed by the audio
在编码良好的视频中发生（毕竟，防止这种极端情况就是混流的意义所在...）
谢谢！
UPDATE：由于我的描述可能不清楚，所以问题不在于流的方式，也不在于如何解码它们：整个 audio/video 解复用，解码，重新缩放和重新编码设置和声音，每个数据块都有自己的时间戳。
我的问题是如何处理解码后的数据，而不会导致缓冲区溢出和欠载，通常不会堵塞我的管道，所以我想这可能被认为是一个 "scheduling" 问题。
同步是容器的工作。每一帧都将带有 PTS/DTS 或 duration/CTS
的时间戳
我将详细说明@szatmary 的回答，我已将其正确标记为正确的，尽管我未能立即认出它是正确的。
请注意，这是我对他的回答的看法，我并不是在暗示他的意图，也许他的意思完全不同...
经过一番沉思，我得出的结论是
Sync is the job of the container.
可以解释为"don't waste too much time into gimmicks to schedule audio and video frames, since the container presents the data in a easy-to-consume-way already".
为了证明这一点，我调查了几个视频流，发现音频和视频数据 "bursts" 以允许这种方法的方式出现：
- 解码并保存所有音频数据，不要太担心即将到来的音频数据：没有足够的音频来减慢视频处理速度，或溢出 "reasonable" 缓冲区，对于足够数量的合理（这并不意味着我不采取预防措施防止溢出）。
- 解码每个视频帧，然后等到它出现的时候
之所以有效，是因为：
- 突发中的音频数据量很小，不会消耗太多内存或 CPU 时间，因此它可以在帧之间解码，即使它包含多个帧的周期
- 音频和视频 "bursts"（分别属于样本和帧）排列得很好，这意味着突发样本所涵盖的时间段几乎涵盖了后续突发帧的时间段。
其他一切都只是一个 "trivial matter of coding" ;-)
我正在使用 ffmpeg 库创建一个非常基本的视频播放器，并且我已经完成了所有解码和重新编码，但我仍然停留在音频视频同步上。
我的问题是，电影的音频和视频流以音频和视频进入 "bursts" 的方式混合（交织）（许多音频数据包，然后是并列的视频帧），就像这样， 每个数据包都有自己的时间戳:
A A A A A A A A V V V V A A A A A A A V V V V ...
A: decoded and re-encoded audio data chunk
V: decoded and re-encoded video frame
据说可以防止没有视频就需要处理太多音频，反之亦然。
现在我要解码"bursts"并及时发送到audio/video播放组件，我有点迷失了细节。
- 有"standard"strategy/paradigm/pattern面对这种问题吗？
- 是否有 tutorials/documentation/books 解释要使用的技术？
- 在编码良好的电影中，muxing 能走多远？
因为我不期待这样的事情：
AAAAAAAAAAA .... AAAAAAAAAAAAA x10000 VVVVVVVVVVVVVV x1000
audio for the whole clip followed by video
或者这个：
VVVVVVVVVVVV x1000 AAAAAAAAAAA...AAAAAAAAA x1000
all video frames followed by the audio
在编码良好的视频中发生（毕竟，防止这种极端情况就是混流的意义所在...）
谢谢！
UPDATE：由于我的描述可能不清楚，所以问题不在于流的方式，也不在于如何解码它们：整个 audio/video 解复用，解码，重新缩放和重新编码设置和声音，每个数据块都有自己的时间戳。
我的问题是如何处理解码后的数据，而不会导致缓冲区溢出和欠载，通常不会堵塞我的管道，所以我想这可能被认为是一个 "scheduling" 问题。
同步是容器的工作。每一帧都将带有 PTS/DTS 或 duration/CTS
的时间戳我将详细说明@szatmary 的回答，我已将其正确标记为正确的，尽管我未能立即认出它是正确的。
请注意，这是我对他的回答的看法，我并不是在暗示他的意图，也许他的意思完全不同...
经过一番沉思，我得出的结论是
Sync is the job of the container.
可以解释为"don't waste too much time into gimmicks to schedule audio and video frames, since the container presents the data in a easy-to-consume-way already".
为了证明这一点，我调查了几个视频流，发现音频和视频数据 "bursts" 以允许这种方法的方式出现：
- 解码并保存所有音频数据，不要太担心即将到来的音频数据：没有足够的音频来减慢视频处理速度，或溢出 "reasonable" 缓冲区，对于足够数量的合理（这并不意味着我不采取预防措施防止溢出）。
- 解码每个视频帧，然后等到它出现的时候
之所以有效，是因为：
- 突发中的音频数据量很小，不会消耗太多内存或 CPU 时间，因此它可以在帧之间解码，即使它包含多个帧的周期
- 音频和视频 "bursts"（分别属于样本和帧）排列得很好，这意味着突发样本所涵盖的时间段几乎涵盖了后续突发帧的时间段。
其他一切都只是一个 "trivial matter of coding" ;-)