随着嵌入式计算技术的发展,家庭智能服务机器人已经从提供单一的家庭服务演变为多功能的智能载体. 家庭智能服务机器人逐渐具备了家用安防视频监控等的功能. 而移动互联网时代下,视频监控终端逐渐多元化,Google公司研发的Android平台逐渐成为移动智能终端的主流操作系统之一. Android系统基于强大的Linux内核,但是,其自身的多媒体系统却不够强大,体现在其对于音视频编码和封装格式的支持有限. 在工程实践中,不能满足应用开发者多媒体处理需求,在视频监控终端的应用场景中尤为突出.
在视频点播(Video on Demand)、安防监控等多媒体应用场景中,音视频同步对于服务质量(Quality of Service)非常关键,是直接影响用户体验的关键点[1-2]. 国内外不少学者针对音视频同步问题进行了研究[3-9]. 目前已有若干种方法,包括需要全网同步化时钟的时间戳同步技术[3],基于反馈进行同步[4],基于流媒体网络协议的同步方法[5-7],根据视频内容中对象(如唇型)进行同步[8],借鉴信息隐藏算法等将音频编码数据嵌入视频编码过程中[9-11]等等. 这些方法都存在一些不足和缺陷,如唇型同步在视频内容中没有唇时无法进行;如将音频数据嵌入H.264的编码中的方法需要对编解码器代码进行修改,理论要求高,实现复杂. 而基于流媒体传输协议的同步方法不仅支持异构网络环境,而且具有实时性好等优点,适合运用在视频监控系统中解决音视频同步问题. 因此,本文针对家庭服务机器人视频监控的需求,提出一种新的音视频同步方案及同步算法. 采用Android设备作为客户端,使用RTP(Real-time Transport Protocol)等作为音视频数据传输协议,对所提的方案和算法进行了验证. 实验结果表明本算法具有同步相位失真小,同步效果稳定的优势.
1 音视频失同步 1.1 失同步原因分析在音视频数据采集过程中,由于程序是顺序执行的,而且操作系统对于进程是异步调度执行,因此,不可能做到音频和视频的采集时间完全相同,这里会使得两种数据的对应关系不正确;而在接下来的音视频编码过程中,由于一帧视频数据相对于一帧音频数据要大很多,对视频进行编码的时间相对于一个音频采样的编码时间要长很多.
编码数据在发送过程中要按照RTP协议的格式来进行打包,在打包的过程中,由于编码后的一帧视频数据长度仍然远大于一帧编码后的音频采样数据. 因此,在将编码数据封装进RTP包的过程中,这个长度差异同样地会引起音频和视频数据的失同步.
在音视频数据进行传输的过程中,由于RTP协议是一种尽最大努力交付的协议,不具备可靠传输的特点,受网络状况影响较大,当网络状况比较拥堵时,数据包存在延时、丢失、乱序到达等可能性. 而对于音视频数据,一旦出现丢包的问题,将可能影响到编码数据的完整性,特别是当H.264的数据单元超过了MTU的大小时,要采用分包发送,此时将会引起视频编码数据的不完整,在解码过程中将出错,这也会引起失同步问题.
在智能终端Android平台上,应用程序进行音视频的解码播放过程中,如果不协调控制好音频数据和视频数据的时间戳而直接予以播放,那么也将引起失同步问题.
1.2 音视频同步的主观评价标准根据ITU-R BT.1359-1[12]的内容,人类生物学视听系统对于声音和视频的不同步的察觉程度是在一个具体的范围内的. 文献表明,当声音的呈现时间Tsound与视像的呈现时间Tvision的差值ΔT在-90 ms到180 ms之间时,人类主观感受是同步的,见图1所示.
在移动视频监控系统中,一般音视频数据是从前端摄像机采集,使用G.729算法和H.264标准分别进行压缩编码后,进行RTP打包,通过网络发送到流媒体服务器进行存储转发,最后实时流转发到客户端,采用Android设备进行接收. 在整个传输与转发的过程中,对同步有影响的部分包括前端摄像机的采集模块和编码打包模块,以及Android客户端的解码和播放模块. 因此,本文抽取出其中最关键部分并均予以同步控制,如图2所示.
在前端采集音视频的过程中,采用的是多线程的程序设计方法,在操作系统中,内核调度线程执行具有异步性等导致无法严格保证采集到的音、视频能够完全同步. 而根据人类生物学声音视像系统对同步的感知能力,可以选取在图1中的可检测阈值(即ΔT在[-125 ms,45 ms]区间内)作为门限,将采集到的原始声音和视频数据认为是同一时刻获取到的. 通过对采集音视频数据的过程中进行观察记录并统计分析,可检测阈值范围内有3帧音频数据和2帧视频数据的时间戳满足这个要求. 这5个数据单元在时间上的强相关性便于在接收端通过时间戳来进行同步,因此,使用新定义的数据结构把这5个数据单元从逻辑上封装为一个整体. 如图3所示,采集模块采集到的5个数据单元将封装到一个同步数据节点中,所有同步数据节点以本节点内的时间戳上最小的数据单元的时间戳作为本同步数据块时间戳. 在采集以后的处理中,所有操作都是基于这个同步数据节点来进行的.
同步数据节点是时间上具有强相关性的数据单元的存储形式,使用如下的数据结构表示.
struct synchronous_block
{
int64_t m_timestamp;
synchronous_subblock m_avdata[5];
};
struct synchronous_subblock
{
enum AV_TYPE_FLAG m_type;
void *m_avdata_p;
};
其中synchronous_block结构体中的m_time stamp是在整个结构体中最先捕获的视频帧的时间戳,单位为us;m_avdata是用来保存整个包中的2帧视频数据和3帧音频数据的数组. synchronous_subblock中的m_type是用来指明这个结构体是用来存储的音频还是视频数据;m_avdata_p成员则指向采集的具体的音视频数据.
在各大模块之间进行数据传递需要用到缓冲区,队列中存储的元素就是同步数据结构体类型的.
struct AVDataBuffer
{
void*buff_avdata[AVDATA_BUFFER];
unsigned short head_loca;
unsigned short tail_loca;
unsigned short frame_num;
}AVDataBuffer;
如上AVDataBuffer就是视频缓冲区的数据结构,其中buff_avdata为void*类型的指针数组,其中的指针指向封装后的同步数据结构. head_loca为缓冲区的头指针指向第一个数据,tail_loca为缓冲区的尾指针,指向最末尾的数据的下一个位置. 在对缓冲区进行变动性的操作的时候,使用POSIX的互斥锁机制控制访问,解决多个线程间同时访问可能存在的竞争条件.
2.3 同步控制算法设计 2.3.1 发送部分同步控制主要存在于发送部分的采集、编码、打包以及接收部分的解包、解码、播放过程中. 在分离采集到音视频数据后,按照同步数据节点的格式存储,插入到采集模块的原始数据环形缓冲区中,这个过程如图4所示.
编码打包模块从环形缓冲队列中依次读取同步结构体,同时,分别使用FFMPEG对视频进行H.264编码,对音频使用G.729算法编码,在编码完成后按照同步结构体的格式填充,同样存入编码数据环形缓冲队列等待打成RTP包进行发送.
打包模块从编码数据环形缓冲队列中读入同步结构体,对音视频数据进行RTP打包. 由于MTU限制,而一帧视频数据可能超过这个限制,因此,需要对于这种情况进行处理. 如果RTP包超过了MTU的限制,那么,将这个RTP包分为若干个子包,同时,在这些子包中均存有同步数据结构中的时间戳字段Tsyncblock,以及RTP时间戳字段Ttsrtp. 在后续接收端将通过Tsyncblock字段来判断子包属于哪个同步数据节点. 而一个同步数据节点中存在多个视频帧,这里要用到RTP包头的时标Sequence Number字段. Sequence Number字段指明该包中第一个三位二进制数据的采样时间.
2.3.2 接收部分当RTP包到达接收端,解码模块从接收缓冲区中取出同步结构体. 从得到的数据中提取出三元组<Tsyncblock,Ttsrtp,NSequnceNumber>,Tsyncblock表明该RTP包从属的同步结构体,Ttsrtp表明这个包的帧归属,也就是说如果是一个子包的话,子包将通过这个时间戳能定位到自己属于哪一帧,NSequnceNumber确定属于同一帧内的不同的子包之间的顺序. 此时,判定该包是否为子包或者为一个完整包. 如果是一个完整的包,那么直接将其中的数据插入到如图3所示的同步数据节点中;如果是一个子包,那么根据NSequnceNumber依次将子包中的数据插入到链表中.
接收部分接收到数据包后,要识别两个时间戳:同步数据块时间戳和RTP时间戳. 根据同步数据块时间戳确定该数据包是属于哪一块同步数据块,再确定该数据包是属于分包还是独立数据包. 如果是分包则根据RTP时间戳规则插入到同步数据块中的视频数据列表中,再根据序列号Sequence Number将数据包插入到该列表的相应位置;如果是独立数据包,那么根据RTP时间戳将数据包插入到同步数据块中的相应位置,具体步骤如图5所示.
逐个访问缓冲区中的同步数据节点,其中有区分音频和视频的数据字段,通过这个字段开始对数据节点中的数据进行对应的音频或者视频解码. 如图6所示,将解码缓冲区中的节点取出并完成对应的解码之后,再次将其存入同步数据节点中,最后插入待播放缓冲区中,等待后面进行访问和同步控制播放. 播放模块从播放缓冲区中取出的同步数据节点已经在时间上具有强相关性,取出后直接按照音视频数据自带的时间顺序进行播放就可以完成整个过程的音视频同步.
在工程实践中,Android系统使用StageFright作为多媒体框架. 但是Android系统对于音视频格式以及封装格式的支持不够丰富. 而开源项目FFMPEG能够支持几乎所有的格式. 将FFMPEG应用在Android平台主要有两种方案. 第一种是把FFMPEG中的解码器加入到Stagefright框架中. 这种方式的软解码效率较Android自带的软解码效率高,而且在应用层编程接口可以统一使用,但必须要修改系统源码,不适合作为应用开发者使用. 第二种是使用Native Development Kit交叉编译FFMPEG,同时使能FFMPEG自带的Android硬解码支持库libstagefright,再在应用开发过程中通过编写JNI接口代码实现调用. 这种方法不用修改系统源代码,更适合于应用开发者,本文也采用这种方式.
在Ubuntu14.04下使用Google官方提供的NDK-r9d工具集,并且对FFMPEG2.5进行移植. 移植的步骤如下:
(1) 根据移植的目标平台编写配置configure文件,特别注意加入对stagefright的支持.
(2) 使用make工具进行构建,交叉编译生成需要的库,主要有如表1所示,抽取这些库和相关的头文件用于Android项目中.
在Android平台上调用FFMPEG进行解码的流程与在其他平台上进行解码播放的流程相同[13]. 在Android应用程序中创建一个线程,先接收从对端传来的数据包,然后调用编写的JNI代码接口对接收到的数据进行解码,由于Android中只有主线程能更新UI,通过Handler通知主线程来显示解码后的图像数据.
4 实验与分析音视频同步性能的客观评价准则通常是使用同步相位失真SPD(Synchronization Phase Distortion)来进行[14]. 其数学表达式为
${D_{av}} = ({P_a}(i) - {P_v}(j)) - ({G_a}(i) - {G_v}(j)).$ |
公式中的Dav是音频和视频流中的两个在时间上具有强相关性且最邻近的帧i和j之间的同步相位失真(SPD),Pa(i)和Ga(i)分别是音频流中第i帧数据单元的播放时刻和产生时刻,相应地,Pv(j)和Gv(j)分别是视频流中第j帧数据单元的播放时刻和产生时刻. SPD从客观的角度反映了在时间上具有相关性的音频和视频数据之间的失同步程度.
为了对文中提出的音视频同步控制算法进行实验,搭建了如表2所示的实验环境.
在实验过程中进行两组实验,在PC端通过Linux下的Video For Linux框架采集视频,设置视频的分辨率,经FFMPEG指定进行H.264编码并设置视频的码率. 并进行音频采样,采样后同样经FFMPEG用G.729编码器编码并指定码率. 其中两组实验参数如表3所示.
按照表3中的参数对两组实验中采集的120帧视频和80帧音频数据用文中方法进行传输. 同时,为了验证文中方法对于整个过程的同步控制效果,使用一组仅在播放过程中进行音视频同步控制的实验数据作为参考.
如图7所示,受多个导致失同步的因素的影响,在仅对播放过程采用时间戳进行简单的同步控制的这一组中,SPD单帧存在失同步情况明显,有时甚至接近200 ms,失同步幅度较大;图8中是用L Bertoglio[15]的方法得到的实验结果,其中存在SPD超过100 ms的情况,而文中提出的方法的实验结果如图9和图10所示,能很好地控制在[-40 ms,+40 ms]区间内,且较为稳定,经计算分析得出SPD平均值相比于仅在播放时使用简单的同步控制的方式下的平均值要减小42.573 1 ms. 薛彬等[16]提出的改进方法的实验结果为SPD平均减小30.197 2 ms,如图11所示,相比之下本文的同步方法更优,同时,本文的SPD的整体值的波动范围也要比其更小.
随着移动互联网的快速发展,移动智能终端的计算能力越来越快,将在日常生活中承担更加重要的角色. 本文提出的音视频同步方案适用于以Android智能终端为客户端的移动视频监控系统. 通过移植多媒体开源项目FFMPEG到Android平台,大大丰富了Android平台对于音视频编码格式以及封装格式的支持. 同时,经过测试与验证,该同步算法能够保证音视频的同步播放,提高了监控系统的服务质量,而且对于工程实践具有很好的参考价值.
[1] |
柴若楠, 曾文献, 张鹏云. 音视频同步技术综述[J].
计算机系统应用, 2011, 20(11): 223-226.
CHAI R N, ZENG W X, ZHANG P Y. Survey on audio and video synchronization[J]. Computer Systems & Applications, 2011, 20(11): 223-226. DOI: 10.3969/j.issn.1003-3254.2011.11.057. |
[2] | RADHAKRISHNAN R, TERRY K, BAUER C. Audio and video signatures for synchronization [C]// Multimedia and Expo, 2008 IEEE International Conference on. Hanover: IEEE, 2008: 1549-1552. |
[3] | ESCOBAR J, DEUTSCH D, PATRIDGE C. Flow synchronization protocol [C]//Global Telecommunications Conference, 1992. Conference Record. GLOBECOM '92. Communication for Global Users., IEEE. Orlando, FL: IEEE, 1992: 111-121. |
[4] | RANGAN P V, RAMANATHAN S, VIN H M, et al. Techniques for multimedia synchronization in network file systems[J]. Computer Communications, 1993, 16(3): 168-176. DOI: 10.1016/0140-3664(93)90127-E. |
[5] | KUO C C, CHEN M S, CHEN J C. An adaptive transmission scheme for audio and video synchronization based on real-time transport protocol [C]//Multimedia and Expo, 2001. ICME 2001. IEEE International Conference on. Tokyo, Japan: IEEE, 2001: 403-406. |
[6] | ZHANG J F, LI Y, WEI Y N. Using timestamp to realize audio-video synchronization in real-time streaming media transmission [C]//Proceedings of the2008 IEEE International Conference on Audio, Language and Image Processing. Shanghai: IEEE Press, 2008: 1073-1076. |
[7] | PALACHARLA S, KARMOUCH A, MAHMOUD S A. Design and implementation of a real-time multimedia presentation system using RTP [C]//2012 IEEE 36th Annual Computer Software and Applications Conference. IEEE Computer Society, 1997: 376-381. |
[8] | AGGARWAL S, JINDALA. Comprehensive overview of various lip synchronization techniques [C]. Proceedings of the2008 IEEE International Symposium on Biometrics and Security Technologies. Washington, DC : IEEE Press, 2008: 1-6. |
[9] |
曾碧, 林建浩, 肖红, 等. 基于可变码长的音视频同步编码改进算法[J].
计算机应用, 2014, 34(5): 1467-1472.
ZENG B, LIN J H, XIAO H, et al. Improved algorithm of audio-video synchronization coding based on variable code length[J]. Journal of Computer Science, 2014, 34(5): 1467-1472. DOI: 10.11772/j.issn.1001-9081.2014.05.1467. |
[10] |
李晓妮, 陈贺新, 陈绵书, 等. 基于H.264运动估计的音视频同步编码技术[J].
吉林大学学报(工学版), 2012, 42(5): 1321-1326.
LI X N, CHEN H X, CHEN M S, et al. Audio-video synchronous coding based on motion estimation in H.264[J]. Journal of Jilin University (Engineering and Technology Edition), 2012, 42(5): 1321-1326. |
[11] |
温洁嫦. 数字音频信号的水印隐藏与嵌入算法[J].
广东工业大学学报, 2008, 25(3): 51-54.
WEN J C. Hidden and embedded water marking algorithm for digital audio signals[J]. Journal of Guangdong University of Technology, 2008, 25(3): 51-54. |
[12] | ITU-R BT. 1359-1. Relative timing of sound and vision for broadcasting [S]. 1998. |
[13] |
刘丽霞, 边金松, 张琍, 等. 基于FFMPEG解码的音视频同步实现[J].
计算机工程与设计, 2013, 34(6): 2087-2092.
LIU L X, BIAN J S, ZHANG L, et al. Synchronization playing of audio and video based on FFMPEG[J]. Computer Engineering and Design, 2013, 34(6): 2087-2092. |
[14] |
张昕, 吕凝, 王春雷, 等. 多媒体同步传输方法研究[J].
吉林大学学报(信息科学版), 2009, 27(6): 573-578.
ZHANG X, LYU N, WANG C L, et al. Transmission method of audio and video synchronization[J]. Journal of Jilin University (Information Science Edition), 2009, 27(6): 573-578. |
[15] | BERTOGLIO L, LEONARDI I R, MIGLIORATI P. Intermedia synchronization for videoconference over IP[J]. Signal Processing: Image Communication, 1999, 15(1): 149-164. |
[16] |
薛彬, 徐京, 王猛. 一种改进的基于时间戳的空间音视频同步方法[J].
电子设计工程, 2013, 21(11): 88-93.
XUE B, XU J, WANG M. An improved audio-video synchronization method based on timestamp[J]. Electronic Design Engineering, 2013, 21(11): 88-93. DOI: 10.3969/j.issn.1674-6236.2013.11.029. |