h.323视频会议系统音视频同步原理

《h.323视频会议系统音视频同步原理》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、H.323视频会议系统音视频同步原理针对H.323视频会议系统设计了一种基于RTP的音视频同步方法，该方法在严格遵守RTP协议的前提下，将音视频数据联系起来通过同一个媒体通道传输，从而达到唇音同步的目的。实验表明：该方法在对图像质量影响很小的情况下，很好地实现了音视频的同步播放，并且具有实现简便，不增加系统负担等优点，具有广泛的实用性。H.323视频会议系统中，发送端同时采集到的音视频数据能在接收端同时播放，则认为唇音同步。终端采集到的音视频数据肯定是同步的，要保证同时播放，就要保证音视频在采集和

2、播放处理过程中消耗的时间相同。IP网络的特点决定了通过不同通道的音视频数据传输所消耗的时间不可能完全相同，唇音同步是视频会议系统中的一大难题。如果同时采样的音视频数据播放时间偏差在[-80ms,+80ms]以内，用户基本上感觉不到不同步，一旦超出[-160ms,+160ms],用户就可以明显感觉到，中间部分是临界范围。1引言1.1文章安排本文第2节分析了现有的音视频同步方案的缺点。第3节详细描述了本文所设计方案的实现过程。第4节给出实验数据以及分析结果。第5节给出结论。1.2基本介绍H.323视频

3、会议系统中，音视频不同步现象产生的原因除了网络环境外，还有一个是音视频的分开传输。虽然H.323建议音视频通过不同道道传输，但是实际传输数据的RTP[2,3]协议和其底层的UDP协议都没有规定一对连接只能传输音频或者视频中的一种，通过同一个通道传输音视频完全可能，而且这样可以最大程度的减少网络原因引起的音视频不同步，本文给出了这一设想的实现方案，并做了验证。2现有解决方案目前最常用的唇音同步方法从思路上可以分为以下两类：思路一，发送端给每个要发送的RTP包打上时戳，记录它们的采样时间。接收端通过增

4、加延时等方式，保证同时采样的数据同时播放。这类方法的实现需要一个中立的第三方参考时钟，需要有RTCP协议的SR[2,3]的参与，如果这两个条件不具备，同步就失去了依据。思路二，唇音不同步本质上是由H.323视频会议系统中音视频的分开传输和处理导致的，如果采用某种方法将音视频信息关联起来，就可以有效的避免不同步现象。一种实现方案是，将音频按一定的对应关系嵌入到视频中传输，接收端从视频中提取音频数据并重建，从而达到唇音同步的目的[4].该方案实现较复杂，而且采用非标准的RTP实现方式，会给不同厂商H.

5、323产品间的互通带来困难。3一种新的音视频同步方法本方法基本思路是：在音视频数据的采样、编码、打包、发送、网络传输、接收、网络异常处理、拆包、解码、播放这十个处理过程中，采集、编码、打包、拆包和解码的时间基本上固定，不会因为网络环境差异造成时延的差异，而发送、网络传输、接收、网络异常处理四个过程则具有较大的随机性，其处理时间会随着网络性能的不同有较大的差异，进而造成播放时音视频的不同步。因此唇音同步处理的重点就在于保证发送、网络传输、接收、网络异常处理这四个过程中音视频的同步，即图1中发送同步到

6、组帧同步之间的部分。图1唇音同步实现全过程其他处理过程引起的时间差，只要在系统稳定后给音频加上固定的延时即可，因为一般情况下，音频处理所花的时间比视频处理少，具体的差值可多次实验统计得到。RTP协议规定每个RTP包中所承载的有效载荷类型（PT）是唯一的，但是如果将音视频通过同一个通道传输，并且保证同一时刻采集到的音视频帧顺次交错发送，则既能保证音视频在传输中的同步，又遵守了RTP协议。音频数据量较小，一个RTP包即能承载一帧，一个视频帧则需要多个RTP包承载，帧结束标志采用RTP包头中的Mark字

7、段，该字段为1,则说明当前包是一帧的结束包。依据上述思想，方案具体实现过程设计如下：（1）发送端分别独立的对音视频信息进行采样，组帧和打包，然后放到各自的缓冲队列中等待发送（2）数据发送模块从发送缓冲中取数据，1）从音频缓冲队列中取一个包（一帧）；2）从视频缓冲队列中取数据，每取一个包，都判断RTP包头的Mark字段是否为1,如果为1,说明当前视频帧已经取完，转1），如果Mark字段为0,说明当前视频帧还未取完，转2）；（3）音视频数据通过同一个通道发送到网络；（4）接收端收到数据，根据包头中的P

8、T字段区分音视频，放到各自的接收缓冲队列中进行请求丢包重传、乱序重排等网络异常处理[5,6],然后进入组帧缓冲等待解码器取走数据，进入组帧缓冲的数据没有乱序包和重包，偶有丢包；（5）音视频各自拆包组帧，实现过程如图2所示：图2组帧同步实现原理图。（6）音视频从各自的解码缓冲队列中按顺序取数据送解码，通过组帧过程中给音视频数据加上的本地时戳来校准后同步播放。丢包判断实现细节说明：在终端的可靠性和代码的健壮性得到保证的前提下，发送端是不可能有包序号不连续的，对于接收端，本方案中的丢包，