H323视频会议系统音视频同步原理.docx

H323视频会议系统音视频同步原理.docx

《H323视频会议系统音视频同步原理.docx》由会员分享，可在线阅读，更多相关《H323视频会议系统音视频同步原理.docx（9页珍藏版）》请在冰点文库上搜索。

H323视频会议系统音视频同步原理

H323视频会议系统音视频同步原理

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

针对H.323视频会议系统设计了一种基于RTP的音视频同步方法，该方法在严格遵守

RTP协议的前提下，将音视频数据联系起来通过同一个媒体通道传输，从而达到唇音同步

的目的。

实验表明：

该方法在对图像质量影响很小的情况下，很好地实现了音视频的同步

播放，并且具有实现简便，不增加系统负担等优点，具有广泛的实用性。

H.323视频会议系统中，发送端同时采集到的音视频数据能在接收端同时播放，则认

为唇音同步。

终端采集到的音视频数据肯定是同步的，要保证同时播放，就要保证音视频

在采集和播放处理过程中消耗的时间相同。

IP网络的特点决定了通过不同通道的音视频数

据传输所消耗的时间不可能完全相同，唇音同步是视频会议系统中的一大难题。

如果同时采

样的音视频数据播放时间偏差在[-80ms,+80ms]以内，用户基本上感觉不到不同步，一

旦超出[-160ms,+160ms],用户就可以明显感觉到，中间部分是临界范围。

1引言

放。

这类方法的实现需要一个中立的第三方参

考时钟，需要有RTCP协议的SR[2,3]的参与，如果这两个条件不具备，同步就失去了依

据。

思路二，唇音不同步本质上是由H.323视频会议系统中音视频的分开传输和处理导致

的，如果采用某种方法将音视频信息关联起来，就可以有效的避免不同步现象。

一种实现方

案是，将音频按一定的对应关系嵌入到视频中传输，接收端从视频中提取音频数据并重建，

从而达到唇音同步的目的[4].该方案实现较复杂，而且采用非标准的RTP实现方式，会给

不同厂商H.323产品间的互通带来困难。

3一种新的音视频同步方法

本方法基本思路是：

在音视频数据的采样、编码、打包、发送、网络传输、接收、网络

异常处理、拆包、解码、播放这十个处理过程中，采集、编码、打包、拆包和解码的时间

基本上固定，不会因为网络环境差异造成时延的差异，而发送、网络传输、接收、网络异常

处理四个过程则具有较大的随机性，其处理时间会随着网络性能的不同有较大的差异，进

而造成播放时音视频的不同步。

因此唇音同步处理的重点就在于保证发送、网络传输、接

收、网络异常处理这四个过程中音视频的同步，即图1中发送同步到组帧同步之间的部分。

图1唇音同步实现全过程

其他处理过程引起的时间差，只要在系统稳定后给音频加上固定的延时即可，因为一般

情况下，音频处理所花的时间比视频处理少，具体的差值可多次实验统计得到。

RTP协议规定每个RTP包中所承载的有效载荷类型（PT）是唯一的，但是如果将音

视频通过同一个通道传输，并且保证同一时刻采集到的音视频帧顺次交错发送，则既能保证

音视频在传输中的同步，又遵守了RTP协议。

音频数据量较小，一个RTP包即能承载一

帧，一个视频帧则需要多个RTP包承载，帧结束标志采用RTP包头中的Mark字段，该

字段为1,则说明当前包是一帧的结束包。

依据上述思想，方案具体实现过程设计如下：

（1）发送端分别独立的对音视频信息进行采样，组帧和打包，然后放到各自的缓冲

队列中等待发送

（2）数据发送模块从发送缓冲中取数据，1）从音频缓冲队列中取一个

包（一帧）；2）从视频缓冲队列中取数据，每取一个包，都判断RTP包头的Mark字段

是否为1,如果为1,说明当前视频帧已经取完，转1），如果Mark字段为0,说明当前视频帧

还未取完，转2）；（3）音视频数据通过同一个通道发送到网络；（4）接收端收到数据，

根据包头中的PT字段区分音视频，放到各自的接收缓冲队列中进行请求丢包重传、乱序重

排等网络异常处理[5,6],然后进入组帧缓冲等待解码器取走数据，进入组帧缓冲的数据没

有乱序包和重包，偶有丢包；（5）音视频各自拆包组帧，实现过程如图2所示：

图2组帧同步实现原理图。

（6）音视频从各自的解码缓冲队列中按顺序取数据送解码，通过组帧过程中给音视

频数据加上的本地时戳来校准后同步播放。

丢包判断实现细节说明：

在终端的可靠性和代码的健壮性得到保证的前提下，发送端是不可能有包序号不连续

的，对于接收端，本方案中的丢包，是指经过丢包重传等网络异常处理策略之后依然存在

的丢包，必然是及其少量的。

本方法中的音频采样、组帧和打包是分开处理的，即音视频

RTP包号分别连续，所以一般情况，依据各自的包序号即可判断是否有丢包。

而对于一个

会话中收到的第一个媒体包即丢失的情况，一旦出错，可能导致音视频播放时间整体错位。

本文通过发送端所加的RTP包头中的时戳来避免这种情况，时间戳的计算公式如下：

Timestamp（0）=（unsignedlong）rand（）；

Timestamp（t）=Timestamp（0）+△T*freq/1000;

△T=T（t）–T（0），时间差，单位：

ms;freq:

采样频率；

H.323视频会议中，与会各方的编解码协议、采样率、帧率等参数在打开通道后的能

力协商阶段即已确定，要改变这些参数，必然要重新能力协商，而任何时候应用层都知道

协商的结果。

所以只要规定一个会话中发送的头一个音频包和头一个视频包的时戳相同，即

可由时戳来建立音视频包的对应关系。

实际上，视频数据头一帧的图像分成多个包传输，

这几个包具有相同的时戳，同时丢失的可能性很小。

而且视频组帧解码过程中，还要分I帧、

P帧和B帧区别处理，比如每个GOP中只要I帧丢失，其后的P帧和B帧都必须丢弃，

直到收到下一个I帧，这已经超出了本文的研究范围，此处不再详述。

4理论分析和结果验证

理论上讲，采用本方法后，在网络状态良好时能做到音视频传输中的完全同步。

网络状

态恶化时，随着丢包率的增加，同步效果会稍微变差，其中随机丢包比周期丢包对同步效

果的影响更明显，这是因为随机丢包会引起更多的网络抖动。

而在帧率码率和编解码协议不

变的情况下。

带宽越小，网络越容易拥塞，所以带宽降低时同步效果也会变差。

将本方案应用在开源的H.323协议栈OPENH323上[7],实现了一个简单的基于PC

机的H.323桌面终端。

两台终端建立会话，通过IPcloud在两台终端间模拟各种复杂恶

劣的网络环境，然后使用Wireshark抓包，可以看到音视频包的发送接收时间以及有关包

头信息，进而计算出传输中引起的音视频偏差时间。

考虑到算法的复杂度，本方案选择了相

对较易实现的H.261和GSM6.10作为音视频编解码协议。

图3是呼叫建立后在发送端

10.21.11.121上截的图。

发送端敲击麦克风，接收端看到敲击动作的同时听到敲击声，

同步效果良好。

图3验证平台--终端互通实现效果图。

终端10.21.11.121在正常网络环境下，以512k的带宽呼叫终端10.21.11.152,呼

叫建立5分钟之后用Wireshark抓到的音视频数据包如图4和图5所示：

图4发送端音视频数据抓包。

图5接收端音视频数据抓包。

随机选取了20个这样的音视频组合，测得传输引起的音视频时间差值，求的平均值为

0.000051s,即51μs.可以认为，在正常情况下，传输阶段不会引起失步。

多次改变呼叫带宽和网络丢包率，反复试验，得到的不同环境下由传输引起的音视频时

间差如表1所示。

表1不同环境下由传输引起的音视频时差（单位：

μs）。

由表1中的数据可以看出，随着丢包率的增大，音视频失步有所增加。

并且相同丢包

率下，随机丢包对同步效果的影响更明显，这和理论分析的结果完全吻合。

但是即便在播放

阶段还有2%丢包这样恶劣的环境下，传输引起的音视频时间差仍然低于1000us.

即：

该方法将[-80ms,+80ms]的同步范围的159/160留给音视频处理和组帧解码

阶段。

理论上讲，低带宽高丢包环境下，使用该方法后视频质量会有所下降。

这是因为，本文

的算法增加了视频帧被丢弃的概率。

如图4所示，每个CIF格式的视频帧需要4个H.261

的RTP包来传输，其中任意一个包丢失都会使该帧成为无用帧被丢弃。

采用了本文的同步

策略后，如果该视频帧对应的音频包丢失，该帧也会被丢弃。

这一点可以根据系统的实际

需求做出取舍，比如用前一个包的重复播放来代替丢掉的音频包，而这样会增加音频播放的

滞顿感。

这些问题正在进一步研究中。

5结语

本方法最大的亮点在于很好的实现了音视频同步的同时，最大程度的遵守了RTP协议

和H.323标准。

此外，该方法实现简便、可以和现有的唇音同步方案同时使用、并且不会额外增加系统

的负担，具有很大的实用价值__