基于嵌入式边缘设备的端-边-云视频流分析系统构建*

朱锦辉

（中国人民解放军91404部队 秦皇岛 066001）

1 引言

近几年来，卷积神经网络的崛起推动着视频流分析应用快速发展，并造就了高效率、高准确度的视频流分析水准。监控摄像头被广泛部署，如部署于商场中、街道上、无人机机身上等。随着应用范围的不断扩大，对视频流分析的要求也越来越高［1～3］。特别是在智慧军营中，要求同时对大范围内的大量视频流进行分析，并且需要及时、准确地得到分析反馈。针对以上问题，本文设计了一项端-边-云计算架构之上的兼顾边-云间数据传输时延和边缘节点硬件资源受限特性的视频流分析任务调度策略 VideoEmbedded［4～7］，根据视频流分析请求的特性来进行任务调度，在保证推理准确度的前提下，提高视频流分析的实时性，降低整体系统资源占用。同时，本文设计了一套基于Docker容器技术、K8s（Kubernetes）容器编排技术的端-边-云视频流分析系统，其具有良好弹性伸缩能力和自动化运营能力。

2 端-边-云视频流分析系统构建

在端-边-云计算架构中［8～10］，智能服务（如车辆检测、车色识别等）可部署于边缘节点和云节点上。边缘节点的优势是其与移动设备更近，且它们间具有更低的数据传输延迟和更大的带宽。在一般负载情况下，视频流分析应用的连续性是比较好保证的（实现足够多的并行化），而应用的实时性更受任务调度的影响，故本文提出的VideoEmbedded任务调度策略将以实时性为最优化目标。

VideoEdge在第二阶段进行请求合并，即对智能服务进行复用。而VideoEmbedded是一阶段的，即一开始就对智能服务进行复用。以视频流车辆信息分析为例（分析任务包括车辆检测、车色识别、车牌检测和车牌识别），表1列举出了与一个请求Qi相关的符号表示。

表1 与请求i相关的符号表示

所以VideoEmbedded对智能服务复用的约束可表示为式（1）～（6）。

需要求的最优项为（实时性优先）式（7）。

上述的最优解问题是一个NP难问题，假设有m个请求，各智能服务有n种不同准确度的智能模型可选，则暴力求解该问题的时间复杂度为O（（m·（m-1）…1）n3）。为降低求解时间复杂度，下面根据不同请求的不同特性来将该问题简化以求一较优解。

视频流分析的输出结果一般有两种［11～13］：

1）输出结果仍为视频流，与原视频流相比，输出的视频流可能在编码方式、色域、分辨率、帧率等方面发生改变，并且往往是带有智能信息的。

2）输出结果为智能信息结构化数据，即将在智能分析过程中所得的智能信息存储起来。

对于这两种不同的输出结果，做不同的考虑：

1）输出结果仍为视频流的请求，其特点是需要对输入视频流进行逐帧智能分析，且最终输出的视频流还是要传输到云上去的，因为用户是通过云来获取输出视频流的。故对这种请求应该将任务优先迁移至云上执行，因为这样做能够节省边缘资源。

2）输出结果为智能信息结构化数据的请求，其特点是需要对输入视频流进行抽帧智能分析，同时要传输到云上去的智能信息结构化数据相比于视频流要小得多。故对这种请求应该将任务优先迁移至边缘节点上执行，因为这样做能够节省边-云间带宽。

系统整体架构设计将边缘分为多个区域，每个区域都会部署一些Worker节点，在Worker节点之上可以按需部署智能服务和其它服务。同样在云上也会部署Worker节点，这些Worker节点由云上的Master节点统一管理。将所有服务程序都置于Docker容器中运行，启用多个K8s Master热备份节点，在多个K8s Master节点之上，使用keepalived工具来向外提供虚拟Socket（IP：Port），并使用haproxy工具来保证多个K8s Master节点间的负载均衡，从而使K8s集群具有较高的可靠性。

对于每个K8s Pod，其只拥有一个Docker容器。图1使用Deployment控制器来部署智能服务、页面前端等无状态的服务；使用StatefulSet控制器来部署MySQL数据库、Kafka消息队列等有状态的服务。在服务发现方面，使用ClusterIP类型的Service来在集群内部暴露Pod服务，使用NodePort类型的Service来向集群外部暴露Pod服务。

图1 服务部署

用户通过Web前端来发起视频流实时智能分析请求，也可以发起对输出视频流或智能信息结构化数据的检索等请求，在图2示例中，在最大化智能服务和逻辑进程中接入视频流以对其进行智能分析，将智能信息结构化数据的输出结果发布至Kafka消息队列，对于携带智能信息的视频流输出结果，将其推给Nginx RTMP服务器。

图2 任务调度

3 对比实验

3.1 实验设计

如图3所示，实验中使用两台Atlas200DK组成一个边缘区域，使用6台服务器组成一个私有云（其中代理服务器位于K8s集群之外）。

图3 实验环境

如表2，在智能组件中使用到6种模型——4种检测模型和两种分类模型，对于车牌识别，使用HyperLPR；对于对象跟踪（只在输出结果为视频流时启用），使用Kalman。为方便阐述，我们分别将准确度和体积分为4个等级（A、B、C和D，准确度递减，体积递增），并给每台Atlas200DK分配8个槽位（以第2节实验结果为依据），给每张显卡分配20个槽位（以500 MB显存为一槽位，每张显卡预留1～2 GB显存）。为保证应用的连续性，限制Atlas200DK、Worker01、Worker02和Worker03上的可使用线程数分别为7、20、20和32（云服务器的CPU主频更高）。对于VideoEdge中的主资源需求（Dominant Resource Demand），仅考虑主要的带宽（边-云间带宽以恒定的90.5 Mbits/s来计算，在服务部署时保证负载均衡（以一台设备上的资源占用百分比为依据，先优先槽位占用的均衡，其次是线程占用）。

表2 智能组件中使用到的模型

如表3，共设计了3组视频流实时智能分析请求，其中每个请求都需要进行所有的智能分析（车辆检测、车牌检测、车牌识别、车色识别）。若输出结果为视频流，则请求的处理帧率为25 FPS，对所有智能组件准确度的要求皆为B；否则请求的处理帧率为1 FPS，针对智能组件准确度的要求，又需进行三组不同的实验：所有要求皆为B（组合1）、所有要求皆为D（组合2）、分别在720P和1080P请求中一半要求为D一半要求为B（组合3）。实验中的输入视频流帧率为25 FPS，分辨率为1080P/720P，编码方式为H.264 NV12，其中大部分的帧中只包含1个车辆对象，最多包含两个车辆对象，且输入视频流通过FFmpeg+EasyDarwin对MP4视频文件推流产生。为方便对比，在VideoEdge中，请求的处理顺序为：先处理输出结果为视频流的请求，然后按照输入视频流分辨率由高到低和准确度要求由高到低的顺序依次处理剩余请求。量化A级别准确度为4，C级别准确度为2。在实时性的度量方面，量化边缘节点间和云节点间的数据传输时延皆为1，边缘节点与云节点间的数据传输时延为300。对于分辨率为的视频流，假设H.264压缩比为20：1，则可量化其带宽占用为

表3 视频流实时智能分析请求

对于智能信息结构化数据，量化其带宽占用为

3.2 实验结果与分析

如图4，VideoEdge以整体准确度为最优化目标，在整体准确度方面VideoEmbedded几乎与之持平。因为VideoEmbedded更倾向于使用轻量级智能模型，所以对于组合2这样的请求，会优先选用轻量级智能模型，从而导致整体准确度稍有下降。同时，这也能够节省一定的系统资源（见图5中的组合2对比）。如图5，VideoEmbedded的系统整体资源占用始终少于或等于VideoEdge。VideoEmbedded和VideoEdge都会优先将输出结果为智能信息结构化数据的智能分析任务调度到边缘区域执行，在请求数较小的情况下，因为VideoEdge Merge是二阶段的，使得有部分任务由于边缘区域没有足够的资源而被分配至云上执行，而Video-Embedded最开始就是从智能组件复用出发的，这使得这些任务可以全部分配至边缘区域中执行，提高了组件复用率，从而占用更少的系统资源。这也直接导致了相比于VideoEdge，VideoEmbedded可以占用更少的边-云间带宽。如图6，VideoEmbedded能够更充分地利用边缘资源，相比于VideoEdge Merge，能够节省12.99%～38.96%的边-云间带宽，且能够稳定地保证应用整体的高实时性，如图7，逻辑进程始终与智能服务处于同一区域，在4/9的情况下，VideoEmbedded的整体实时性更高。随着请求数的不断增加，即使是使用VideoEmbedded边缘区域也因资源有限而无法容纳更多的任务，使得大部分的任务被分配至云上执行，Video-Embedded和VideoEdge Merge的组件复用率逐渐持平，所占用的系统资源也逐渐持平。

图4 实验结果整体准确度对比

图6 实验结果边-云间带宽占用对比

图7 实验结果应用整体实时性对比

4 结语

本文设计了一项端-边-云计算架构之上的兼顾边-云间数据传输时延和边缘节点硬件资源受限特性的视频流分析任务调度策略VideoEmbedded，根据视频流分析请求的特性来进行任务调度，提高了视频流分析的实时性，降低整体系统资源占用。实验证明，相比于VideoEdge，本文提出的VideoEmbedded能更充分地利用边缘资源，在实时性、系统资源和边-云间带宽占用等方面表现更优。同时，本文设计了一套基于Docker容器技术、K8s容器编排技术的端-边-云视频流分析系统，其具有良好弹性伸缩能力和自动化运营能力。