分散式大规模阵列全景视频系统的设计与实现
2019-04-25胡耀民晏细兰
□胡耀民 晏细兰
一、分散式全景视频系统物理拓扑结构与节点配置
(一)系统物理拓扑结构。由于全景视频系统是一个实时系统,并且通信量大,无法承受过高的通信代价[1],这时必须为分散式视频全景系统提供一个高速通信的环境。本系统搭建高速局域网如图1所示。
图1 24路视频全景系统物理拓扑
为了方便摄像机的统一管理,摄像机均连接到固定在摄像机阵列上的一个千兆交互机,而各个计算节点统一连接另一个千兆交换机,最后将两个交换机通过交换机专用高速接口连接在一起[2~3]。由于计算节点与摄像机通信时交互次数只要两次,使得实测网络延时<1ms。
(二)分散式全景视频系统需求与配置。本系统所需设备:24路网络摄像头阵列,能输出帧率达到25fps的标清视频;千兆交互机2台。计算机节点如表1所示。在本次系统设计中选用3台性能差异较大的计算机作为计算节点以验证分散式系统在异构环境下仍然能够发挥作用。此外配置1同时担任系统控制节点。
二、分散式全景视频系统整体方案设计
本分散式系统需要对管理系统和计算节点分布实现应用
表1 节点配置
程序的接口,管理服务器主要完成参数学习、多分辨浏览控制、全景数据融合和节点任务管理;计算节点应用接口负责视频数据采集、局部全景视频投影与存储和多分辨浏览数据提取。如图2所示。
图2 系统整体方案设计
三、系统数据传输分析
数据传输根据节点的串行方式可以分为节点间网络传输和节点内部数据传输。网络传输方面本系统使用TCP/IP网络传输协议,该协议提供无边界数据传输,带有纠错功能,能实现无丢失的数据交换,传输能力主要由网络的传输带宽和节点的网络数据交换能力决定。本系统使用的是千兆交互机和千兆网卡,交换机能实现线路的自动开关,使得端与端之间的数据交换互不影响,也就是说各个计算节点都能实现1,000Kb/s的数据交换能力。节点内部数据传输通过数据总线决定,其数据交换能力非常大,相对于网络传输其数据交换代价可以忽略不计。根据串行任务中交换数据的不同,对网络数据传输需求主要模块作出如下分析。
(一)摄像机至采集模块。摄像机输出数据采用H.264的MPG4编码方式,该方式通过设定关键帧与帧间差分的方式去除视频中的冗余信息,实现高压缩比的视频压缩。由于本系统中全景目标帧率为10fps,所以把摄像机的物理采集帧率与关键帧隔设定为10fps,这时视频码率设定为2Mb/s时视频图像能保持较好质量。24路视频数据均在一个交换机出口输出,输出带宽需求为24×2Mb/s=48Mb/s,远低于交换机的带宽容量。
(二)采集模块至投影模块。如果该两个模块被分配到了不同的节点,必须通过网络传输。采集模块通过解码后,把每帧图片提取出来,对于720p图像,其原始大小为1,280×720×3×8bit≈21Mbit,对于视频为10fps的处理速度其带宽需求为210Mb/s,虽然网络带宽能满足需求,但是也会造成每帧在网络传输上花费21ms,由于串行流水线操作中数据传输是必要开支,对本系统中流水线单步执行时间限制在100ms以内的需求来说网络传输花费时间太多。为了减少网络传输数据,必须对图像进行压缩,本系统利用JPEG图像压缩,在压缩比在15∶1时,一帧图像大小约在1.4Mbit,网络传输时间为1.4ms,另外压缩图像也会增加另外的编解码计算成本,实际测试中,不同计算能力的计算机对720p图像进行JPGE编码和解码时间为2~6ms内,所以采用图像压缩后传输图像显得更加效率。
(三)投影模块至压缩模块。由于本系统中摄像机除了角度参数外其他参数基本相同,所以图像在投影变换后畸变一般很小,大小与原始图像相仿,其网络要求与(2)是一样的。
以上分析是根据理论值计算的,实际测试中根据图像内容和网络瞬时状态存在10%~20%左右的浮动。可以看出,数据传输是流水线操作上的产品传递时间,该时间由各个传输过程中最慢的一块决定,即裁剪模块至融合模块,也就是说提供给各个模块的最大计算时间为75ms,大于该时间会出现流水线不同步,任务堆积在某一个模块。
四、系统任务测试与分配
(一)任务功耗需求计算。以配置3为任务测试环境,测试各个任务1,024次,其中t3以其最大值(视窗分辨率和图像分辨率一致并包含整个图像)计算结果如表2所示。
表2 任务需求
从表2可以看出,其通信消耗非常大,说明优秀的分配结果基本上会是把任务直接本地串行以减少传输消耗,只有在考虑任务均衡时才会引入少量传输消耗。
表3 节点测试
五、结语
综上所述,可以看出本系统对24路全景视频的处理还是有一定的负荷余量,通过调节帧率或扩大阵列规模,系统效率还可以提高。分散式系统对实时和异构系统都有很好的适用性。通过继续扩大节点规模,各个节点的负荷率将会减少,当规模达到一定程度时,基本可以达到在不影响各个节点用户本身的使用需求下,仍然保证系统的流畅运行。