全景视频拼接分散式系统的研究与设计

晏细兰

（广州番禺职业技术学院信息工程学院，广东 广州511483）

图1 应用程序设计

随着视频监控的市场规模逐步扩大，人们不需要再花费大量的人力和精力去现场进行监视或者指导，而是通过网络把不同地方的监控数据集中到一个监控中心进行观察和记录[1]。正是因为监控设备与监控者在空间上的分离，在监控区域出现问题时监控者无法马上到达监控区域进行更全面的记录，因此监控者不希望由于监控设备性能的不足而无法获取更加详细的监控内容。在需要监控一个大场景时，现有方法可以采用拥有较大视角的镜头如鱼眼镜头和广角镜头等获得大视角的监控，但这些镜头会使得视频内容出现严重畸变。此外，由于摄像机技术限制，摄像机分辨率有限，用单个摄像机观察大视场必然会牺牲细节内容，而细节往往才是我们感兴趣的。目前为了满足大场景高分辨率监控的需求，一般采用多个摄像机分别监控视场中的各个位置，但是由于摄像机监控区域的不一致，导致整体监控内容具有不连续性，一个移动目标会在不同摄像机中反复跳转，因为对监控者来说，要在不同摄像机中找到一个连续运动的目标往往非常困难，所以希望找到一种方法能保持目标的连续性。本文以解决大规模视频全景摄像机阵列中计算量需求巨大的问题为主要研究内容[2-3]，设计了一个能实时生成并分散式保存视频全景数据的系统。

1 分散式全景视频系统节点配置

本系统的性能指标为实现24 路720p 视频阵列的全景拼接，视场重叠区域小于25%，总分辨率达到1 千6 百万，全景视频播放帧率达到10fps，用户能通过多分辨的方式浏览和存储全景视频。计算机节点位三个配置，配置1 和配置2CPU 均为Core-i7 3.4GHz 四核八线程，配置2 为Pentium4 3.0GHZ 双核，所需内存依次为16GB，4GB 和2GB，操作系统均为Windows10系统。

2 系统整体应用接口实现

本分散式系统需要对计算节点实现应用接口，一个计算节点可以并行处理多路视频数据，也可以和其他节点串行以流水线方式完成某路视频数据，具体根据管理服务器来自动分配。各个节点把图像按照多分辨浏览参数提取局部图像后传输到服务器的融合模块，由于多分辨浏览中视窗大小一致，该带宽需求主要取决于视窗大小，本系统中视窗大小设定为1280x720，再考虑各视场存在20%左右的重叠区域，所包含的融合数据大小应该是视场大小的1.96 倍，即每帧41.2Mbit。同样该数据量延时也是不可接受的，所以也需要做压缩，每帧延时为7～15ms。服务器与节点的控制信息是小数据指令，可以忽略其传输消耗，而投影参数传递为一次性传递，没有事实要求，所以也不考虑其带宽消耗。系统设计如图1 所示。

3 系统任务测试与分配

3.1 节点性能测试

设总体任务量Q 固定，节点i 由0 开始，直到t 达到收敛，收敛时间为t'，则节点i 的性能容量为：

图2 节点1 运行负载

图3 节点2 运行负载

根据式（1）各个节点的容量为：

表1 节点容量

由于该容量为系统空载下测试的结果，由于节点1 处理计算节点同时还作为系统管理节点，而节点2 有别的用户使用需求，只能提供部分资源，所以这里设定各个节点的权值为0.5、0.5、1。即有：

表2 乘上权值后的节点容量

3.2 系统实时运行负荷

在打开2 路全景时，帧率保持10fps，此时各个节点的瞬时运行负载如图2、3。

节点2 和节点3 与理论结果是比较接近的，而节点1 在同时作为管理节点的情况下，运行负载仍然要比理论值低，说明单纯用某个任务去比较各个节点的性能不够全面，原因是不同节点可能对同一任务的处理效率不一样。此外，同一个节点中各个CPU 的负载也不近相同，出现了个别CPU 满负载运行，其他CPU 半负载的情况，这主要是一个线程只能利用一个逻辑核心线程的资源，而分配的任务线程数量与节点逻辑核心线程数量不为公约数而导致的，所以在任务分配时也要考虑着方面的约束条件。但总体来看，本系统设计的任务分配方案还是具有一定的可用性。

4 结论

本文利用分散式系统的基本设计方法，设计了一个能实时生成并分散式保存视频全景数据的系统，实验结果表明本系统设计的任务分配方案具有一定的可用性，能够实时的生成全景视频。