《音视频同步》由会员分享，可在线阅读，更多相关《音视频同步（2页珍藏版）》请在装配图网上搜索。
1、音视频同步-时间戳媒体内容在播放时，最令人头痛的就是音视频不同步。从技术上来说，解决音视频同步问题的最佳方案就是时间戳：首先选择一个参考时钟（要求参考时钟上的时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，同时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；如果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者索性将这块数据“丢弃”，以使播放进度追上参考时钟）。可见，避免音视频不同步现象有两个关键
2、一是在生成数据流时要打上正确的时间戳。 如果数据块上打的时间戳本身就有问题，那么播放时再怎么调整也于事无补。如图2.8，视频流 内容是从0s开始的，假设10s时有人开始说话，要求配上音频流，那么音频流的起始时间应该 是10s,如果时间戳从0s或其它时间开始打，则这个混合的音视频流在时间同步上本身就出了 问题。打时间戳时，视频流和音频流都是参考参考时钟的时间，而数据流之间不会发生参考关 系；也就是说，视频流和音频流是通过一个中立的第三方（也就是参考时钟）来实现同步的。 第二个关键的地方，就是在播放时基于时间戳对数据流的控制，也就是对数据块早到或晚到采 取不同的处理方法。图2.8中，参考时钟时间在
3、0-10s内播放视频流内容过程中，即使收到了 音频流数据块也不能立即播放它，而必须等到参考时钟的时间达到10s之后才可以，否则就会 引起音视频不同步问题。基于时间戳的播放过程中，仅仅对早到的或晚到的数据块进行等待或快速处理，有时候是 不够的。如果想要更加主动并且有效地调节播放性能，需要引入一个反馈机制，也就是要将当 前数据流速度太快或太慢的状态反馈给“源”，让源去放慢或加快数据流的速度。熟悉 DirectShow的读者一定知道，DirectShow中的质量控制（Quality Control ）就是这么一个反 馈机制。DirectShow对于音视频同步的解决方案是相当出色的。但WMF SDK在
4、播放时只负责将 ASF数据流读出并解码，而并不负责音视频内容的最终呈现，所以它也缺少这样的一个反馈机制。为了更好地理解基于时间戳的音视频同步方案，下面举一个生活中的例子。假设你和你的 一个朋友约好了今天18:00在沪上广场见面，然后一起吃饭，再去打游戏。实际上，这个18:00 就是你和你朋友保持同步的一个时间点。结果你17:50就到了沪上广场，那么你必须等你的朋 友。 10分钟过后，你的朋友还没有到，这时他打来电话说有事耽搁了，要晚一点才能到。你没 办法，因为你已经在旁边的餐厅预订了位置，如果不马上赶过去，预订就会被取消，于是你告 诉你的朋友直接到餐厅碰头吧，要他加快点。于是在餐厅将来的某个时间点就成为你和你朋友 的又一个同步点。虽然具体时间不定（要看你朋友赶过来的速度），但这样努力的方向是对的， 你和你朋友肯定能在餐厅见到面。结果呢？你朋友终于在 18:30赶过来了，你们最终“同步” 了。吃完饭 19:30 了，你临时有事要处理一下，于是跟你朋友再约好了 20:00 在附近的一家游 戏厅碰头。你们又不同步了，但在游戏厅将来的某个时间点你们还是会再次同步的。悟出什么道理了没有？其实，同步是一个动态的过程，是一个有人等待、有人追赶的过程。 同步只是暂时的，而不同步才是常态。人们总是在同步的水平线上振荡波动，但不会偏离这条 基线太远。
音视频同步
