监控音视频同步如何实现？

这个跟设备本身有关系，一、音视频同步问题概述： 音视频同步问题是可视对讲中的重点需要解决的问题之一，也是一直以来被模拟门禁产品厂商攻击的一个弱点，因为模拟可视对讲产品都采用专线传输，不存在这个问题。解决同步问题的方法有很多种，其中时间戳是最成熟最完美也是最复杂的解决办法，可以解决任何多媒体领域的音视频同步问题；其原理是选择一个参考时间，在生成数据流时依据参考时间上的时间给每个数据块都打上时间戳；在播放时，读取数据块上的时间戳，同时参考当前时钟上的时间来安排播放，让快于这个参考时间的包等待，丢弃慢于这个参考时间的包。 在基于时间戳的同步机制中，仅仅对不同步的数据进行处理是不完备的，还需要反馈机制，如基于Windows平台的DirectShow就提供这样一个反馈机制，它的质量控制（Quality Control）可以将播放的状态反馈给源，让源端加快或者放慢数据流的速度。

在多媒体文件采集，播放及对同步的要求都非常严格，如果从多媒体文件中分离出音视频数据的数据不同步，音视频的时间差则会越来越大，这是无法忍受的，所以在多媒体文件中，不但要求有同步机制，还要求有反馈机制。

二、数字可视对讲中的音视频同步方案

在数字可视对讲中，可以考虑的音视频同步方案有两种：一是发送端解决；二是接收端解决。

发送端解决方法比较简单，具体措施是在发送端先将一段时间内采集到音视频数据打包。比如采集到一帧视频图像，将这帧图像与采集这帧视频的时间内采集到的视频数据打成一个包，接收端接收到这个包之后解包分别播放就可以了。发送端解决的控制方法比较简单，但是在高清要求清晰度比较高的情况下就不是很理想，清晰度高，意味着每个音视频包数据量就大，能保证同步，却难以保证连续。我们在同一个线程中按照先后顺序发送PCM音频和H.264视频，测试结果表明这种方法确实存在连续问题。

接收端解决方案绕不开的问题是时间戳，接收端根据接收到的音视频数据的时间戳安排播放。时间戳需要一个参考时间，而采集过程中视频的时间是不定的，数字摄像头采集图像的帧率是一个平均值，不宜用来做参考时间，所以只能用音频时间作为参考时间。

三、声卡编程和声卡驱动的时间机制

门禁可视对讲中音频是双向的。本文的门禁可视对讲方案中，音频的采用PCM（Pulse Code Modulation——脉码调制录音）采集，在网络中传送的也是原始数据，之所以没有对音频数据进行编码处理是基于以下原因：一是S3C6410没有提供对音频的硬编解码，如果使用软件实现编解码，在有限的系统资源条件下难以实现；二是音频数据量较小：采用8000采样率和量化位数为8位的电话语音标准，一秒的音频数据是8K字节，只相当于视频1帧数据的两倍，这对普遍拥有百兆网卡的局域网来说，数据量很小。实验的结果表明，这种简单的处理方式被证明是有效的。

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为混音器，也是声卡设备中相当重要的一部分，它的作用是将多个信号组合或者叠加到一起，但对应用程序来说，这些都无需考虑，但可以通过这个接口调节声卡播放时声音的大小等参数。

无论是Linux下还是Windows下，声卡的编程接口都是由声卡驱动提供的，而驱动都是会考虑到时间机制的，其表现形式就是当声卡驱动没有装好时，使用播放器播放多媒体文件时声音以极快的速度过去了，但是声卡驱动装好之后就很正常了，本文的音视频同步解决方案即以此为基础。

四、基于音频时间机制的音视频同步解决方案

与文件形式的多媒体不同的是，可视对讲中音视频流的源端是永远同步的。所以一种简单的解决方案是发送端启用独立的音频和视频线程，进行音视频采集，采集后只管往外发送数据，接收端接到数据就分别解码播放，从表面看，这种采用无同步机制多线程解决方案是可行的，但是忽略了一个问题，即音频数据包和视频数据包的大小。包的大小会影响网络传输的速度。这种差别在网络条件好的情况下显示不出来，一旦遇到网络拥塞或者其他情况就会变得很明显。

根据对音频采集和处理的叙述，我们知道，音频的采集是有时间机制的。比如采样率是8000，采样位数是8，我们就可以算出采8K字节的数据所用的时间是1s，这样音频就可以按照自己的速度播放；而摄像头每秒采集的帧数是相对固定的，如OV9650采集速度为平均每秒30帧，这样即可以算出1/30秒（约为0.03333，具体精度可以根据要求决定）刷新一帧图片，这种方式中只要保证源端音频视频的采集是同步的就可以，而门禁对讲过程中，这种同步是原生的。

发送端分别用线程采集音视频数据，采集的同时根据RTP协议的规定分别将这些数据打上时间戳，然后通过RTP底层协议（如UDP）发送出去。

接收端接收到音频数据，直接交给声卡播放，当前播放的音频包的时间戳时间传送给视频线程；接收到视频帧，则将其时间戳时间与当前播放的音频时间戳进行比较，若未达到参考时间，则解码播放；若达到参考时间，则说明该视频帧滞后，丢弃该视频帧，接收下一个视频帧，循环往复，直到线程接收到结束命令停止；以上述音频采样率和采样位数为例，视频参考时间的计算方法为（以C语言格式的？号表达式表示）：

音频时间戳时间 +1/30>视频时间戳时间＋丢弃：播放；

在编程实现时，采集端和播放端的音频和视频可采用独立的线程，并利用Qt的信号槽机制实现音视频线程时间戳的传递，此处不再赘述。

录音：mic接到codec，经过adc变成数字信号，经过待续2中ac97等接口存储到cpu的fifo中，经过待续1中的dma传输存储到内存，经过待续3中alsa_lib中snd_pcm_readi接口传给录音软件，经过编码，进而形成音频文件。

放音：播放软件将音频文件解码，并通过待续3中snd_pcm_writei接口逐渐传递到和dma相关的内存，经过待续2中dma传递给cpu的fifo，再经过ac97等接口传递给dac，最后传给连接在codec上的speaker。

心得：

1.ac97数据传输颇复杂，分时复用，cpu端fifo和codec端adc/dac关系要对应好。比如，cpu端的pcm left fifo占用slot3，那么adc只有配置成slot3才能把数据传递给它，如果配置成slot6，那就传给cpu的mic in fifo了。录音单声道通常选择slot6，录音双声道通常两个adc分别选择slot3和slot4。

2.wav音频文件大小计算：要测试录音是否丢祯，就必然要计算文件大小，通常的方法是：根据录音时间，用公式：录音时间(单位s)x采样率x(采样位数/8)x通道数。比如，录音时间5秒，采样率8kHz，位数16位，通道数1,那么5x8000x(16/8)x1=80k，实际的wav文件大小稍大于80k就对了。还有一种计算文件大小的方法：通常音频系统要用dma，也会用到dma中断，可以在dma中断中打印计数，次数xdma中断周期字节就行了。

3.数据交换的大小问题：待续1中DMA传输必须和FIFO的特性匹配：若FIFO位宽是16位，深度是16，并且半满时向DMA发出请求(握手)，则链表式DMA必须配置成传输位宽16位，1次突发16字节，才能保证不丢失位数和数据个数。待续2中cpu端FIFO位数要和codec端adc/dac采样位数匹配，i2s/pcm接口可以配置成一样的值，比如16位，ac97接口复杂一点，cpu端不用配置，那么采样位数是多少呢?若cpu端fifo一个声道位宽16位，codec端adc/dac位宽18位，ac97通道20位，则传输到fifo端就被截取到有效的16位，整体采样位数16位，adc/dac的性能没有充分发挥而已。待续3中snd_pcm_readi、snd_pcm_writei函数第三个参数表示读写数据的大小，单位是祯，不是字节。双声道16位格式一祯大小为4字节

总线接口：显示卡要插在主板上才能与主板互相交换数据。与主板连接的接口主要ISA、EISA、VESA、PCI、AGP等几种。ISA和EISA总线带宽窄、速度慢，VESA总线扩展能力差，这三种总线已经被市场淘汰。现在常见的是PCI和AGP接口。PCI接口是一种总线接口，以1/2或1/3的系统总线频率工作（通常为33MHz），如果要在处理图像数据的同时处理其它数据，那么流经PCI总线的全部数据就必须分别地进行处理，这样势必存在数据滞留现象，在数据量大时，PCI总线就显得很紧张。AGP接口是为了解决这个问题而设计的，它是一种专用的显示接口（就是说，可以在主板的PCI插槽中插上声卡、显示卡、视频捕捉卡等板卡，却不能在主板的AGP插槽中插上除了AGP显示卡以外的任何板卡），具有独占总线的特点，只有图像数据才能通过AGP端口。另外AGP使用了更高的总线频率（66MHz），这样极大地提高了数据传输率。

---