基于帧缓冲队列的边缘视频处理加速方法*

程小兰,蒋从锋,欧东阳,任永坚,张纪林,万 健

(1.杭州电子科技大学计算机学院,浙江 杭州 310018;2.复杂系统建模与仿真教育部重点实验室，浙江 杭州 310018;3.浙江科技学院信息与电子工程学院,浙江 杭州 310023)

1 引言

基于云端的视频处理[1,2]降低了用户的建设维护成本，同时集中式计算和存储模式降低了视频数据处理的难度。但是，由于爆炸式增长的边缘视频数据[3]，基于云计算模型的视频处理技术存在网络带宽需求高、实时性差和安全性差等问题。万物互联应用需求的发展催生了边缘式大数据处理模式，即边缘计算模型[4 - 7]。边缘视频处理是将全部或者部分视频处理工作放在边缘节点端，边缘节点包括智能手机、智能手表、智能摄像头和边缘服务器等。边缘视频处理具有显著的优点：数据传输的开销小、延迟小。这些优点体现在生活的诸多应用中，比如对于实时交通路况的监控视频，边缘视频分析可以避免在网络资源紧张的情况下进行大量视频数据传输；智能摄像头捕获的实时视频数据，可以在边缘端进行适当处理再传输至云端，不仅可以减小视频处理时延，还可以提高视频数据的安全性。同时，针对不同的应用[8]，很多原始视频流将由多个视频分析系统进行分析。来自不同视频源的视频流也会被同一个系统处理，来自多个视频源的视频参数具有多样性。不同视频参数对视频处理性能有不同影响，所以视频参数的多样性会加剧视频处理的难度。比如，同一个人脸识别系统中，在系统性能满足的前提下，很难保障所有分辨率和帧率的视频都能在保持较高的帧接收率的同时具有较小的视频处理时间。此外，视频是一种复杂的数据类型，视频传输消耗大量的网络资源，视频处理会消耗大量的系统资源。然而边缘服务器的系统资源有限，给边缘实时视频处理带来很大的困难。综合这些因素，在边缘实时处理视频仍旧面临很多挑战，边缘服务器需要在满足自身性能的前提下最大化视频处理性能。

本文针对视频处理的帧堆积问题提出了在帧接收和帧处理间加入缓冲区即帧缓冲队列的方法，来并行处理缓冲帧，以解决帧接收时延问题，加速视频处理。本文搭建以树莓派作为边缘节点，台式机作为边缘服务器的边缘视频处理平台。边缘服务器可以同时处理来自多个边缘节点的视频数据，即视频参数不是单一的，而是多样化的。边缘服务器的视频处理程序是基于OpenCV[9,10]的人脸检测。视频传输是实时流式传输，包括采集、编码、打包和网络传输等过程，边缘服务器端的视频处理也是实时流式处理，包括解码和视频处理。本文的工作目标是对于边缘节点传输来的任何参数的视频数据，资源有限的边缘服务器在满足自身系统性能的前提下，尽可能提高视频处理的性能指标。具体工作如下所示：

(1)首先，经实验发现高帧率和高分辨率的视频数据容易导致系统丢帧，提出基于帧缓冲队列的流视频处理加速方法解决丢帧问题。在这部分，首先进行数据分析探究系统丢帧的原因，结果发现视频数据量的增加导致视频处理速度变慢，形成帧接收时延，造成帧堆积，从而导致解码出错和丢帧。随后提出利用帧缓冲队列解决丢帧问题，本文提出的解决方案是在帧接收和帧处理之间加上缓冲队列，即帧缓冲队列FBQ(Frame Buffer Queue)。帧缓冲队列的作用有2点：一是解决帧接收速度和帧处理速度的不匹配问题，将暂时未及时处理的帧缓冲下来，避免帧堆积，从而避免丢帧；二是可以借助帧缓冲队列的分流作用，充分利用系统的多核资源，将一路视频流多路分流处理，从而提高视频的处理速度，满足视频处理的实时性。本文将添加帧缓冲队列的系统标记为“有FBQ系统”，否则为“无FBQ系统”。

(2)其次，分别在有FBQ系统和无FBQ系统中通过性能对比探究视频参数(分辨率、帧率)对视频处理性能和系统性能的影响。视频处理性能指标包括帧接收率、人脸检测率和视频处理时长，系统性能指标包括边缘服务器端系统内存使用率和系统功耗。具体实验发现，人脸检测率与分辨率的大小有关，而与帧率无关；同时，在无FBQ系统中，处理高分辨率视频会加剧系统丢帧；分辨率高于720×405时，高帧率视频数据的处理也会加剧丢帧；但分辨率低于720×405时，帧率对帧接收率没有影响；随着分辨率和帧率的增加，系统的功耗都呈上升趋势；而分辨率和帧率对系统内存使用率和视频处理时间影响不大。另外，相较于无FBQ系统，有FBQ系统不仅不存在丢帧，而且降低了系统功耗；仅有一个视频处理线程时，由于需要处理缓冲帧，随着分辨率和帧率的增加，视频处理时间和内存使用率均会呈现明显的递增趋势。

本文的实验结果表明，如果边缘服务器的CPU资源与任务量匹配，有FBQ系统在保证视频实时处理的前提下，降低了系统丢帧率和功耗。

2 相关工作

为了提高边缘节点实时处理视频流的性能，学者们提出了不同的视频分析方法，如通过使用边缘节点之间的协作来实现实时视频分析。Zhang等人[11]基于Firework[12]的扩展版本实现了AMBER(America’s Missing Broadcast Emergency Response)警报助手(A3)。A3可以通过实时高效地分析城市摄像机的数据来定位和跟踪车辆。A3主要通过多个边缘设备之间的协作来实现实时视频分析，并且通过巧妙地选择候选摄像机来有效地控制用于车辆跟踪的搜索区域，提出了与位置方向有关的扩散策略。Long 等人[13]提出了一种边缘计算框架，可以在资源丰富的移动设备上实现对延迟敏感的多媒体物联网任务的协同处理。该框架的主要挑战是将移动设备组成最佳的视频处理组，并将视频块分配给适当的组。Cao等人[14]给出了一种基于轻量级虚拟化技术的在边缘计算平台上实现协作视频处理的方法。

有一些学者考虑了边缘与云之间的协作工作。EVAPS(Edge Video Analysis for Public Satety)[15]以优化的方式在边缘节点和云之间分配计算工作负载，并消除了不必要的数据传输，从而为边缘设备节省了能源。 为了解决将大量数据从物联网设备传输到使用机器学习模型进行处理的云中心时，连接数据源端和云平台的网络可能成为瓶颈，Ali等人[16]提出为数据处理分配跨越边缘资源和云/雾资源的深度学习管道的方法，数据的基本处理阶段和训练模型在网络边缘进行。此外，还有学者使用机器学习来加速视频的实时处理。为了获得更高的总体应用质量，Mainstream[8]可以自适应地在共享边缘设备上并发进行视频处理的应用之间协调DNN词干共享。

一些学者为不同的应用程序构建了完整的实时视频分析系统。Wang等人[17]引入了一种新型人脸识别系统OpenFace，该系统可以与帧间跟踪相结合，生成用于实时隐私保护的RTFace，作者以城市交通监控为例详细介绍了该系统。Chen等人[18]提出了一种动态视频流处理方案，以满足实时信息处理和决策的要求。Dautov等人[19]将诸如物联网、云计算、边缘计算和大数据之类的各种方法和技术结合到一个通用框架中，能够采用统一的方法在城市范围内实施智能监控，从而为大都市智能监控铺平了道路。

Xu等人[20]引入的VideoChef是一种近似优化视频流水线的系统，并且是首个使用Canary输入[21]的复杂流应用程序的系统。VideoChef根据Canary输入的概念在系统运行时找到近似滤波器的最佳配置，该概念使用较小的输入来调整计算的准确性并将近似配置传输到所有输入。为了实现实时不间断的移动人体跟踪，Xu等人[22]提出了基于定向直方图(HOG)和线性支持向量机(SVM)的移动人体检测方法，并提出了一种有效的基于核相关滤波器的目标跟踪算法。

为提高边缘环境中的视频处理性能，上述工作针对特殊的边缘节点和应用场景提出了相应的优化方案，而本文则是考虑同一个边缘服务器会处理来自不同边缘节点的视频流，以边缘节点视频参数多样性作为出发点，探究不同视频参数的组合对视频处理性能和系统性能的影响，从而提出性能优化方案，提升视频处理的综合性能。

3 基于帧缓冲队列的流视频处理加速方法

3.1 帧率和分辨率对流视频处理性能的影响

本节探究视频参数的多样性对视频处理综合性能的影响，涉及的视频参数有分辨率和帧率。本文发现边缘服务器端处理高分辨率和高帧率视频数据时，会产生丢帧等性能问题；而且，对于系统丢帧的问题，经分析发现帧的接收时延是导致丢帧的根本原因。随后提出在边缘服务器端通过添加帧缓冲队列来解决丢帧问题。

帧接收率FRR(Frame Reception Rate)是实时视频处理的重要性能指标，当系统处理不同分辨率和帧率的视频数据时，系统的丢帧情况也不相同。首先，网络环境对帧接收率影响很大，本文发现无线网络环境会导致系统丢帧。此外，当系统处理高分辨率和高帧率的视频时，系统也会丢帧。图1表示在有线网和无线网环境中，帧率是25 fps时系统帧接收率随着视频分辨率增加的变化情况。

Figure 1 Frame reception rate under different resolution configurations (frame rate=25 fps)图1 不同分辨率配置下的帧接收率(帧率为25 fps)

经分析可知，2种网络环境中，随着视频分辨率的增大，系统均出现丢帧，但是无线网环境中的帧接收率总体低于有线网环境中的帧接收率。此外，当视频分辨率较低时，有线网络环境系统不会丢帧，但是无线络网环境却会丢帧。由实验结果可知，除了网络环境因素，还有其它因素导致系统丢帧，因为在有线网络环境中随着视频分辨率的增加，系统也出现了丢帧。

有线网络和无线网络的区别在于数据的传输方式，在没有信号干扰的前提下，有线视频传输和无线视频传输并没有实质区别。在实际的应用场景中，有线网络抗干扰能力强，但是会受到器材限制，比如线路的长短，而无线网络虽然方便快捷，但是抗干扰能力弱，导致传输速度慢。排除网络环境，本文发现丢帧的直接原因是帧的解码问题，帧堆积是造成解码错误的主要原因。而视频数据量的增加导致视频处理速度跟不上视频帧的传输速度，从而导致帧堆积。

本文进行了如下实验和数据分析来探究丢帧原因。

视频处理一般是计算密集型任务，以包含人脸检测任务的视频处理过程为例，视频处理过程可分为如下几个具体阶段[11]：

(1)视频解码：首先将视频数据解码成不同参数的帧，常见的帧参数包括分辨率和帧率，常见的视频编码格式有H.264、MPEG和H.265等。

(2)图像预处理：为了提高图像质量，需要对解码得到的图像进行一系列的处理，包括图像增强、降噪、改变尺寸和镜头校正等图像编辑操作。

(3)图像处理：常见的图像处理操作是图像分割，其结果是将图像分割成多个部分，方便后续操作。

(4)目标检测：将图像中感兴趣的部分检测出来，划分成固定类，常见的目标检测对象包括人脸、汽车和建筑等。

(5)目标识别：将检测到的对象进行语义分类，人脸识别将检测到的人脸与某个具体人关联起来。

(6)目标跟踪：在视频中定位一个或者多个对象的过程。

(7)数据融合：整合来自多个视频的视频处理结果。

在一次实时视频传输的过程中，本文根据视频分析的一般过程将帧生命周期分为5个阶段，如图2所示。5个阶段分配在边缘节点、网络和边缘服务器3个物理空间。t1之前的阶段在边缘节点空间，网络传输阶段在网络空间，t2之后的阶段在边缘服务器空间。在同一个时刻，每个空间的任务都独立运行，并且操作的对象不同。然而，前后任务的执行速度之间存在制约关系，如果执行速度相差很大，会造成视频处理性能问题。例如，等待解码时间会随着视频处理时间的增加而增加。因为空间的独立性，在边缘服务器空间，虽然较长的视频处理时间导致大量的帧处在等待解码阶段，但是网络空间仍然会源源不断地向边缘服务器传输帧，导致更多帧处在等待解码阶段，后继帧便会有更长的等待解码时间。

Figure 2 Various stages in the frame life cycle图2 帧生命周期中的各个阶段

由图3可知，帧的平均处理时间随着分辨率的提高而增长。将VideoCapture类的read()函数(如果有帧传入，read()对帧解码然后返回，如果在其设置的超时节点前没有帧传入，就返回空)返回一帧的时间称作帧接收时间。如果帧接收时间越长，帧的等待解码时间越短，最短为0，如果帧接收时间越短，帧的等待解码时间越长。

Figure 3 Average frame processing time under different resolution configurations (frame rate=25 fps)图3 不同分辨率配置下的帧平均处理时间(帧率为25 fps)

图4a和图4b分别表示分辨率为320×180(未出现丢帧)和1024×576(未出现丢帧)时，一次实验中帧接收时间的分布情况。经分析可知，帧接收时间可以被分成2类，小于或等于20 ms的标记为小帧接收时间，大于20 ms的标记为大帧接收时间；就整体趋势而言，1024×576的大帧接收时间小于320×180的大帧接收时间，而小帧接收时间大于320×180的小帧接收时间；数据显示1024×576的小帧接收时间分布在2 ms和3 ms，320×180的小帧接收时间分布在0 ms和1 ms。本文又取连续100帧进行分析，图5表示100帧的帧接收时间的折线图。经分析可知，2种分辨率都是连续出现一个小帧接收时间，再出现一个大帧接收时间，依次循环下去。

Figure 4 Distribution of frame reception time (instantaneous value) of all frames in an experiment图4 一次实验中所有帧的帧接收时间(瞬时值)分布情况

H.264协议定义了3种帧，完整编码的帧为I帧，参考前面I帧编码生成的只包含差异部分的帧叫P帧，还有一种参考前后帧编码的帧叫B帧。H.264采用的核心算法是帧内压缩和帧间压缩，帧内压缩是生成I帧的算法，帧间压缩是生成B帧和P帧的算法。在H.264协议中，图像以序列为单位进行组织，一个序列是一段图像编码后的数据流，以I帧开始，到下一个I帧结束，并且一个序列中的帧数不是固定的，且只有一个I帧。

结合H.264的编解码原理，对图4和图5做出以下解释。图5中一个循环包含的帧是一个帧序列，大帧接收时间对应的帧是I帧，小帧接收时间对应的帧是B帧和P帧。所以，小帧接收时间仅仅包含解码时间，而大帧接收时间则包含边缘服务器等待帧到达的时间和帧的解码时间，上述情况下，read()函数需要等待帧到达，说明帧到达后能够立即被解码,它的等待解码时间几乎为0，只有一个序列中的B帧和P帧有少许等待解码时间，所以上述情况不存在丢帧。由于空间的独立性，在同一时间段，3个空间的任务都在同时执行，但是处理的对象不同。前面帧被处理的时间越长，覆盖后继帧在前面2个空间的时间也就越长，read()函数等待帧到达的时间也就越短，即随着分辨率的提高，大帧接收时间在缩短。图6表示分辨率为1280×720(出现丢帧)和1920×1080(出现丢帧)时，一次实验中帧接收时间的分布情况(因为存在丢帧，所以帧数小于500)。

Figure 5 Distribution of frame reception time (instantaneous value) for 100 consecutive frames图5 连续100帧的帧接收时间(瞬时值)的分布情况

Figure 6 Distribution of frame reception time (instantaneous value) of all frames in one experiment图6 所有帧的帧接收时间(瞬时值)分布情况

经分析可知，存在丢帧时，几乎没有大帧接收时间，小帧接收时间比320×180和1024×576的小帧接收时间长。即如果帧的处理时间足够长，read()函数不需要等待帧到达，即使到达的帧也不能被实时处理。到达的帧长时间等待解码导致大量帧堆积在边缘服务器端，所以会出现解码错误和丢帧。

经上述分析可知，帧的解码时间随着分辨率的提高而增长，帧的等待处理时间也随着分辨率的提高而增长，较长的等待解码时间会导致系统丢帧。

3.2 基于帧缓冲队列的视频处理加速

由3.1节分析可知，系统出现丢帧的原因如图7所示，即边缘服务器端处理器性能不足和视频数据量大导致当前帧(图像)处理时间较长，从而导致下一帧的接收时间短(意味着帧的等待解码时间长)，造成帧堆积，因此解码出错、丢帧。下文是本文为解决丢帧提出的方案。

Figure 7 Reasons for frame loss in the system图7 系统出现丢帧的原因

处理器的性能不是本文优化的重点。此外，由于视频参数存在多样性，在边缘实时视频处理系统中，视频数据量大也是难以避免的。因此，解决丢帧的核心问题是缩短帧的等待解码时间。考虑到计算机系统软件结构采用的是一种层的结构，计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。为了解决帧的等待解码时间过长问题，本文在帧接收和帧处理之间加上缓冲，即将未及时处理的帧缓冲下来，避免帧堆积。缓冲的介质是内存，代码层面的实现是队列，记作“帧缓冲队列”。考虑到多线程访问问题，本文系统中的队列是C++语言封装的线程安全队列。

由计算机体系结构基础知识可知，因为CPU频率发展受阻，SMP和多核的时代到来了。单个CPU频率有限，因此应用程序的设计应该充分挖掘计算机硬件能力，提高计算机执行效率。特别是对于实时视频处理这样对系统性能要求极高的应用程序，需要充分挖掘计算机系统资源，从而最优化视频处理性能。由上述得到启发，可以通过多核处理由一个边缘节点传入的视频数据，从而缩短视频处理时间。需要解决的是一个一对多的问题，即一路视频流多路处理。直接在边缘服务器端的帧接收处进行视频分流达到多路处理的目的是可行的，但是考虑到多路处理也会存在CPU成为性能瓶颈的问题，本文利用FBQ进行分流。FBQ从2个层面解决丢帧问题，如图8所示。一方面缓冲帧，缩短帧的等待解码时间，从而减少帧堆积；另一方面充分利用多核资源，实现一路视频流多路处理，从而加快视频处理速度。实验结果表明，FBQ不仅可以解决系统丢帧问题，还可以降低其它系统资源的消耗，比如电能。

Figure 8 FBQ solves the problem of frame loss图8 FBQ解决丢帧问题

算法1表示FBQ分流后的视频处理流程，主要包含2个函数。函数pushFrame被生产者线程执行(只有一个生产者线程)，执行的任务是打开视频流地址，解码获取视频帧，进行图像预处理，将处理后的帧放入帧缓冲队列。本文中的图像预处理(图像缩放)，将缩小后的帧放入帧缓冲队列，可以降低系统内存消耗。函数popFrame被消费者线程执行(有多个消费者线程)，执行的任务是从帧缓冲队列中取出帧，进行后续图像处理(本文是人脸检测)。

算法1FBQ分流后的视频处理算法

Input:videoAddress,queue。/*视频流地址，帧缓冲队列*/

Output:NULL。

1:FunctionpushFrame(videoAddress,queue)

2:capture←VideoCapture(videoAddress) /*打开视频流地址*/

3:while(capture>>imagOriginal&& !queue.full())do

4:imag←imgPreprocessing(imagOriginal) /*包括图像缩放*/

5:queue.push(imag);/*预处理后的帧放入帧缓冲队列，降低内存消耗*/

6:endwhile

7:endFunction

8:FunctionpopFrame(queue)

9:while(!queue.empty())do

10:imag←queue.top();

11:queue.pop();

12:imageProcessing(imag);/*图像处理*/

13:endwhile

14:endFunction

图9是有FBQ系统的一路视频流多路处理的模型图，FBQ起到缓冲和分流的作用。缓冲解决帧的接收时延问题，避免帧堆积；分流可以使一路视频多路处理，加速视频处理速度。整个程序模型是经典的生产者消费者模型，生产者线程的任务是将收到的帧解码存入FBQ，消费者线程的任务是从FBQ中取出帧，然后进行处理。实验结果表明，仅需要一个生产者线程就可以解决帧的实时接收问题，为了解决帧的实时处理问题，消费者线程数需要根据视频流参数而定。

Figure 9 Program running model diagram with FBQ system图9 有FBQ系统的程序运行模型图

4 帧缓冲队列对不同视频源的影响

4.1 实验目的和实验配置

该组实验是为了探究视频分辨率和帧率对视频处理性能和边缘服务器性能的影响，在有FBQ系统(With FBQ)和无FBQ系统(No FBQ)中探究不同参数的视频数据对视频处理的性能影响。视频处理性能指标有帧接收率FRR、人脸检测率FDR(Face Detection Rate)和总视频处理时间TPT(Total Processing Time)。帧接收率和人脸检测率的计算方式分别如式(1)和式(2)所示：

FRR=边缘节点发送的视频帧数/

边缘服务器接收的视频帧数

(1)

FDR=检测出人脸的视频帧数/

边缘服务器接收的视频帧数

(2)

总视频处理时间指边缘节点与边缘服务器建立连接到边缘服务器处理完最后一帧之间的时间。服务器性能指标有内存使用率(Memused)和系统功耗(Power)。

本文搭建实时视频处理的边缘计算平台，平台包括边缘节点(树莓派)和边缘服务器(台式机)，边缘服务器的应用程序是基于OpenCV的人脸检测。实时视频流的传输机制为：Raspivid视频捕获工具把从摄像机传出的视频流传输到VLC(Video LAN Client)转码成H.264网络视频流；再以TS(Transport Stream，一种码流格式)的形式把帧封装后输出到指定端口；台式机通过访问视频地址接收实时视频流。

视频流传输示意图如图10所示，整个过程包括边缘节点端的视频流编码、网络传输和边缘服务器端的解码和处理。

Figure 10 Schematic diagram of video stream transmission图10 视频流传输示意图

各个节点之间的实物连接图如图11所示。边缘服务器可以同时为多路边缘节点服务，边缘服务器架构是基于Linux环境的高并发服务器模型，应用程序是基于OpenCV的人脸检测。边缘节点主动与边缘服务器建立连接，连接成功后，边缘节点向边缘服务器发送视频流地址；边缘服务器通过流媒体地址接收视频数据，并进行实时处理，直到边缘节点终止发送。

Figure 11 Connection topology diagram between nodes图11 节点之间的连接拓扑图

实验硬件配置如表1所示。软件配置如下：OpenCV的版本是3.1.0；图像预处理阶段将所有的帧缩小为原来的1/2；目标区域像素值的下限为30×30，没有设置上限；人脸检测模型是haarcascade_frontalface_default.xml。实验环境：仅考虑一个边缘节点与边缘服务器相连；网络环境采用有线网络；目标物距离摄像头正前方1 m；实验室光线不变。

4.2 分辨率

该组实验以分辨率作为实验变量，探究视频分辨率对边缘实时视频处理的影响。视频时长设置为20 s，帧率为25 fps(即一次实验传输的帧数是500)。本文使用11种分辨率(1920×1080，1600×900，1366×768，1280×720，1024×576，960×540，854×480，720×405，640×360，480×270，320×180)进行实验，探究5个性能指标随着分辨率提高的变化情况。为了对比性能，功耗实验系统使用多个消费者线程，其它性能指标系统使用单个消费者线程。图12
表示不同分辨率配置下，帧接收率、视频处理时间、边缘服务器的内存使用率和功耗的分布情况。

Table 1 Hardware configuration

由实验结果可知，低分辨率会导致人脸识别率降低，其原因是低分辨率图像中出现的人脸像素点数不在实验设置的目标检测区域像素大小范围内。对于其它量变比较明显的性能指标，后文将使用可视化图形表示，并进行性能分析。

由图12a可知，随着分辨率的提高，无FBQ系统的帧接收率呈现明显递减趋势，而有FBQ系统的帧接收率则保持不变，即不存在丢帧。由图12b可知，随着分辨率的提高，无FBQ系统的总视频处理时间呈现缓慢递增趋势，最大值相较于最小值仅增加了8.73%；而有FBQ系统的总视频处理时间呈现迅速递增趋势，最大值相较于最小值增加了96.91%。

由图12c可知，随着分辨率的提高，无FBQ系统的内存使用率呈现缓慢递增趋势，最大值相较于最小值仅增加了6.5%；而有FBQ系统的内存使用率呈现迅速递增趋势，最大值相较于最小值增加了130.68%。由图12d可知，随着分辨率的提高，2种系统的边缘服务器端功耗都是呈递增趋势，但是对于每一种分辨率的视频，有FBQ系统的边缘服务器端功耗都要低于无FBQ系统的。

Figure 12 Performance indicators under different resolution configurations图12 不同分辨率配置下的性能指标

图13表示了对于有FBQ系统，当使用不同的线程进行视频处理时，边缘服务器端系统内存使用率的变化趋势。分析可知，多线程可以缩短视频的处理时间，并且降低了系统的最大内存使用率。

Figure 13 Memory usage under different thread count configurations图13 不同线程数分配下的内存使用率

无FBQ系统由于处理器处理能力弱导致帧堆积，从而导致解码出错丢帧。帧缓冲队列的加入不仅可以缓冲未及时处理的帧，还可以利用多核处理器并行处理缓冲帧，从而加速视频处理。由上述实验结果可知，帧缓冲队列并没有从本质解决系统丢帧(处理器性能不足导致丢帧)。在有FBQ系统中，如果处理器能力不够，由于大量缓冲帧，系统会因为内存成为瓶颈导致丢帧，并且由于处理缓冲帧，也很难保证视频处理的实时性。但是，如果系统的CPU资源与处理任务量匹配，当帧率是25 fps时，随着分辨率的增加，有FBQ系统在保障最佳的帧接收率和低功耗的同时，还可以保障视频的实时处理。

4.3 帧率

该部分实验以帧率作为实验变量，探究视频帧率对边缘实时视频处理性能的影响。一共包含2组实验，一组将分辨率设置为640×360(低分辨率代表)，另一组将分辨率设置为1280×720(高分辨率代表)。本文使用12种帧率(10 fps，15 fps，20 fps，25 fps，30 fps，35 fps，40 fps，45 fps，50 fps，55 fps，60 fps，65 fps)进行实验，探究5个性能指标随着帧率提高的变化情况。视频时长设置为20 s，为了进行对比，对于功耗指标，实验中视频处理的方式采用多个消费者线程，而其它的性能指标则采用单个消费者线程。分辨率设置为640×360时，有FBQ系统和无FBQ系统中，人脸检测率不受帧率的影响。

由图14可知，2种系统的帧接收率的变化趋势一致，均是当帧率低于25 fps和高于55 fps时出现丢帧。这种丢帧是由于边缘节点的编码出错而导致的，与边缘服务器的性能无关。为了进一步探索丢帧原因，统计了帧率是65 fps时一次实验中帧接收时间的分布情况，如图15所示。经分析可知，当分辨率是640×360，帧率是65 fps时，一次实验中所有帧的帧接收时间包含小帧接收时间，也包含大帧接收时间，所以不存在由于帧的接收时延而导致丢帧的情况。

Figure 14 Frame reception rate under different frame rate configurations (resolution=640 × 360)图14 不同帧率配置下的帧接收率(分辨率为640×360)

Figure 15 Distribution of the frame reception time (instantaneous value) of all frames in one experiment (resolution=640 × 360,frame rate=65 fps)图15 一次实验中所有帧的帧接收时间(瞬时值)分布情况(分辨率为640×360，帧率为65 fps)

图16中的图16a～图16c分别表示分辨率是640×360时，视频处理时间和边缘服务器端内存使用率和功耗3个性能指标随着帧率提高的变化情况。

Figure 16 Performance indicators under different frame rate configurations (resolution=640 × 360)图16 不同帧率配置下的性能指标(分辨率为640×360)

由图16可知，2种系统中视频处理时间和内存使用率变化趋势基本一致，均不受帧率影响；边缘服务器端功耗均随着帧率的提高而增加，但是对于所有帧率而言，有FBQ系统的边缘服务器端功耗都要低于无FBQ系统的。由上一组实验得知，小于25 fps和大于55 fps的帧率会导致边缘节点丢帧，所以分辨率是1280×720时，本组实验只取中间7种帧率。同样，分辨率是1280×720时，随着帧率的提高，人脸检测率没有变化，保持较好的状态。图17表示分辨率为1280×720时，帧接收率、视频处理时间、内存使用率和边缘服务器端系统功耗4个性能指标随着帧率提高的变化情况。

Figure 17 Performance indicators under different frame rate configurations (resolution=1280 × 720)图17 不同帧率配置下的性能指标(分辨率为1280×720)

由图17a可知，无FBQ系统的帧接收率呈下降趋势，而有FBQ系统的帧接收率一直是100%。由图17b可知，无FBQ系统的视频处理时间随分辨率的提高呈小范围的波动，而有FBQ系统的视频处理时间呈明显递增趋势。由图17c可知，无FBQ系统的内存使用率也随着分辨率的提高呈小范围波动，而有FBQ系统的内存使用率呈明显递增趋势。由图17d可知，无FBQ系统的边缘服务器端系统功耗呈先上升后下降的趋势，这种趋势是因为随着帧率的提高系统出现丢帧，导致数据量减小；而有FBQ系统的边缘服务器端系统功耗一直呈上升趋势；从低帧率部分的图像趋势可知，有FBQ系统的边缘服务器端系统功耗依旧低于无FBQ系统的。

综合本节上述分析可知，帧率对人脸检测率没有影响；如果分辨率较低，帧率对系统性能和视频处理性能几乎没有影响，如果分辨率较高，高帧率会加剧系统负担，无FBQ系统会出现丢帧，而有FBQ系统也需要消耗更多的系统资源来保证帧接收率和视频的实时处理。

从实验结果可以得出以下结论：视频参数的多样性给边缘视频处理带来了很多难题，本文实验中不同视频分辨率和帧率的视频处理效果并不相同。本文发现，由于边缘节点处理能力较弱，高分辨率和高帧率的视频数据容易增加系统负担，将导致视频处理性能较差。可以从以下方面尝试解决该问题：如果实时视频监控场景需要高分辨率，边缘节点端可以在保证监控信息不丢失的前提下，尽可能地降低视频帧率，这样不仅可以节约网络带宽，还可以减少边缘服务器的负担，提高视频处理的性能；对于低分辨率就能满足的监控场景，可以提高视频帧率来提高监控质量，避免信息遗漏，以捕获到更多实时信息，这样既不会给边缘服务器带来太大的系统性能损失，也不会降低视频处理性能。

5 结束语

本文通过实验发现高分辨率和高帧率视频会导致系统丢帧，其原因是数据量的增加加剧了系统处理器负担，导致帧的接收时延增加，从而产生丢帧。因此，本文提出利用帧缓冲队列(FBQ)来解决上述丢帧问题，并以分辨率和帧率为实验变量，分析有FBQ系统和无FBQ系统的5个性能指标的差异。通过实验发现，人脸检测率与分辨率的大小有关，而与帧率无关。无FBQ系统中，高分辨率加剧系统丢帧；分辨率大于720×405时，高帧率也会加剧丢帧，但分辨率小于720×405时，帧率对帧接收率没有影响；随着分辨率和帧率的提高，系统的功耗都呈上升趋势；而分辨率和帧率对系统内存使用率和视频处理时间影响不大。相较于无FBQ系统，有FBQ系统中，不仅不存在丢帧，而且还减少了系统功耗；仅有一个视频处理线程时，由于需要处理FBQ中的缓冲帧，随着分辨率和帧率的提高，视频处理时间和内存使用率都会呈现明显递增趋势。