监控视频的柔性实时分析架构

李 刚,张 晴,徐传运,2,徐 昊,宋志瑶

(1.重庆理工大学 两江人工智能学院, 重庆 401331;2.重庆师范大学 计算机与信息科学学院, 重庆 401331)

0 引言

随着计算机视觉与人工智能的发展,监控摄像机内嵌了越来越多的视频分析算法,能够独立实现人脸检测、人数统计等操作,但这种摄像机价格比较昂贵,且使用不够灵活。其主要问题有:摄像机在单个预置点上可以添加一个算法工作,当然一个固定位置可以添加多个预置点,达成了在固定位置设置多个算法的目的,但缺少移动过程中的检测,或移动后点位的相同算法检测,需要重复登录摄像机设置预置点,操作比较繁琐,当摄像机数量达到一定程度后无疑是一种灾难。摄像机功能固定,内嵌的算法较少,不利于扩充,对视频内容的检测率较低,大量的视频内容因缺少对应的智能算法而不能及时检测异常内容。

另一方面,不少文献提出并构建了智能视频分析系统,目前关于视频监控远程视频分析主要有2种实现架构,分别是基于边缘计算和云计算的架构[1-2]。随着研究的进展,国内[3-6]与国外[7-11]学者相继开发出来很多的智能视频监控系统,其中也提出若干对应不同场景的架构。例如,陈曦[3]、Xing[4]、张阳[5]与朱爱娟[6]等对智能视频分析系统中的关键技术做了详细的介绍。Tandayya教授团队开发的Nokkhum视频监控服务系统[7-9,12]具有一定的灵活性和可拓展性。Billones等[13]在检测交通违规上提出了一种灵活的多层架构。Chen等[14]提出将深度学习用于边缘计算的架构。谢莹[15]提出基于Web的插件播放架构。Ibrahim等[16]对当前神经网络算法用于视频分析做了总结。Jang等[17-18]提出基于边缘计算的视频架构。

以上系统的设计大都基于单个算法或一组对应相关场景的算法,这些系统中有能够复用视频数据的设计,但缺乏对算法性能和精度的衡量,系统柔性较差。每种算法只有一个版本,一旦出现任务量激增、计算资源短缺或其他故障,这些系统的性能就将出现断崖式下降,且不能主动探测视频内容、动态加载算法,缺乏灵活性。

通过对各个系统架构的研究,提出一种通用的柔性监控视频实时分析架构FRTA(flexible real-time analysis)。FRTA的柔性体现在:

1) 计算流程可定义,可分级,自动调整分配计算资源,超参数可调整。

2) 统一管理视频流数据与文本数据,减少图片的复制和网络传输,在不删减信息的同时减少系统内部通信的数据大小。

3) 把算法抽象成随插随用并能相互组合的组件,视频、图片和文本数据能与算法任意结合,且能够解耦合。

4) 保持视频帧序列的顺序输入输出的同时做无序计算。

1 FRTA架构

对于视频监控来说,实时的分析处理无疑会产生更大的好处,能够提高视频分析质量,一般从以下几方面着手:提高分析算法的精度,缩短算法的执行时间,增加检测帧数和检测分析算法的数量,以应对不同的场景需求。

FRTA架构是主要从控制检测帧数和检测算法数两方面设计的一种柔性实时视频智能分析架构。其架构柔性体现在:检测帧数、检测算法数、检测算法版本和检测数据都可控。FRTA可根据用户需求和系统资源自动调控视频分析的算法数量、算法版本、图片分辨率大小、视频帧数等。当系统任务需占用过多系统资源时,架构自动调解系统后台任务执行,释放资源用于实时任务;当系统出现资源闲置时,架构会主动开始一些预设任务,对视频内容进行分析。

FRTA最重要的目的是为了实现监控视频流全面的实时分析,即在不影响视频监控实时性和清晰度的同时,对视频流做更多的检测分析,脱离人工并自动挖掘更多细节,最终能够把异常情况及时反馈给视频监控使用人员。

FRTA架构中有5个主要模块:算法管理器、任务定义器、调度器、算法执行器以及数据管理模块——黑板,如图1所示。

图1 FRTA架构主要模块

采用上述设计的原因主要有:

1) 满足单一职责,避免模块之间过度耦合。

2) 实现流的柔性处理,避免一个算法拉一路流,做生硬粗暴的计算。

3) 实现接口与实现分离,每个模块可以根据自己的需要实现对应的接口,以适应不同的应用场景和计算方式。

4) 保证算法的随插随用,即算法可以固定在某台机器上运行,也可以动态脚本启动,同时一路流的关闭不影响算法的继续运行,只要还有流需要,这些算法就不必重新加载算法,减少时间开销。

5) 保持视频流的顺序性,视频流从摄像头中是按时序被拉取出来的,中间经过一系列的处理后,最终将结果汇总并按时序保存或推送给用户观看。处理流程如图2所示。

图2 FRTA架构处理流程

以下分别对FRTA架构中5个主要模块的设计原理和内部工作方案做出详细说明,并对FRTA工作流程给出归纳和进一步的拓展说明。

1.1 算法管理器

根据算法的来源、类型和作用不同,算法之间除了逻辑之外存在着一些差异性。一些算法来自已经开发好的框架,例如OpenCV;一些算法来自用户自己训练的模型,或者是用户选择使用某些云平台提供的模型。算法也有类型上的区分,算法可能是常规的逻辑处理算法,也可能是机器学习或者深度学习算法,常规算法可能对GPU要求不高,但后者在不同CPU上的表现差异性不容忽略。此外,算法的效果也有差别,一个精度特别高的算法可能需要花费更长的时间,而精度差的算法也是可以满足一般需求的。

因此,算法管理器按照算法的来源、类型、作用、运行效率和条件等对算法进行统一的接口管理,能够适应多线程和顺序执行,并根据用户能够提供的设备自动适配,选择合适的算法以提供差级服务。算法管理器根据算法签名管理算法,算法签名由算法名称和版本号构成,且是唯一的,用户在注册算法时会有唯一性检查。相同功能的算法使用同一个名字,但它们的版本号不同,用以区分彼此。

此外,算法需要说明其输入和输出要求,因为所提架构面向的是视频流处理,所以对输入为非图像或视频帧序列的算法不做考虑。在算法输入方面,会有图片颜色空间、宽度、高度、步长、位深等的区别。在算法输出方面,由于算法来源不同,因此需要做不同的处理:对于架构实现时嵌入的算法,可以直接输出文本信息;对于输出图片或者视频的第三方应用可以进行标记,或对原始视频帧做替换等操作。架构中的算法管理器更多的是维持算法的存在,对于算法的输入输出需要其他模块作对应的调整。

为了算法的执行不被机器限制,架构中所有的算法都被调整到无状态。虽然有些算法在逻辑上具有先后顺序,但其实对图像的要求不会出现一致的情况。同时,为了图片或者视频能被尽可能地复用,不能对图片本身进行修改,除非该图片只有当前算法使用。算法中的所有数据都被存入黑板,所有的算法都到黑板中拿数据。

1.2 数据管理

为了增加视频实时分析的维度和多路视频的联动,采用集中管理的方式管理所有的数据。架构中最主要的数据便是视频流,此外还有算法对视频处理结果的文本数据。架构为所有数据提供统一的基类,方便数据的传递和扩展。

算法在处理完一张图片或一份视频帧序列后,需要把处理结果缓存起来,以便于后续算法使用。多个算法同时处理一份数据,其完成时间必不相同,因此也需要把先完成任务产生的数据缓存起来,以便于释放资源用于处理其他的任务。所以在所提架构中采用黑板模式做数据的缓存。

黑板模式有4个基本的角色:数据、数据生产者、数据消费者以及控制器。其中数据便是此架构中的视频流信息,视频流对应的帧序列,算法产生的结果,以及最终处理完成的视频帧序列;数据生产者和数据消费者的角色是可以互换的,生产者也可能使用另一个生产者产生的数据,从而变成了消费者,同样的消费者产生的数据放入黑板进而成为生产者,因此在架构中将所有的生产者和消费者都统一成任务;控制器控制数据和算法之间的交互,在所提架构中将此部分功能合并到调度器中。

另外,黑板的数据缓存形式可以由架构实现者选择,其可以选择自己实现数据缓存,也可以选择使用数据库或者消息队列框架代替。黑板为了方便管理,避免架构过于复杂,根据流的唯一标识划分队列,为每一路流在源流、中间和最终数据阶段各分配一个队列。

1.2.1视频源流数据的处理

首先是对视频数据的处理,把所有接入系统的摄像头进行统一管理。在所提架构中,每一个摄像头只会被拉取一路流。虽然现在的高清摄像头能支持几十路流的同时拉取,但同时拉取过多的视频流会对网络带宽和计算机内存提出更大的挑战。同时,在做算法分析时也会产生重复处理的操作,这同样会造成计算资源的浪费。因此所提架构采取一路摄像头只拉取一路视频流的方案。

对所有的视频流进行统一的管理,为每一路流维持一份类似于文件管理中的文件控制块的元信息。这些信息包含视频流的来源(摄像头的相关信息与摄像头所属单位等信息),视频的封装格式、编码器、解码器、帧分辨率、码率、帧率、拉流地址、推流地址、拉流器和推流器等信息。同时为了能够保证系统各模块间的通信压力,为每一路流分配一个唯一标识。

每一路流在系统中缓存一份帧序列,这是从摄像头中拉取的视频帧序列。视频中的每一帧图片从摄像头抓取出来时会带有大量的信息,但只有一些与图片相关的信息是在帧序列或者图片处理的时候常用的,例如图片的宽和高、图片片素格式、图片步长、图片深度等。在图片复制或者传送时,只传输这些必要的信息无疑会减少带宽的花销,同时为每一帧图片分配一个流内唯一标识,作为图片所属流的位置。

一路流的视频帧不可能完全都缓存在内存中:一方面,前面的帧已经被处理过了,没有被缓存的必要了;另一方面,拉流器还在不停地从摄像头中抓取视频帧,这些视频帧不及时被缓存可能会阻塞后续的视频帧抓取,还会影响视频流的处理流程,使视频的实时播放出现卡顿、丢帧等现象,甚至会造成内存溢出的错误。所以处理过的视频帧需要及时保存。

1.2.2中间数据处理

中间数据是除了最初的视频流和最终数据外算法产生的结果,之所以将算法产生的结果独立出来,也是根据单一职责的原则,将不同时期的数据放到不同的地方,便于管理和维护。在源流队列中有视频帧时,架构便将视频帧出列,放入中间数据队列中,等待该帧上所有的任务做完。调度器检测到该帧上的任务没有完成,便会继续等待任务执行或者将未执行的任务交给算法执行器,已完成任务的结果则将写入该帧关联的集合中。当该帧上的所有任务都已完成或者超时,该帧会从中间数据队列中出列,放入最终数据队列中。

1.2.3最终数据处理

最终数据由原始视频帧序列和对应的文本数据组成,其表示该视频帧已被处理完成,所有的数据都需要按照原始视频帧的时序排列。

一般情况下拉流视频的帧率为25帧/s,2帧时间间隔为40 ms,考虑到无处理流的时间消耗,在所提架构中设置初始30 ms的等待时间,即推流器或者数据保存的等待最大时长为30 ms,如果当前队列中最小视频帧不是已推送视频帧的下一帧,那么直接推送此帧,而不再等待。

FRTA提供可设置的等待时长,用户可手动或者由系统自动调整适当的等待时长,调整策略为监测视频帧上的任务完成时间、任务生成和调度花费时间。一般在推送实时流给用户观看时需要调整等待时长来保证视频的流畅度,因此一帧图片的处理总时间不应超过40 ms或帧间隔时间,在调度中还有一些策略来保证视频的流畅度。

1.3 任务定义

任务定义器主要管理视频流和算法之间的关系,视频流和算法存在一对一、一对多、多对一或者多对多的关系。任务定义器便是根据视频流和算法之间的设定来维持一个最优的对应关系,以便减少重复计算次数和数据内存占用量。任务定义流程如图3所示。

图3 任务定义流程

1.3.1用户事件

用户在前端设定一路视频流上所绑定的事件,这里的事件为用户想要在视频流中触发的事件,所有的事件都会将用户、摄像头、视频流和算法等信息保存在用户事件管理器中。经过任务解析器解析后,事件会变成一个个任务,并与视频流绑定,写入任务定义器中。

1.3.2任务定义器

任务定义器采用有向无环图的形式关联任务的关系,任务之间存在同级和先后的关系。在所提架构中,将所有的最小处理单元都抽象为任务,每一个任务都具有一个任务清单,在清单中包含3个内容:需要算法处理的数据引用、当前算法、算法的输入要求、算法输出处理等。关于视频处理算法或者图片算法几乎全是要求输入的数据是图片,因此不考虑非图片或者非视频帧序列的情况。

一路视频流绑定的算法大部分是可以同时进行计算的,这种算法处理起来比较简单,只要计算资源允许,就可以并发或并行执行,先后顺序不会影响最后的结果。但有些算法处理需要一些前置算法,其原因有很多,例如用户设定的事件具有先后顺序。另外,有些算法比较耗时,或者视频变化比较少,这些情况下对每一帧都处理,无疑是一种不可行或者非必要的计算。因此采用一些聚焦算法感知原始视频帧的内容变化,之后对视频帧做缩放或者分割等处理,最后把满足算法输入需求的图片地址传给算法,这样处理会节约大量的计算资源,并能进一步保障视频的实时性。

任务定义器的另一个主要作用便是可以根据算法的输入输出主动推导算法的前置算法和输出结果的处理方式。例如,如果算法要求的输入是灰度图片,任务定义器便会检测当前图片是否为灰度图,如果不是便会自动调用图像像素转换算法,将彩色图片转换成灰度图。

1.3.3任务工厂

根据任务中的算法生成对应的算法对象或加载对应算法的模型。通过工厂模式,不仅可以不暴露创建逻辑的创建任务所需的算法对象,而且可以对算法的对象进行管理。加载算法模型需要花费一定的时间,如果在每次使用算法时都加载一个新的模型并创建一个新的对象,那么必然浪费很多不必要的时间,因此花费很少内存缓存一些还会被用到的算法模型是一件很值得的事。

1.4 调度器

调度器是所有任务执行和数据流动的中间调度者,根据单一职能的原则,把可执行任务和数据流向单独提取出来,以此控制整个架构中每个任务执行与否、执行时间和执行异常处理等。

调度器从任务定义器中获取可执行任务,判断此任务的可执行性,如果不可以执行,那么判断不可执行的原因,根据原因不同做不同的处理;如果可执行,那么调用算法执行器,若算法执行器回应可执行,则交给算法执行器执行任务,否则做进一步处理。调度器会将算法产生的结果放入黑板的中间数据队列中,如果当前算法是当前视频帧唯一一个任务或最后一个任务,那么将算法结果和当前视频帧放入最终数据队列中。如果当前算法不是当前视频帧唯一一个任务或最后一个任务,那么检测黑板中有没有对应视频帧:没有,则将视频帧放入队列中,然后将该算法输出结果放入对应视频帧的结果集合中,同时检测该视频帧的任务有没有全部执行完或者有没有任务超时;有,则将该帧放入最终数据队列中。调度器工作流程如图4所示。

图4 调度器工作流程

调度器另一方面的工作便是对整个系统的管理,当一路流收到停止分析指令,或者拉流出现问题、推流和保存视频出现异常等情况时,调度器便会向各个模块发出对应的指令,关闭一些不需要的算法对象,清空对应数据内存,做出通知系统处理结果等操作。

1.5 算法执行器

之所以把算法执行器单独提取出来,是为了将所有的计算资源进行统一的管理和分配,这种设计不仅支持单机资源管理,还支持分布式或者云计算的方式。也就是说,架构不需要关心是谁在执行任务,只需要调度器将任务交给算法执行器便可以等待一个执行结果。

所有的来自调度器的任务都会被视为一个基本任务执行单元,算法执行器根据任务清单获取任务中的算法和数据,执行系统负责算法的调用和执行,并将结果返送给算法执行器;算法执行器根据任务清单中的结果处理方式处理结果,并将算法结果返送给调度器。

1.6 FRTA工作流程

FRTA架构的整个处理流程为:

1) 整个架构从用户设置摄像头上的事件开始,用户事件会被保存在用户事件管理器中,然后经过任务解析器解析成任务集合,这些任务在任务定义器中与视频流绑定。

2) 任务定义器检测根据调度器的请求和任务完成情况,同时根据当前所要执行的算法,从算法管理器中拿到算法签名和算法路径。根据算法的输入需求检测当前数据是否符合算法要求,不符合就自动推到合适的处理算法,再到任务工厂加载算法模型生成算法对象,然后把算法和数据绘制成任务清单,将任务清单传给调度器。

3) 调度器拿到任务清单后,根据清单中数据和算法查看是否需要算法执行器执行。如果不需要执行,那么直接将数据放入最终队列中;如果需要执行,那么将最初的视频帧放入黑板中间队列中,然后调用算法执行器执行任务。

4) 算法执行器会根据整个系统的资源情况分配计算资源,在执行完毕后将结果返回给调度器。调度器检测对应视频帧的任务是否执行完毕:如果执行完毕,那么将该视频帧和相关的处理结果写入最终数据队列,转到步骤5),否则向任务定义器请求下一各任务,重复步骤2)—4)。

5) 当黑板中最终数据队列出现数据时,便会开始推流或者保存数据的操作。如果推流就根据推流用户指定的推流策略与等待策略开始工作。无论推流还是保存数据都被规划为任务,由算法执行器执行。

架构通过文本数据标记图片或视频数据,减少计算机复制造成的时间开销和内存开销,同时对任务超时、拉流中断、推流异常和任务获取异常等情况做出处理。

1.7 FRTA对比分析

与TANDAYYA教授[7-9,12]领导设计的Nokkhum系统相比,FRTA在视频内存存储上更加灵活。Nokkhum系统视频流直接对应视频分析算法的设计,无法做到视频片段甚至视频任意帧上的算法组合。FRTA更能做到灵活的组件插拔,不用停掉整个视频流,可以在任意时间点设置任意时间段内的算法,算法可配置,动态组合,具有事件重要优先级,更具灵活性。

与BERAN[11]设计的可选分析算法视频分析系统相比,FRTA的算法不仅可选,而且可配置。分析算法不仅来自代码集成的算法,还支持系统管理人员将按照FRTA规则配置好的算法加入系统中,这样算法的维护工作会更轻松,系统的灵活性和可用性也更高。

另外,为了降低延迟,减轻服务器计算压力,很多人的研究方法转向边缘计算[2,4,17-18],FRTA架构与边缘计算并不冲突,反而是对边缘计算的补充。从宏观上抽象视频流和算法,形成一个个计算任务,便于边缘计算更集中于核心任务的处理。例如先做视频流内容的感知分析,然后将可能有任务的视频帧序列分发给对应的处理单元,这样可以更高效地利用算力,减少无用视频帧序列流向计算单元。从宏观上把整个架构内的计算单元专业化,甚至可以动态地分配算法到整个边缘计算网络中,避免出现某些边缘设备长时间闲置,而其他的边缘设备却处理不完任务的情况。

综上所述,FRAT的优势在于更灵活的架构设计,能够动态配置算法,并做到热插拔,算法优先级分配;更高的系统利用率,避免算法占据服务器却没有工作任务分配的情况发生。

2 结论

介绍了一种柔性的实时视频分析架构FRTA,此架构可以根据系统任务和系统资源自动调控分析算法的数量、算法版本、数据量等;根据用户需求和系统资源自动调控视频分析的算法数量、算法版本、图片分辨率大小、视频帧数等。当系统任务需占用过多系统资源时,架构自动调解系统后台任务执行,释放资源用于实时任务;当系统出现资源闲置时,架构会主动开始一些预设任务,对视频内容进行分析。

FRTA架构采用单一职责的设计原则,将整个系统分为任务定义器、数据管理、算法管理、调度器、算法执行器等模块,从较高层次抽象设计系统架构,从而提出一种多路视频实时分析的系统架构。该架构能灵活地保证用户任务的执行,并能够更详细、更主动地分析全场景内容;系统内部大幅度减少重复数据的内存占用,增加视频内容分析的准确度,提高系统的可扩展性和适用性。

FRTA架构实现了更灵活的架构模块组合,可由架构实现者根据需要实现各个模块,保证了架构的计算效率和计算模式的多样性,增加了智能监控系统的扩展性。