飞上天的鱼
发表于 2006-9-4 23:31:00
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?快速注册
x
怎么实现网络监控中的视频音频同步5 {# e6 |0 p/ }0 n
! }. Q' Z. T- q% U, q1 u1 Z 怎么实现网络监控中的视频音频同步,这个跟设备本身有关系,小编从以下几个方面为大家介绍。) }/ `- B$ S# k* F# f: k
3 ~" c& w; w7 V7 c# ]
怎么实现网络监控中的视频音频同步一、音视频同步问题概述: 音视频同步问题是可视对讲中的重点需要解决的问题之一,也是一直以来被模拟门禁产品厂商攻击的一个弱点,因为模拟可视对讲产品都采用专线传输,不存在这个问题。解决同步问题的方法有很多种,其中时间戳是最成熟最完美也是最复杂的解决办法,可以解决任何多媒体领域的音视频同步问题;其原理是选择一个参考时间,在生成数据流时依据参考时间上的时间给每个数据块都打上时间戳;在播放时,读取数据块上的时间戳,同时参考当前时钟上的时间来安排播放,让快于这个参考时间的包等待,丢弃慢于这个参考时间的包。 在基于时间戳的同步机制中,仅仅对不同步的数据进行处理是不完备的,还需要反馈机制,如基于Windows平台的DirectShow就提供这样一个反馈机制,它的质量控制(Quality Control)可以将播放的状态反馈给源,让源端加快或者放慢数据流的速度。
7 L% a4 U; {: e* R
8 k' Z0 G% s+ q5 h 在多媒体文件采集,播放及对同步的要求都非常严格,如果从多媒体文件中分离出音视频数据的数据不同步,音视频的时间差则会越来越大,这是无法忍受的,所以在多媒体文件中,不但要求有同步机制,还要求有反馈机制。
3 x' I- p0 |. } K1 z7 G" z: D
, g8 T$ m. B( A8 A) r: M) h 怎么实现网络监控中的视频音频同步二、数字可视对讲中的音视频同步方案
0 X) _3 Z0 Q d1 h- V! w ' K4 X. O6 A; n( H) w
在数字可视对讲中,可以考虑的音视频同步方案有两种:一是发送端解决;二是接收端解决。 . W4 d0 b/ E( c0 W
9 C/ j- t9 E% i* \% R4 x' ^, j4 k" H
发送端解决方法比较简单,具体措施是在发送端先将一段时间内采集到音视频数据打包。比如采集到一帧视频图像,将这帧图像与采集这帧视频的时间内采集到的视频数据打成一个包,接收端接收到这个包之后解包分别播放就可以了。发送端解决的控制方法比较简单,但是在高清要求清晰度比较高的情况下就不是很理想,清晰度高,意味着每个音视频包数据量就大,能保证同步,却难以保证连续。我们在同一个线程中按照先后顺序发送PCM音频和H.264视频,测试结果表明这种方法确实存在连续问题。 , q c, E0 F' `
; W3 \; w, |6 _9 s 接收端解决方案绕不开的问题是时间戳,接收端根据接收到的音视频数据的时间戳安排播放。时间戳需要一个参考时间,而采集过程中视频的时间是不定的,数字摄像头采集图像的帧率是一个平均值,不宜用来做参考时间,所以只能用音频时间作为参考时间。 ( m# D; m' r, u+ _% ?# m" ]* s
8 ~& r, I9 t- T8 h, ^: @ 怎么实现网络监控中的视频音频同步三、声卡编程和声卡驱动的时间机制
: p$ x) U `4 R9 _) ?9 e5 ~
3 D+ D% a# X" O' D {0 Y 门禁可视对讲中音频是双向的。本文的门禁可视对讲方案中,音频的采用PCM(Pulse Code Modulation——脉码调制录音)采集,在网络中传送的也是原始数据,之所以没有对音频数据进行编码处理是基于以下原因:一是S3C6410没有提供对音频的硬编解码,如果使用软件实现编解码,在有限的系统资源条件下难以实现;二是音频数据量较小:采用8000采样率和量化位数为8位的电话语音标准,一秒的音频数据是8K字节,只相当于视频1帧数据的两倍,这对普遍拥有百兆网卡的局域网来说,数据量很小。实验的结果表明,这种简单的处理方式被证明是有效的。 " {2 z: ]) O+ z
$ R6 v# \0 f9 h( e- v2 x3 V- V" T6 P( R Linux操作系统下音频接口有/dev/dsp,/dev/audio,/dev/Mixer三种。前两种的属性基本相同,DSP是数字信号处理器(Digital Signal Processor)的简称,是用于数字采样(sampling)和数字录音(recording)的设备文件,它对于Linux下的音频编程来讲非常重要。向该设备写数据即意味着激活声卡上的D/A转换器进行放音,而向该设备读数据则意味着激活声卡上的A/D转换器进行录音。目前许多声卡都提供有多个数字采样设备。/dev/audio属性与dsp类似,但更多的用于sun的工作站中,为兼容性考虑,应用中一般使用/dev/dsp作为音频接口。mixer为混音器,也是声卡设备中相当重要的一部分,它的作用是将多个信号组合或者叠加到一起,但对应用程序来说,这些都无需考虑,但可以通过这个接口调节声卡播放时声音的大小等参数。 |0 Y' _4 z8 u9 g, U
) F7 \- ^% G: T4 x- D' X, }9 Y
无论是Linux下还是Windows下,声卡的编程接口都是由声卡驱动提供的,而驱动都是会考虑到时间机制的,其表现形式就是当声卡驱动没有装好时,使用播放器播放多媒体文件时声音以极快的速度过去了,但是声卡驱动装好之后就很正常了,本文的音视频同步解决方案即以此为基础。
% x4 b$ G$ F. r2 ]) d
' P) l! W0 k. I1 }% s* ]7 M( J/ b% t 怎么实现网络监控中的视频音频同步四、基于音频时间机制的音视频同步解决方案
! _9 W3 n1 }' g3 z6 P ^: Y* h3 j
" h8 a& L* I- b 与文件形式的多媒体不同的是,可视对讲中音视频流的源端是永远同步的。所以一种简单的解决方案是发送端启用独立的音频和视频线程,进行音视频采集,采集后只管往外发送数据,接收端接到数据就分别解码播放,从表面看,这种采用无同步机制多线程解决方案是可行的,但是忽略了一个问题,即音频数据包和视频数据包的大小。包的大小会影响网络传输的速度。这种差别在网络条件好的情况下显示不出来,一旦遇到网络拥塞或者其他情况就会变得很明显。 - c' W2 R" z4 Q! W: d' n) m# }
7 E: A2 D7 k- p1 P2 _
根据对音频采集和处理的叙述,我们知道,音频的采集是有时间机制的。比如采样率是8000,采样位数是8,我们就可以算出采8K字节的数据所用的时间是1s,这样音频就可以按照自己的速度播放;而摄像头每秒采集的帧数是相对固定的,如OV9650采集速度为平均每秒30帧,这样即可以算出1/30秒(约为0.03333,具体精度可以根据要求决定)刷新一帧图片,这种方式中只要保证源端音频视频的采集是同步的就可以,而门禁对讲过程中,这种同步是原生的。0 q" l' X# J+ E N
* W! G3 j& B4 B/ U8 l3 O4 j8 X 发送端分别用线程采集音视频数据,采集的同时根据RTP协议的规定分别将这些数据打上时间戳,然后通过RTP底层协议(如UDP)发送出去。
5 T" S) w# n: C# H6 |: f / V7 e! i% N1 j( I
接收端接收到音频数据,直接交给声卡播放,当前播放的音频包的时间戳时间传送给视频线程;接收到视频帧,则将其时间戳时间与当前播放的音频时间戳进行比较,若未达到参考时间,则解码播放;若达到参考时间,则说明该视频帧滞后,丢弃该视频帧,接收下一个视频帧,循环往复,直到线程接收到结束命令停止;以上述音频采样率和采样位数为例,视频参考时间的计算方法为(以C语言格式的?号表达式表示): : A/ X' M3 e3 u" X5 Z1 F
$ a. P. O$ e4 n% h0 B4 } 音频时间戳时间 +1/30> 视频时间戳时间+丢弃:播放; , L$ o! b. A' G! c" ^
3 c2 N% [& m; W$ h1 t7 q 在编程实现时,采集端和播放端的音频和视频可采用独立的线程,并利用Qt的信号槽机制实现音视频线程时间戳的传递,此处不再赘述。 |
|
|
|
|