[转]音频视频同步

本篇文章转自吉林大学硕士论文。

5.5接收端音视频的同步控制
5.5.1媒体内同步控制算法
为保证媒体内同步性，对音频，采用基于播放时限的同步方法，在接收终端设置音频接收缓冲区(Jitter buffer)。缓冲区设定一个门限值M，该值比预计最长抖动时间要大。门限值M的大小可通过公式5.1计算：

其中，d_{max 、}d_min 分别是媒体单元通过网络的最大、最小延迟，r为数据传输速率。在系统接收端，开始时，语音数据在缓存中积累，直到缓存大小达到M。然后才可提取播放。对视频流，为更利于达到媒体间同步，正常情况下，采用到达事件驱动的方式播放视频流，而不采用定时读取的方式。
5.5.2媒体间同步控制算法
系统中各媒体流采用的是虚轴(virtual axes)模型，即音视频流有各自的时间轴，发送时各帧打上相对时间戳(RTS)。考虑两个流，一个主流，一个从流，主流连续播放，从流的播放由主流的播放状态决定，从而实现同步。对于音频流和视频流，由于听觉对声音的不连续比视觉对图像不连续的敏感程度要高，因而选择音频流为主流，视频流为从流，音频流连续播放。通过调整视频播放过程实现媒体间同步控制。当RTP帧到达接收端后，随后被送至相应的解码器进行解码。由于每个数据帧的复杂度不相同，因此不可能精确知道解压缩所消耗的时间。此处采用两种方案，并对两种方案分别进行讨论。方案一：计算延迟抖动时未进行解压，解压时间不作为网络延迟的一部分，这样延抖动可以真正反映网络拥塞情况，如图5-7所示；方案二：为准确地控制回放时间，数据包在进行同步之前应由软件解码器进行解压缩。这样解压缩时间作为网络延迟的一部分，解压后的时间作为数据包的到达时间。

按照方案一系统音视频同步播放过程及视频播放算法如下：
1．首先，回放开始时，定时从音频缓冲区中取出语音包，送入音频设备播放，并记录当前播放帧的时间戳T_play。这样做的好处是考虑语音的敏感性(这里暂不考虑音频播放的时间)。同时当新的音频数据分组到达，被加到缓存中时，只要没有分组的时延超过M（见5.5.1）个缓存单元，缓存中就有足够的数据用于连续播放。
2．视频帧到达时，把该帧的时间戳T_v与T_play比较。规定音视频帧不同步的容忍度为T_av=120ms。若T_play-T_av≤T_v≤T_play+T_av，就播放该视频帧。若T_v<T_play-T_av，视频帧滞后，就丢弃该帧。若T_v>T_play+T_av，视频帧超前，重复播放前一帧，等待下一次定时读取音频帧时再处理。3．这里音频的播放速率一定，不考虑终端工作负载的变化。若用缓存的方式来读取视频数据，当画面出现高速运动的物体时，数据会大量缓冲，造成画面出现严重的块效应，因此，正常情况下，采用到达事件驱动的方式播放视频流，而不采用定时读取的方式。为了防止音频流失步时，出现视频流数据丢弃较为严重的现象，系统中必须优先保证音频流的同步，并且能够连续播放。视频处理算法如下：
HandVideoFameArrival：//视频帧到达
if(getVideoFrame(v)//取出视频帧
{
    If（T_v<T_play-T_av）//滞后，丢弃；
    else if(T_v>T_play+T_av)//超前；
   {
     VideoFrameWaitNum++；//缓存区待处理数据包数目加1
     play(last_v);
   }
   else play(v)//音视频同步，播放视频
}
音频处理算法如下：
HandleAudioFrameTime：//定时时间到
getAudioFrame(a)；//取出音频帧
Aplay=getCurrentPlayingAudioTimestamp；//得到正在播放的音频帧时间戳
play(a)；//送入音频设备播放
对方案二，同步控制见流程图5-8，视解码时间为网络时延的一部分，考虑到媒体数据解码时无法保留RTP包头信息，特别是时间戳信息，故而在处理RTP包的同时将时间戳信息提取保存，其它步骤同方案一。