CN115641497A - 多路视频处理系统及方法 - Google Patents

Abstract

本发明提供了一种多路视频处理系统及方法，涉及图像处理技术领域，本发明将解码抽帧与算法推理完全解耦，将解码抽帧与算法推理的依赖减小到最低，真正解放了算法推理服务，因此能够充分发挥GPU运算优势，保证抽帧的速度与质量；抽帧服务集群化，且基于各节点的实时视频流处理量，向GPU服务器集群进行任务分发，能够分担全链路的时延与存储压力，保证几百路，甚至上千路视频并发处理的稳定性与效率，从而提供了确定的时延保障，同时具有灵活且可水平拓展的优点。

Description

多路视频处理系统及方法

技术领域

本发明涉及图像处理技术领域，尤其是涉及一种多路视频处理系统及方法。

背景技术

随着人工智能生态的不断发展，各项技术开始落地，服务于社会。在车路协同、智慧城管、智能监控等领域，对人、车、物进行识别分析的算法，需要接收多路实时视频流作为输入源，并将视频流进行解码抽帧，抽帧后的图片，交由算法服务进行推理。

视频流的解码抽帧，其主要工作在于矩阵变换，矩阵变换的计算量较大。在并行（并发）场景下，实时算法对于上层业务系统的时延保障，以及多路视频的并发处理能力提出了较高的要求。

发明内容

本发明的目的在于提供一种多路视频处理系统及方法，以保证抽帧的速度与质量以及多路视频并发处理的稳定性与效率，从而提供确定的时延保障。

第一方面，本发明实施例提供了一种多路视频处理系统，包括任务调度服务器、GPU服务器集群和推理服务器；

所述任务调度服务器用于获取所述GPU服务器集群内各节点的实时视频流处理量，并基于所述各节点的实时视频流处理量，向所述GPU服务器集群进行任务分发；

所述GPU服务器集群内的各节点用于接收分发到的任务对应的数据源地址信息和控制参数，根据所述数据源地址信息获取待处理视频流，根据所述控制参数，对所述待处理视频流进行解码抽帧处理，并将抽帧结果发送至所述推理服务器；其中，所述控制参数包括抽帧算法和抽帧间隔；

所述推理服务器用于对所述抽帧结果进行算法推理，得到视频处理结果。

进一步地，所述GPU服务器集群内的各节点提供任务管理接口和状态查询接口；

所述多路视频处理系统还包括集群管理服务器，所述集群管理服务器用于通过所述各节点的任务管理接口，管理所述GPU服务器集群内的所有节点，以及通过所述各节点的状态查询接口，查询所述各节点的任务状态。

进一步地，所述GPU服务器集群内的主节点提供IP列表接口；所述GPU服务器集群内的各节点还提供节点心跳接口和视频流处理情况的实时反馈接口；所述集群管理服务器提供负载能力查询接口；

所述GPU服务器集群内的各节点还用于通过实时反馈接口上报其实时视频流处理量；所述集群管理服务器用于通过所述主节点的IP列表接口获取所述GPU服务器集群中所有节点的IP地址信息，通过所述各节点的节点心跳接口对所述各节点进行心跳检测，以及通过所述各节点的实时反馈接口获取所述各节点上报的实时视频流处理量和所述各节点的处理视频流负载的最大能力值；所述任务调度服务器还用于通过所述集群管理服务器的负载能力查询接口，获取所述各节点的实时视频流处理量。

进一步地，所述任务调度服务器包括调度服务器和任务服务器；

所述调度服务器用于获取业务系统发送的携带有调度信息的视频处理请求，管理所述调度信息，以及按照所述调度信息向所述任务服务器发送调度请求；其中，所述调度信息包括数据源地址信息、抽帧算法和抽帧间隔；

所述任务服务器用于获取所述各节点的实时视频流处理量，并基于所述各节点的实时视频流处理量和接收到的调度请求，向所述GPU服务器集群进行任务分发。

进一步地，所述调度服务器支持可视化、动态的调度信息管理功能，以及调度结果监控功能和日志查询功能，所述调度信息管理功能包括任务新建、任务更新、任务删除和任务报警；所述任务服务器还用于接收并执行所述调度服务器的任务执行请求、任务终止请求和日志请求。

进一步地，所述任务服务器还用于基于预设的分发策略向所述GPU服务器集群进行任务分发；其中，所述分发策略包括熔断保护策略、最短路由策略、均衡策略和余量加权策略中的一种或多种。

第二方面，本发明实施例还提供了一种多路视频处理方法，应用于第一方面的多路视频处理系统；所述多路视频处理方法包括：

所述任务调度服务器获取所述GPU服务器集群内各节点的实时视频流处理量，并基于所述各节点的实时视频流处理量，向所述GPU服务器集群进行任务分发；

所述GPU服务器集群内的各节点接收分发到的任务对应的数据源地址信息和控制参数，根据所述数据源地址信息获取待处理视频流，根据所述控制参数，对所述待处理视频流进行解码抽帧处理，并将抽帧结果发送至所述推理服务器；其中，所述控制参数包括抽帧算法和抽帧间隔；

所述推理服务器对所述抽帧结果进行算法推理，得到视频处理结果。

进一步地，所述多路视频处理系统还包括集群管理服务器；所述多路视频处理方法还包括：

所述GPU服务器集群内的各节点基于分发到的任务的任务状态上报其实时视频流处理量；

所述集群管理服务器通过所述GPU服务器集群内主节点的IP列表接口获取所述GPU服务器集群中所有节点的IP地址信息，通过所述各节点的节点心跳接口对所述各节点进行心跳检测，以及通过所述各节点的实时反馈接口获取所述各节点上报的实时视频流处理量；

所述任务调度服务器通过所述集群管理服务器的负载能力查询接口，获取所述各节点的实时视频流处理量。

进一步地，所述基于所述各节点的实时视频流处理量，向所述GPU服务器集群进行任务分发，包括：

根据所述各节点的实时视频流处理量，计算得到所述GPU服务器集群的总视频流处理量；

根据所述总视频流处理量，确定目标分发策略；其中，所述目标分发策略包括熔断保护策略、最短路由策略、均衡策略和余量加权策略中的一种；

根据所述目标分发策略，确定待分发的当前任务对应的候选节点；

当所述候选节点的实时视频流处理量小于或等于预设的节点阈值时，将所述候选节点确定为所述待分发的当前任务对应的目标节点。

进一步地，所述根据所述总视频流处理量，确定目标分发策略，包括：

当所述GPU服务器集群的总视频流处理量小于或等于预设的第一集群阈值时，确定所述目标分发策略为最短路由策略；

当所述GPU服务器集群的总视频流处理量大于所述第一集群阈值且小于或等于预设的第二集群阈值时，确定所述目标分发策略为均衡策略；

当所述GPU服务器集群的总视频流处理量大于所述第二集群阈值且小于或等于预设的第三集群阈值时，确定所述目标分发策略为余量加权策略；

当所述GPU服务器集群的总视频流处理量大于所述第三集群阈值时，确定所述目标分发策略为熔断保护策略；

其中，所述第三集群阈值大于所述第二集群阈值，所述第二集群阈值大于所述第一集群阈值。

本发明实施例提供的多路视频处理系统及方法中，多路视频处理系统包括任务调度服务器、GPU服务器集群和推理服务器；任务调度服务器用于获取GPU服务器集群内各节点的实时视频流处理量，并基于各节点的实时视频流处理量，向GPU服务器集群进行任务分发；GPU服务器集群内的各节点用于接收分发到的任务对应的数据源地址信息和控制参数，根据数据源地址信息获取待处理视频流，根据控制参数，对待处理视频流进行解码抽帧处理，并将抽帧结果发送至推理服务器；其中，控制参数包括抽帧算法和抽帧间隔；推理服务器用于对抽帧结果进行算法推理，得到视频处理结果。这样将解码抽帧与算法推理完全解耦，将解码抽帧与算法推理的依赖减小到最低，真正解放了算法推理服务，因此能够充分发挥GPU运算优势，保证抽帧的速度与质量；抽帧服务集群化，且基于各节点的实时视频流处理量，向GPU服务器集群进行任务分发，能够分担全链路的时延与存储压力，保证几百路，甚至上千路视频并发处理的稳定性与效率，从而提供了确定的时延保障，同时具有灵活且可水平拓展的优点。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种多路视频处理系统的结构示意图；

图2为本发明实施例提供的一种集群管理服务器对GPU服务器集群进行节点管理的原理示意图；

图3为本发明实施例提供的一种多路视频处理系统的整体流程示意图；

图4为本发明实施例提供的一种多路视频处理方法的流程示意图；

图5为本发明实施例提供的一种任务分发的策略流程图。

具体实施方式

下面将结合实施例对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

抽帧是在一段视频中，通过间隔一定帧抽取若干帧的方式，模拟每隔一段时间拍摄一张照片并接合起来形成视频的过程。视频流的解码抽帧，其主要工作在于矩阵变换，矩阵变换具有计算量大、重复度高的特点，GPU（graphics processing unit，图形处理器）擅长进行大量的重复性的数学运算。基于此，本发明实施例提供了一种基于GPU抽帧服务化与分布式任务调度的多路视频处理系统及方法，拟在服务层进行解耦，将解码抽帧服务化并以集群的方式部署于多台GPU服务器，真正解放算法推理服务，且分担全链路的时延与存储压力，保证多路视频并发处理的稳定性与效率。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种多路视频处理系统进行详细介绍。

参见图1所示的一种多路视频处理系统的结构示意图，该多路视频处理系统包括任务调度服务器110、GPU服务器集群120和推理服务器130；任务调度服务器110用于获取GPU服务器集群内各节点的实时视频流处理量，并基于各节点的实时视频流处理量，向GPU服务器集群120进行任务分发；GPU服务器集群120内的各节点用于接收分发到的任务对应的数据源地址信息和控制参数，根据数据源地址信息获取待处理视频流，根据控制参数，对待处理视频流进行解码抽帧处理，并将抽帧结果发送至推理服务器130；其中，控制参数包括抽帧算法和抽帧间隔；推理服务器130用于对抽帧结果进行算法推理，得到视频处理结果。

上述数据源地址信息可以包括设备ID、通道ID和视频流地址等；控制参数可以包括抽帧算法、抽帧间隔、是否保存图片和算法参数（如置信度等）等。各节点还可以接收分发到的任务对应的任务参数，该任务参数可以包括任务编号、任务ID（如XXLjob ID）、任务名称、任务类型（实时任务或定时任务）、任务状态（任务的执行状态）、操作状态（仅记录在调度服务器111）、创建时间、更新时间、执行周期、实时任务的结束时间、结果输出的主题和任务结果类型等。

上述GPU服务器集群120由多台GPU服务器构成，每台GPU服务器作为一个节点。在一种可能的实现方式中，服务器集群120内的各节点可以发送携带有抽帧结果的推理请求给推理服务器130，其中，抽帧结果包括多个图片，图片名称中可以包括抽帧时间信息、结果输出的主题（订阅的topic）、任务ID（任务编号）、批次号（指任务执行第几次）和数据源地址信息等信息。推理服务器130得到的视频处理结果可以存储在对象存储服务器上，通过结果输出的主题发送任务ID、批次号、数据源地址信息、图片存储地址信息等至消息服务器（如Kafka服务器）；需求方（业务系统）通过订阅消息，得到视频处理结果。推理服务器130可以采用集群化部署，也可以采用单个服务器，本实施例对此不做限定。

本发明实施例提供的多路视频处理系统，将解码抽帧与算法推理完全解耦，将解码抽帧与算法推理的依赖减小到最低，真正解放了算法推理服务，因此能够充分发挥GPU运算优势，保证抽帧的速度与质量；抽帧服务集群化，且基于各节点的实时视频流处理量，向GPU服务器集群进行任务分发，能够分担全链路的时延与存储压力，保证几百路，甚至上千路视频并发处理的稳定性与效率，从而提供了确定的时延保障，同时具有灵活且可水平拓展的优点。

在一些可能的实施例中，为了方便GPU服务器集群的管理，上述GPU服务器集群120内的各节点提供任务管理接口和状态查询接口；上述多路视频处理系统还包括集群管理服务器140，集群管理服务器140用于通过各节点的任务管理接口，管理GPU服务器集群120内的所有节点，以及通过各节点的状态查询接口，查询各节点的任务状态。

集群管理服务器140可以部署在GPU服务器集群120内的任一个节点所在的设备中，也可以部署在其他设备中，本实施例对此不做限定。集群管理服务器140负责管理运行抽帧服务的GPU服务器集群120，例如任务的新建、启动、中断、停止、删除等，还可以主动查询各节点的任务状态。

上述GPU服务器集群120内的节点可以分为主节点和副节点两类，主节点只有一个，副节点可以为一个或多个，主节点还需负责监控GPU服务器集群120内所有节点的网络地址列表。GPU服务器集群120内的主节点可以提供IP列表接口；GPU服务器集群120内的各节点还提供节点心跳接口和视频流处理情况的实时反馈接口；集群管理服务器140提供负载能力查询接口。在此情况下，GPU服务器集群120内的各节点还用于通过实时反馈接口上报其实时视频流处理量；集群管理服务器140用于通过主节点的IP列表接口获取GPU服务器集群120中所有节点的IP地址信息，通过各节点的节点心跳接口对各节点进行心跳检测，以及通过各节点的实时反馈接口获取各节点上报的实时视频流处理量和各节点的处理视频流负载的最大能力值；任务调度服务器110还用于通过集群管理服务器140的负载能力查询接口，获取各节点的实时视频流处理量。

任务调度服务器110不仅可以获取各节点上报的实时视频流处理量（如节点正在处理的视频流路数），还可以通过主动查询的方式，获取各个节点处理视频流负载的最大能力值（如节点所能处理的视频流路数上限），即对各个节点进行能力初始化查询。其中，实时视频流处理量和处理视频流负载的最大能力值均可以用视频流路数表示，例如，某个节点的处理视频流负载的最大能力值为1000路，实时视频流处理量为600路。

为了便于理解，参见图2所示的一种集群管理服务器对GPU服务器集群进行节点管理的原理示意图，GPU服务器集群120包括节点一、节点二和节点三，其中节点二为主节点；三个节点可以向集群管理服务器140进行心跳上报和状态变化上报，其中心跳上报指主动上报心跳到集群管理服务器140，状态变化上报指当视频流处理开始或结束时（这里的处理指解码抽帧），向集群管理服务器140主动上报实时消息（实时视频流处理量）；节点二作为主节点还会将所有节点的IP列表信息上报给集群管理服务器140；集群管理服务器140可以通过主动查询的方式获取各个节点处理视频流负载的最大能力值，即对各个节点进行能力初始化查询；集群管理服务器140将得到的相关数据（包括各个节点上报的心跳和实时视频流处理量，以及各个节点处理视频流负载的最大能力值等）存入Redis数据库服务器，Redis数据库服务器对外暴露负载能力查询接口。

在一些可能的实施例中，为了提高系统整体稳定性和扩展性，如图1所示，上述任务调度服务器110包括调度服务器111和任务服务器112；调度服务器111用于获取业务系统发送的携带有调度信息的视频处理请求，管理调度信息，以及按照调度信息向任务服务器112发送调度请求；其中，调度信息包括数据源地址信息、抽帧算法和抽帧间隔；任务服务器112用于获取各节点的实时视频流处理量，并基于各节点的实时视频流处理量和接收到的调度请求，向GPU服务器集群120进行任务分发。这样通过将任务调度服务器110的“调度”和“任务”解耦，提高了系统整体稳定性和扩展性。

其中，调度服务器111可以与一个或多个业务系统对接，业务系统可以包括如交管部门道路养护的业务系统等。业务系统可以发送调度请求给调度服务器111，调度请求可以携带有如下信息：抽帧算法（如人和非机动车识别算法、未带头盔检测算法、道路破损检测算法、未礼让行人检测算法等中的一种或多种）、算法参数（如置信度）、数据源地址信息（即视频流地址信息，可以包括设备ID、通道ID、视频流地址）、与实时任务对应的给定结束时间、结果输出的主题（自定义的topic）、任务结果类型（若无结果数据时，是否保存结果）、抽帧间隔和任务来源（用于标识来自哪个业务系统）等。

可选地，上述调度服务器111支持可视化、动态的调度信息管理功能，以及调度结果监控功能和日志查询功能，调度信息管理功能包括任务新建、任务更新、任务删除和任务报警；任务服务器112还用于接收并执行调度服务器111的任务执行请求、任务终止请求和日志请求。

调度服务器111新增一个任务时，插入一条任务数据到任务列表（用户可以查询、编辑任务列表），调度服务器111还有日志管理功能（可以基于日志进行告警和原因追溯等）、状态管理功能（如任务的开启和中断等）。调度服务器111与任务服务器112建立连接后，可以通过数据流的方式将任务参数发送给任务服务器112，通过HTTP（Hyper TextTransfer Protocol，超文本传输协议）协议调用任务服务器112的相应执行器，其中，任务参数可以包括任务编号、任务ID（如XXLjob ID）、任务名称、任务类型（实时任务或定时任务）、任务状态（任务的执行状态）、操作状态（仅记录在调度服务器111）、创建时间、更新时间、执行周期、实时任务的结束时间、任务来源、结果输出的主题和任务结果类型等。任务服务器112具有线程池，一个执行器对应线程池中的一个线程。

上述执行周期可以是实时任务对应的Cron表达式或定时任务对应的人工设置的任务执行间隔，其中，实时任务对应的Cron表达式可以根据实时任务对应的给定结束时间确定，6位的CRON表达式用于表达诸如每分钟的第几秒执行一次；任务执行间隔要求大于或等于抽帧间隔。

优选地，上述任务服务器112还用于基于预设的分发策略向GPU服务器集群进行任务分发；其中，分发策略包括熔断保护策略、最短路由策略、均衡策略和余量加权策略中的一种或多种。

任务服务器112内置视频流分发策略：1.轮询策略，每路视频流按照列表顺序均匀分配至不同的节点；2.余量加权策略，权重与节点当前剩余的处理能力（即节点余量）成正比，处理能力用节点最大处理量与当前处理量（实时视频流处理量）的差值来衡量；3.最短路由策略，在大型分布式系统中，设计了容灾备份机制，而一个真实的物理节点（或云节点）上可能同时存在多个服务，这些服务在某些场景下会有通信需求，对视频流地址进行IP解析，再与抽帧节点IP进行路由追踪比对，找出最快路由的抽帧节点，降低网络层时延；4.熔断保护策略：当处理量超过饱和量的75%（该阈值可以根据实际需求设置）时触发，保证GPU服务器集群以及节点的鲁棒性。

为了便于理解，下面参照图3对上述多路视频处理系统的整体流程进行介绍：

1）业务系统向调度服务器发起视频处理请求。

2）用户打开调度服务器对应的调度中心页面时，调度服务器判断是否新增任务。

3）如果新增任务，则从海量视频设备中拉取视频流结构化数据（即数据源地址信息），确定生成任务成功，然后根据任务类型判断是否立即启动任务。如果任务类型为实时任务，则立即启动任务，向任务服务器发送相应的调度请求。如果任务类型为定时任务，则判断当前时间是否满足启动时间要求，如果不满足，则不启动任务，结束；如果满足，则立即启动任务，向任务服务器发送相应的调度请求。

4）如果未新增任务，则用户可以预览任务列表，修改任务信息，决定是否立即启动任务。若不启动任务，则结束；若立即启动任务，向任务服务器发送相应的调度请求。

5）任务服务器通过执行器执行任务，包括通过集群管理服务器拉取GPU服务器集群中各节点的实时视频流处理量，以及任务分发。

6）GPU服务器集群中每个节点的抽帧服务用于进行相应任务的解码抽帧处理，抽帧服务在解码抽帧之后，调用所在节点的算法客户端的相关接口，向推理服务器的算法服务端发起推理请求；算法服务端提供算法推理服务，算法服务端还响应算法客户端的回调。

本发明实施例拟在服务层进行解耦，将解码抽帧服务化并以集群的方式部署于多台GPU服务器，该解码抽帧服务可以遵循HTTP协议。GPU服务器集群内各节点接收上层的业务系统传入的多路视频流与任务参数，主节点提供GPU服务器集群内各节点的IP列表接口，各节点提供节点心跳接口与视频流处理情况的实时反馈接口，实时反馈接口主要反馈各个节点所能处理的视频流路数上限与正在处理的视频流路数，任务调度服务器通过实时感知实现联动处理，可以对当前任务所要处理的视频流进行动态分配，将视频流分发至不同的节点。

上述多路视频处理系统涉及如下五个部分：视频流输入模块、算法模块、解码抽帧模块、任务调度模块和GPU集群管理模块：

1.视频流输入模块：与真实摄像头（视频设备）建立连接，提供视频流列表信息，支持精确/模糊/条件查询，支持批量选中。

2.算法模块：包含位于GPU服务器集群的每个节点内的算法客户端（client端）与位于推理服务器内的算法服务端（server端）两个部分，抽帧服务在解码抽帧之后，调用client端的相关接口，向server端发起推理请求。server端仅提供推理服务，不承担任何业务逻辑，是一种无状态服务。

3.解码抽帧模块：位于GPU服务器集群的每个节点内，包含两个核心功能与一个对外暴露的服务。核心功能一为解码抽帧，发挥GPU优势，保证抽帧的频率与制品（制品指抽帧结果，其具有一定分辨率要求）满足算法推理的要求；核心功能二为调用client端接口，接收上层业务系统传递的流地址信息、控制参数和任务参数，结合功能一，完成本次任务所有流的解码抽帧处理。服务对内使用全局变量监控本节点的流处理情况，对外暴露相关接口，包括节点心跳接口（主动上报）、实时反馈接口（发生变化时主动上报），以及实时任务与定时任务的新建、启动、中断、停止、删除的任务管理接口和状态查询接口（被动查询），其中，位于主节点的服务还需负责监控集群内所有节点的网络地址列表。

4.任务调度模块（任务调度服务器）：将“调度模块”（调度服务器）和“任务模块”（任务服务器）完全解耦，调度模块进行任务调度时，将会解析不同的任务参数发起远程调用，调用各自的远程执行器服务。调度模块负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度模块与任务模块解耦，提高了系统可用性和稳定性，同时调度模块的性能不再受限于任务模块；支持可视化、简单且动态的管理调度信息，包括任务新建、更新、删除、GLUE开发和任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志。其中，执行器需要后端开发接口逻辑，可以在前端的代码编辑界面，编辑执行器的代码；GLUE是一种组件库，GLUE开发指在前端的代码编辑界面上，通过基于GLUE的可视化方式编写java源码，实现执行器的后端开发。

任务模块负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效；接收“调度模块”的执行请求、终止请求和日志请求等。

任务模块内置视频流分发策略，包括：熔断保护策略、最短路由策略、均衡策略和余量加权策略。

5.GPU集群管理模块（集群管理服务器）：该模块负责管理运行抽帧服务的GPU服务器集群，通过主节点的IP列表接口获取GPU服务器集群中所有节点的IP信息，获取地址以后，逐一对GPU服务器集群内各个节点进行心跳检测，通过主动查询的方式获取各个节点处理视频流负载的最大能力值，对各个节点进行能力初始化查询。

运行于各个节点的抽帧服务，通过全局变量获取当前节点正在处理的视频流路数，当视频流处理开始或结束时（这里的处理指解码抽帧），向GPU集群管理模块上报实时消息。GPU集群管理模块缓存各节点的负载情况（实时视频流处理量）。

当开启一个新任务时，任务模块的执行器调用GPU集群管理模块的负载能力查询接口，拉取抽帧服务各节点正在处理的实时视频路数（实时视频流处理量），通过执行器内置的负载均衡器确定最优的分发策略，将本次任务的视频流分发至不同的GPU节点。

和现有技术相比，主要优势在于：

1.将解码抽帧与算法推理完全解耦，真正解放算法推理服务。可以利用FFmpeg（FFmpeg是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序）充分发挥GPU运算优势，保证抽帧的速度与质量。经过测试，同等环境下，与直接调用SDK（Software Development Kit，软件开发工具包）的方式相比，抽帧的耗费时间被压缩了10倍，且这一数值不会受到视频路数增加的影响，中途也不存在图像丢失问题，与算法推理过程实现完全异步。通过封装成服务的方式隐藏内部逻辑，对外提供标准化接口，易于拓展。

2.抽帧服务集群化，分担全链路的时延与存储压力，保证几百路，甚至上千路视频并发处理的稳定性与效率，可通过主节点与GPU集群管理模块对GPU服务器集群进行状态监控与实时感知。

3.将“任务”与“调度”完全解耦，提高系统整体稳定性和扩展性。

4.四种视频流分发策略面向分布式场景，选择多样且可以灵活组合。

一种示例性的具体实现方式如下：

1.在路口部署枪球一体机（枪球一体机采用一体化设计，由2镜头相机与2颗高性能GPU模块组成），经由设备管理平台提供设备的视频流列表。可以根据路口位置、街道名称、设备厂家等字段对数据源进行筛选，批量选中，选中后的列表包含枪球一体机的视频流地址信息。

2.任务调度模块的数据库使用MYSQL，调度中心（调度模块）与任务中心（任务模块）的执行器分布式部署，其中调度中心实现任务管理、执行器管理、日志管理、运行报表、失败告警等功能。任务中心的调度采用线程池方式实现，避免单线程因阻塞而引起任务调度延迟。执行器实际上是一个内嵌的Server，JAVA语言实现。在项目启动时，执行器会通过“@JobHandler”识别Spring容器中“Bean模式任务”，以注解的value属性为key管理起来。“执行器”接收到“调度中心”的调度请求时，如果任务类型为“Bean模式”，将会匹配Spring容器中的“Bean模式任务”，然后调用其execute方法，执行任务逻辑。如果任务类型为“GLUE模式”，将会加载GLue代码，实例化Java对象，注入依赖的Spring服务。

3.解码抽帧模块：包含两个核心线程与一个对外暴露的HTTP服务。采用C++语言编写，线程一为解码抽帧线程，调用FFmpeg函数，接收单路视频流与抽帧间隔，发挥GPU的优势，保证抽帧的频率与制品满足算法推理的要求；线程二主要调用Triton客户端的接口（Triton是一个深度学习的框架），接收上层业务系统传递的视频流地址信息、控制参数和任务参数，根据业务要求，循环调用线程一，直至本次任务所有流抽帧处理完毕，并推送至Triton服务端为结束。HTTP服务对内使用全局Map监控整个GPU服务器集群的流处理情况，对外暴露接口，包括节点心跳接口、实时反馈接口，以及实时任务与定时任务的新建、启动、中断、停止、删除的任务管理接口和状态查询接口。

4.算法模块使用Triton语言编写，client端与抽帧服务绑定部署于GPU服务器集群的各个节点，抽帧服务在解码抽帧之后，调用Triton客户端的相关接口，将抽帧结果集以及控制参数一并传递过去，由Triton客户端向Triton服务集群发起推理请求。

5.GPU集群管理模块：该模块使用JAVA语言实现，通过GPU服务器集群主节点的IP列表接口获取GPU服务器集群中所有节点的IP信息，消费GPU服务器集群节点上报的心跳消息，保证节点的正确性与可用性，通过调用GPU服务器集群节点的状态查询接口和实时反馈接口，对各个节点进行初始化。

GPU服务器集群内各个节点的抽帧服务，通过全局的Map变量获取当前节点正在处理的视频流路数，当视频流处理开始或结束时，作为生产者向上报实时消息。本GPU集群管理模块作为消费者，获取各节点最新的处理情况，并将其维护于Redis缓存数据库中，并对外暴露负载能力查询接口。

综上，本发明实施例提出了一种视频解析类算法领域的分布式高可用架构；将基于GPU的视频流解码抽帧工作，通过服务化、集群化实现异步高可用与高延展性，并通过GPU集群管理模块实现可视化管理与标准接口提供；在视频解析算法面向分布式高并发的场景下，将“调度”与“任务”完全解耦；视频解析算法在处理多路视频流时可以采用四种分发均衡策略。

和现有技术相比，主要创造性在于：

1. 解码抽帧与算法推理解耦，将抽帧与算法推理的依赖减小到最低。

2. 抽帧服务集群化管理，灵活且可水平拓展。

3. 将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。

4. 面向分布式算法推理场景，提出了四种视频流分发均衡策略。

本发明实施例还提供了一种多路视频处理方法，该方法应用于上述的多路视频处理系统。参见图4所示的一种多路视频处理方法的流程示意图，该方法主要包括如下步骤S402~步骤S406：

步骤S402，任务调度服务器获取GPU服务器集群内各节点的实时视频流处理量，并基于各节点的实时视频流处理量，向GPU服务器集群进行任务分发。

步骤S404，GPU服务器集群内的各节点接收分发到的任务对应的数据源地址信息和控制参数，根据数据源地址信息获取待处理视频流，根据控制参数，对待处理视频流进行解码抽帧处理，并将抽帧结果发送至推理服务器；其中，控制参数包括抽帧算法和抽帧间隔。

步骤S406，推理服务器对抽帧结果进行算法推理，得到视频处理结果。

在一些可能的实施例中，上述多路视频处理系统还包括集群管理服务器；基于此，上述方法还包括：GPU服务器集群内的各节点基于分发到的任务的任务状态上报其实时视频流处理量；集群管理服务器通过GPU服务器集群内主节点的IP列表接口获取GPU服务器集群中所有节点的IP地址信息，通过各节点的节点心跳接口对各节点进行心跳检测，以及通过各节点的实时反馈接口获取各节点上报的实时视频流处理量；任务调度服务器通过集群管理服务器的负载能力查询接口，获取各节点的实时视频流处理量。

在一些可能的实施例中，上述步骤S402中，基于各节点的实时视频流处理量，向GPU服务器集群进行任务分发可以通过如下方式实现：根据各节点的实时视频流处理量，计算得到GPU服务器集群的总视频流处理量，总视频流处理量可以等于各节点的实时视频流处理量之和；根据总视频流处理量，确定目标分发策略；其中，目标分发策略包括熔断保护策略、最短路由策略、均衡策略和余量加权策略中的一种；根据目标分发策略，确定待分发的当前任务对应的候选节点；当候选节点的实时视频流处理量小于或等于预设的节点阈值时，将候选节点确定为待分发的当前任务对应的目标节点。

优选地，确定目标分发策略的方式可以如下：当GPU服务器集群的总视频流处理量小于或等于预设的第一集群阈值时，确定目标分发策略为最短路由策略；当GPU服务器集群的总视频流处理量大于第一集群阈值且小于或等于预设的第二集群阈值时，确定目标分发策略为均衡策略；当GPU服务器集群的总视频流处理量大于第二集群阈值且小于或等于预设的第三集群阈值时，确定目标分发策略为余量加权策略；当GPU服务器集群的总视频流处理量大于第三集群阈值时，确定目标分发策略为熔断保护策略；其中，第三集群阈值大于第二集群阈值，第二集群阈值大于第一集群阈值。

例如，第一集群阈值为集群最大负载能力的25%，第二集群阈值为集群最大负载能力的50%，第三集群阈值为集群最大负载能力的75%。集群最大负载能力指通过能力初始化查询得到的各个节点的最大能力值之和。

为了便于理解，如图5所示，一种可能的任务分发策略如下：

首先，判断GPU服务器集群的总视频流处理量是否为集群最大负载能力的25%以下，得到第一判断结果。

如果第一判断结果为是，则采用最短路由策略确定候选节点。

如果第一判断结果为否，则判断GPU服务器集群的总视频流处理量是否为集群最大负载能力的50%以下，得到第二判断结果。

如果第二判断结果为是，则采用均衡策略确定候选节点。

如果第二判断结果为否，则判断GPU服务器集群的总视频流处理量是否为集群最大负载能力的75%以下，得到第三判断结果。

如果第三判断结果为是，则采用余量加权策略确定候选节点。

如果第三判断结果为否，则采用熔断保护策略，进行熔断返回（此次任务无法分发），结束。

当确定出候选节点时，判断候选节点的实时视频流处理量是否为节点最大负载能力的75%以下，如果是，则进行任务分发，分发成功，结束；如果否，则采用熔断保护策略，进行节点熔断，结束。

本实施例所提供的多路视频处理方法，其实现原理及产生的技术效果和前述多路视频处理系统实施例相同，为简要描述，多路视频处理方法实施例部分未提及之处，可参考前述多路视频处理系统实施例中相应内容。

在这里示出和描述的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制，因此，示例性实施例的其他示例可以具有不同的值。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (10)

1.一种多路视频处理系统，其特征在于，包括任务调度服务器、GPU服务器集群和推理服务器；

所述任务调度服务器用于获取所述GPU服务器集群内各节点的实时视频流处理量，并基于所述各节点的实时视频流处理量，向所述GPU服务器集群进行任务分发；

所述GPU服务器集群内的各节点用于接收分发到的任务对应的数据源地址信息和控制参数，根据所述数据源地址信息获取待处理视频流，根据所述控制参数，对所述待处理视频流进行解码抽帧处理，并将抽帧结果发送至所述推理服务器；其中，所述控制参数包括抽帧算法和抽帧间隔；

所述推理服务器用于对所述抽帧结果进行算法推理，得到视频处理结果。

2.根据权利要求1所述的多路视频处理系统，其特征在于，所述GPU服务器集群内的各节点提供任务管理接口和状态查询接口；

所述多路视频处理系统还包括集群管理服务器，所述集群管理服务器用于通过所述各节点的任务管理接口，管理所述GPU服务器集群内的所有节点，以及通过所述各节点的状态查询接口，查询所述各节点的任务状态。

3.根据权利要求2所述的多路视频处理系统，其特征在于，所述GPU服务器集群内的主节点提供IP列表接口；所述GPU服务器集群内的各节点还提供节点心跳接口和视频流处理情况的实时反馈接口；所述集群管理服务器提供负载能力查询接口；

所述GPU服务器集群内的各节点还用于通过实时反馈接口上报其实时视频流处理量；所述集群管理服务器用于通过所述主节点的IP列表接口获取所述GPU服务器集群中所有节点的IP地址信息，通过所述各节点的节点心跳接口对所述各节点进行心跳检测，以及通过所述各节点的实时反馈接口获取所述各节点上报的实时视频流处理量和所述各节点的处理视频流负载的最大能力值；所述任务调度服务器还用于通过所述集群管理服务器的负载能力查询接口，获取所述各节点的实时视频流处理量。

4.根据权利要求1所述的多路视频处理系统，其特征在于，所述任务调度服务器包括调度服务器和任务服务器；

所述调度服务器用于获取业务系统发送的携带有调度信息的视频处理请求，管理所述调度信息，以及按照所述调度信息向所述任务服务器发送调度请求；其中，所述调度信息包括数据源地址信息、抽帧算法和抽帧间隔；

所述任务服务器用于获取所述各节点的实时视频流处理量，并基于所述各节点的实时视频流处理量和接收到的调度请求，向所述GPU服务器集群进行任务分发。

5.根据权利要求4所述的多路视频处理系统，其特征在于，所述调度服务器支持可视化、动态的调度信息管理功能，以及调度结果监控功能和日志查询功能，所述调度信息管理功能包括任务新建、任务更新、任务删除和任务报警；所述任务服务器还用于接收并执行所述调度服务器的任务执行请求、任务终止请求和日志请求。

6.根据权利要求4所述的多路视频处理系统，其特征在于，所述任务服务器还用于基于预设的分发策略向所述GPU服务器集群进行任务分发；其中，所述分发策略包括熔断保护策略、最短路由策略、均衡策略和余量加权策略中的一种或多种。

7.一种多路视频处理方法，其特征在于，应用于权利要求1-6中任一项所述的多路视频处理系统；所述多路视频处理方法包括：

所述任务调度服务器获取所述GPU服务器集群内各节点的实时视频流处理量，并基于所述各节点的实时视频流处理量，向所述GPU服务器集群进行任务分发；

所述GPU服务器集群内的各节点接收分发到的任务对应的数据源地址信息和控制参数，根据所述数据源地址信息获取待处理视频流，根据所述控制参数，对所述待处理视频流进行解码抽帧处理，并将抽帧结果发送至所述推理服务器；其中，所述控制参数包括抽帧算法和抽帧间隔；

所述推理服务器对所述抽帧结果进行算法推理，得到视频处理结果。

8.根据权利要求7所述的多路视频处理方法，其特征在于，所述多路视频处理系统还包括集群管理服务器；所述多路视频处理方法还包括：

所述GPU服务器集群内的各节点基于分发到的任务的任务状态上报其实时视频流处理量；

所述集群管理服务器通过所述GPU服务器集群内主节点的IP列表接口获取所述GPU服务器集群中所有节点的IP地址信息，通过所述各节点的节点心跳接口对所述各节点进行心跳检测，以及通过所述各节点的实时反馈接口获取所述各节点上报的实时视频流处理量；

所述任务调度服务器通过所述集群管理服务器的负载能力查询接口，获取所述各节点的实时视频流处理量。

9.根据权利要求7所述的多路视频处理方法，其特征在于，所述基于所述各节点的实时视频流处理量，向所述GPU服务器集群进行任务分发，包括：

根据所述各节点的实时视频流处理量，计算得到所述GPU服务器集群的总视频流处理量；

根据所述总视频流处理量，确定目标分发策略；其中，所述目标分发策略包括熔断保护策略、最短路由策略、均衡策略和余量加权策略中的一种；

根据所述目标分发策略，确定待分发的当前任务对应的候选节点；

当所述候选节点的实时视频流处理量小于或等于预设的节点阈值时，将所述候选节点确定为所述待分发的当前任务对应的目标节点。

10.根据权利要求9所述的多路视频处理方法，其特征在于，所述根据所述总视频流处理量，确定目标分发策略，包括：

当所述GPU服务器集群的总视频流处理量小于或等于预设的第一集群阈值时，确定所述目标分发策略为最短路由策略；

当所述GPU服务器集群的总视频流处理量大于所述第一集群阈值且小于或等于预设的第二集群阈值时，确定所述目标分发策略为均衡策略；

当所述GPU服务器集群的总视频流处理量大于所述第二集群阈值且小于或等于预设的第三集群阈值时，确定所述目标分发策略为余量加权策略；

当所述GPU服务器集群的总视频流处理量大于所述第三集群阈值时，确定所述目标分发策略为熔断保护策略；

其中，所述第三集群阈值大于所述第二集群阈值，所述第二集群阈值大于所述第一集群阈值。

Images