H323视频会议系统音视频同步原理Word下载.docx
- 文档编号:21168165
- 上传时间:2023-01-28
- 格式:DOCX
- 页数:9
- 大小:276.68KB
H323视频会议系统音视频同步原理Word下载.docx
《H323视频会议系统音视频同步原理Word下载.docx》由会员分享,可在线阅读,更多相关《H323视频会议系统音视频同步原理Word下载.docx(9页珍藏版)》请在冰豆网上搜索。
思路一,发送端给每个要发送的RTP包打上时
增加延时等方式,保证同时釆样的数据同时播
放。
这类方法的实现需要一个中立的第三方参考时钟,需要有RTCP协议的SR[2,3]的参与,如果这两个条件不具备,同步就失去了依据。
思路二,唇音不同步本质上是由H.323视频会议系统中音视频的分开传输和处理导致的,如果采用某种方法将音视频信息关联起来,就可以有效的避免不同步现象。
一种实现方案是,将音频按一定的对应关系嵌入到视频中传输,接收端从视频中提取音频数据并重建,从而达到唇音同步的目的[4].该方案实现较复杂,而且釆用非标准的RTP实现方式,会给不同厂323产品间的互通带来困难。
3—种新的音视频同步方法
本方法基本思路是:
在音视频数据的采样、编码、打包、发送、网络传输、接收、网络异常处理、拆包、解码、播放这十个处理过程中,釆集、编码、打包、拆包和解码的时间基本上固定,不会因为网络环境差异造成时延的差异,而发送、网络传输、接收、网络异常处理四个过程则具有较大的随机性,其处理时间会随着网络性能的不同有较大的差异,进
而造成播放时音视频的不同步。
因此唇音同步处理的重点就在于保证发送、网络传输、接
收、网络异常处理这四个过程中音视频的同步,即图1中发送同步到组帧同步之间的部分。
图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所示:
r->
图2组帧同步实现原理图。
(6)音视频从各自的解码缓冲队列中按顺序取数据送解码,通过组帧过程中给音视频数据加上的本地时戳来校准后同步播放。
丢包判断实现细节说明:
在终端的可靠性和代码的健壮性得到保证的前提下,发送端是不可能有包序号不连续的,对于接收端,本方案中的丢包,是指经过丢包重传等网络异常处理策略之后依然存在
的丢包,必然是及其少量的。
本方法中的音频釆样、组帧和打包是分开处理的,即音视频
RTP包号分别连续,所以一般情况,依据各自的
包序号即可判断是否有丢包。
而对于一个会话中收到的第一个媒体包即丢失的情况,一旦出错,可能导致音视频播放时间整体错位。
本文通过发送端所加的RTP包头中的时戳来避
免这种情况,时间戳的计算公式如下:
Timestamp(t)=Timestamp(O)+AT*freq/1000;
△T=T(t)•采样频率;
-T(0),时间差,单位:
ms;
freq:
H.323视频会议中,与会各方的编解码协议、采样率、帧率等参数在打开通道后的能
力协商阶段即已确定,要改变这些参数,必然要重新能力协商,而任何时候应用层都知道协商的结果。
所以只要规定一个会话中发送的头一个音频包和头一个视频包的时戳相同,即可由时戳来建立音视频包的对应关系。
实际上,视频数据头一帧的图像分成多个包传输,这几个包具有相同的时戳,同时丢失的可能性很小。
而且视频组帧解码过程中,还要分I帧、P帧和B帧区别处理,比如每个GOP中只要I帧丢失,其后的P帧和B帧都必须丢弃,直到收到下一个I帧,这已经超出了本文的研究范围,此处不再详述。
4理论分析和结果验证
理论上讲,采用本方法后,在网络状态良好时能做到音视频传输中的完全同步。
网络状
态恶化时,随着丢包率的增加,同步效果会稍微变差,其中随机丢包比周期丢包对同步效果的影响更明显,这是因为随机丢包会引起更多的网络抖动。
而在帧率码率和编解码协议不变的情况下。
带宽越小,网络越容易拥塞,所以带宽降低时同步效果也会变差。
将本方案应用在开源的H.323协议栈0PENH323上[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所示:
5672OM-09-1714:
53:
01.02578M10.21.11.12110.21.11.15.2H.261h.261mes-sag
5«
9200^-09-1714;
58:
<
XL.03170S10.21.12»
1211O.21.1X.15>
2H.Z^lH.261messaq
5702009-09-1714:
58:
01・03819410.21.11.12110.21.11.152H.261H.261messag
5712OW-09-1714:
01.04568110.21.11.12110.21.ll.li2RTPPTMSM0&
・L0
•566(1075byresonMr®
107sbyresed)
•Eihernern,src:
EllTegro_bl:
16:
18C00:
le:
90:
bl:
16:
18),ost:
ElitegroJjf:
!
•internetproto<
olrSr<
:
10.21.11.121(10.21.11.121).dst:
10.21.11.152(10.21.
•userDaiagramprotocolsrcPorx:
Ix1«
evrii5vc(5M4)WD5tport:
rf@(5002)
•Real-TimeTransportprotocol
♦[StreamsetupbyH245(frame556)]
IO......-verj^Qp;
rpc1689versionC2)
・・0=Padding:
FaHe
...0••••=Extension;
Filse
・・・・0000=Contributingsourceidentnf-ierscount:
0
Q«
>
4=Harker:
False
PayloadType:
ITli-TH.261(31)
sequencenumber;
9903
[Extendedsequencenutiber:
75439^]
TlmesTamp:
6006
SvrkzhrcnHzzmrfcnsourceId^nrifler:
0xQclr4ee66f?
&
5OO747?
6^
图4发送端音视频数据抓包。
Tine
Source
Dcsliititioa
Frotoc©
l
Info
•40
10.21.12.121
10.21.11.152
H・26L
H.262messa«
nct®
fflGa2£
ti5ittnripiwutkt・甲秤|0匚;
~1一!
?
用.”Tnrmpm・ii□n
43
203-09-17
14158!
0L.382844
10.21.11.121
10.21.11.1S2
H.26L
R.261messai
05
200^-09-17
14:
58:
01・38976M
H.261
262messa«
-46
2OQH7
14:
58;
XL.395141
14:
01.402770
10・21・11»
121
1*Q«
21«
U«
1S2
Ht261
h.?
61rnessai
47
10.21.11^121
RTP
••
Pl-GSM06.H
J“—
♦Frame42(1075bytesonwiref1075bytescaptured)
♦Ethernetu,src:
El1ttgro.bl:
l6:
l8(OO:
le:
9O:
18),osr:
ElltegroJjf:
da:
*5a
1;
inT^rn^pguxol.LQ,3LtUan观总<
X0r?
l^U
♦userDatagramProtocol.£
rcPort!
Ix1-svntsvc(5044).DstPort!
rfe(5002)
-Real-TimeTransportProtocol
-[StreamsetupbyH245Cframe523]
「5ETUD于广“me;
321
[setupweihod:
H245]
IO・version:
RFC1889version
(2)
••0»
PaddingIraise
...0....*Extension;
・■・・0000・CGntr»
but1ngsourceidentifierscountr0
0-Marker;
Payloadtyp*:
Iiu-TH.261C31)
Sequencenunber:
99Q3
图5接收端音视频数据抓包。
随机选取了20个这样的音视频组合,测得传输
引起的音视频时间差值,求的平均值为
0.000051s,BP51US.可以认为,在正常情况下,传输阶段不会引起失步。
多次改变呼叫带宽和网络丢包率,反复试验,得到的不同环境下由传输引起的音视频时间差如表1所示。
表1不同环境下由传输引起的音视频时差(单位:
Us)o
由表1中的数据可以看出,随着丢包率的增大,音视频失步有所增加。
并且相同丢包率下,随机丢包对同步效果的影响更明显,这和理论分析的结果完全吻合。
但是即便在播放
阶段还有2%丢包这样恶劣的环境下,传输引起的音视频时间差仍然低于lOOOus.
即:
该方法将[-80ms,+80ms]的同步范围的159/160留给音视频处理和组帧解码阶段。
理论上讲,低带宽高丢包环境下,使用该方法后视频质量会有所下降。
这是因为,本文的算法增加了视频帧被丢弃的概率。
如图4所示,每个CIF格式的视频帧需要4个H.261的RTP包来传输,其中任意一个包丢失都会使该帧成为无用帧被丢弃。
采用了本文的同步策略后,如果该视频帧对应的音频包丢失,该帧也会被丢弃。
这一点可以根据系统的实际需求做出取舍,比如用前一个包的重复播放来代替丢掉的音频包,而这样会增加音频播放的滞顿感。
这些问题正在进一步研究中。
5结语
本方法最大的亮点在于很好的实现了音视频同步的同时,最大程度的遵守了RTP协议和H.323标准。
此外,该方法实现简便、可以和现有的唇音同步方案同时使用、并且不会额外增加系统
的负担,具有很大的实用价值_
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- H323 视频会议系统 视频 同步 原理