基于EPOLL机制的实时监控传输系统的设计与实现

张绪红，黄 睿

(1. 广东技术师范大学 自动化学院， 广州 510665； 2. 广东第二师范学院 计算机科学系， 广州 510303)

0 引 言

随着科技的发展，人工智能与物联网技术已广泛应用于各个领域，人脸识别、车联网等技术趋于成熟，对视频采集、监控的技术要求越来越高。然而，这些实时应用场景往往由于网络传输的时延而影响云端的计算效率。在此背景下，边缘计算的架构得到了越来越多的关注。边缘计算将计算部署在离终端更近的边缘平台，可以避免集中式云计算中心的网络延迟，提供更具实时性和短周期的计算，更好地满足物联网推动下爆发式的计算需求。本文特别针对大数据量的视频采集、视频监控等实时传输场景，研究高效稳定的嵌入式视频传输方案，实现边缘平台的实时视频数据采集操作。

具体而言，影响边缘平台服务器性能的有处理器、硬盘、内存等硬件因素和服务器架构、网络传输协议等软件因素，而服务器架构是主要的软件影响因素。目前基于Linux内核的模型架构一般有传统I/O模型、SELECT模型、POLL模型和EPOLL模型等[1-4]。传统I/O模型包括阻塞I/O和非阻塞I/O，该模型主要用于短连接和即时信息交互等场景。SELECT模型通过一组有限的文件描述符集合和时间值(Timeval)结构来等待并处理I/O事件，并通过遍历监听池来判断事件源，从而完成事件下行操作[5]。POLL模型是在SELECT模型的基础上，对最大监听数和响应方法进行优化，事件上报后不需要进行遍历操作，直接调用事件注册时绑定的处理函数。

本文设计的传输方案首先在嵌入式终端实现摄像头驱动，进行图像采集，然后进行Socket网络服务器搭建，建立图像传输协议，最后对客户端接收到的图像进行实时显示。在数据量小且连接数单一的情况下，上述各模型均能满足需求。随着连接数和图像数据量的增大，服务器系统调度频繁，前两类模型效率较低，将难以满足工程所需。POLL模型处理相对较好，但资源占用带宽高，所以，需要在POLL模型的基础上进行模型优化，以提高系统性能的效果。

1 EPOLL模型

1.1 EPOLL介绍

基于Linux内核的嵌入式产品中，通常会挂载多种外部设备，为确保各个设备的稳定运行，系统需要实时监测各设备的运行状态。传统的阻塞I/O主要采用忙等的方式来获取事件的状态，实现简单但占用系统资源多。而SELECT在事件发生后不能直接判断上报的事件是由哪一个文件产生，需要耗费时间和资源对监听池的所有事件进行遍历来判断事件源。EPOLL模型是在POLL模型基础上进行优化，使监控的文件数量为无穷大，且事件发生后就直接调用该事件绑定的回调函数，从而直接进行下行操作。

为了使设计的视频监控系统更高效地运行，本文基于EPOLL架构，分别建立图像采集、图像传输、视频通讯、播放显示等4个子系统，各个子系统之间相互通信，从而达到实时视频监控的效果，并最终基于Intel、ARM平台下完成图像传输。

1.2 EPOLL基本模型

EPOLL机制是基于传统的SELECT、POLL机制产生的，并在Linux2.6内核以后的版本进行了实现。EPOLL支持对管道、先进先出(FIFO)、套接字、可移植操作系统(POSIX)消息队列、终端、设备等监听处理，其主要优点如下：

(1) 进程进行文件监控的数量没有上限。该机制所支持的最大文件描述符上限，主要依赖于运行设备的内存容量，呈正相关，远大于SELECT的1 024条。

(2) 事件响应快速。当事件发生时，不需要再重新遍历监听池里所有注册的事件，而是直接找到上报事件的回调函数，及时进行事件处理。

(3) 快速访问内核空间。通过内存映射(mmap)机制将内核空间映射到用户空间，应用程序直接对内存进行读写操作，可以及时对设备进行数据交互。

传统EPOLL模型使用比较简单，主要分为3个步骤：创建EPOLL监听池、添加要监听的事件、等待事件上报。EPOLL模型如图1所示，实现步骤如下：

步骤1创建EPOLL监听池。epoll_create()函数用于创建EPOLL监听池，该函数创建的监听数量不限，返回值是一个文件描述符。

步骤2添加要监听的事件。epoll_ctl()函数可以对监听文件属性进行设置。部分参数说明如下[6]：

EPOLL_CTL_ADD，注册新事件到监听池中。

EPOLL_CTL_MOD，修改已注册的监听事件。

EPOLL_CTL_DEL，从监听池中删除事件。

EPOLLLT，水平触发模式。当监听池事件处于就绪态时，EPOLL将一直上报该事件。

EPOLLET，边缘触发模式，包括上升沿触发和下降沿触发。

步骤3等待事件上报。epoll_wait()函数用于等待事件上报，当发生事件上报时，EPOLL机制会调用注册事件时的处理函数。

图1 EPOLL模型

1.3 EPOLL模型优化

传统EPOLL模型是通过epoll_ctl()函数对事件进行注册，该函数主要依赖struct epoll_event结构体进行事件描述，该结构体内容如图2所示。

图2 Epoll_event结构体关系图

从图可以得知，epoll_event结构体成员data是一个union联合体。虽然使用*ptr可以指向用户定义的处理函数(*为指针结构)，fd可以保存事件的文件描述符，但是union联合体只能选择一种成员方式进行使用，因此，需要对EPOLL模型进行优化，如图3所示。

首先，实现自定义结构体struct event_ext，包含事件描述符fd；事件状态epolled；事件类型events；事件上报时对应的处理函数*handler；附加参数*arg。

其次，通过union联合体成员*pt指向自定义结构体struct event_ext，完成EPOLL监听池事件注册。当发生事件上报时，可以根据*pt指向的自定义结构体，找到对应的处理函数，从而实现事件下行操作。

图3 Epoll_event结构体优化

2 系统设计和实现

2.1 程序架构

本文基于EPOLL机制分别建立图像采集、图像传输、视频通信、显示等子系统，该系统功能结构图如图4所示。

图4 系统功能结构图

图像采集子系统主要功能是对图像进行采集，包括初始化摄像头、设置图像采集格式、图像的保存等功能。

图像传输子系统用于建立图像传输协议，使服务端和客户端按照既定的协议完成通信，确保图像数据传输完整。

视频通信子系统用于建立客户端与服务器的网络连接，对接收到的数据进行解析，提供图像数据接口给显示子系统。

显示子系统用于实时显示摄像头采集到的图像，同时也显示图像帧格式、图像尺寸、传输速率等基本内容。

2.2 图像采集子系统

视频监控是嵌入式Linux的一个重要应用场合，合理高效的进行图像采集是广大学者研究的重点[7]。目前基于Linux操作系统下，比较流行的摄像头软件架构是V4L2(video for linux 2)架构，该架构通过一系列的回调函数来使应用程序具有发现设备和操作设备的功能，譬如设置摄像头的频率、视频压缩格式等图像基本参数，其软件架构如图5所示。

图5 V4L2软件架构

图5详细界绍了基于V4L2摄像头软件架构，该架构下图像采集步骤如下：

步骤1初始化摄像头。

步骤2获取驱动信息；通过文件接口的调用，使用VIDIOC_QUERYCAP参数可以查看驱动信息。

步骤3设置图像格式；v4l2_format结构体用于设置摄像头的视频捕捉格式和帧格式等信息。

步骤4申请图像缓冲区；v4l2_requestbuffers结构体用于设置缓冲区数据格式和映射关系。

步骤5将内核空间中的图像缓冲区映射到用户空间；结构体v4l2_buffer设置缓冲区的存储类型，使用mmap建立映射关系。

步骤6图像缓冲入队列；映射好的缓冲区通过使用VIDIOC_QBUF参数，进行缓冲入队列操作。

步骤7注册事件到EPOLL。当采集事件发生后，EPOLL会自动调用事件处理函数，从而完成采集事件的下行操作。

2.3 传输子系统

通过图像采集子系统完成摄像头的采集，下一步就需要将图像进行传输。传输层采用面向连接的TCP协议，注册事件到EPOLL后，收到客户端的网络包请求时会作出相应的事件处理。Socket编程主要进行以下几步： 创建套接字； 初始化要绑定的地址，并使用bind进行绑定； 进行端口监听； 等待连接； 数据交互。

建立网络连接后，需要定义服务端与客户端的通信协议，传输的基本内容包含帧的格式和图像内容。一条完整的通讯协议分别由协议头、协议长度和数据内容3部分组成，如图6所示。

图6 网络传输协议

图6表明，协议头由3个字节组成，分别包含请求ID(8bit)、数据类型type(3bit)、数据格式subs(5bit)和数据长度len(8bit)。协议帧长度由4个字节组成。剩下为图像数据。协议数据头定义见表1。

表1 协议头定义

当监听到客户端的请求帧时，首先，事件处理函数对该请求帧协议头进行解析，从而获取请求帧ID，然后将需要返回的内容按照传输协议进行封装，最后发送给客户端完成了视频的传输。

2.4 通信子系统

通过上述步骤完成了采集子系统和传输子系统，为了让客户端与服务器进行稳定的数据传输，需要设计面向连接的通信子系统，该系统工作流程设计如下。

(1) 初始化网络协议，采用面向连接的TCP协议。

(2) 创建工作线程，主要用于图像请求及数据解析。

(3) 图像获取，根据传输子系统的通信协议，对服务器返回一帧的数据进行解析，从而获取一帧的图像数据。

(4) 创建显示接口，该接口用于将解析的一帧图像数据，传递给图像显示子系统。

该系统通过线程来发送构造的图像请求，并对接收到的数据帧进行解析，将解析出来的图像提交给图像显示子系统。

2.5 显示子系统

嵌入式Linux支持多种图形界面(GUI)，常用的有Qt[8]、GTK+[9]、miniGUI等[10-11]。Qt是面向对象的跨平台C++图形开发框架，模块化程度高。GTK+是嵌入式Linux下主流的图形界面开发工具，支持LGPL开发协议，主要采用C语言进行编程。miniGUI是面向嵌入式系统图形界面开发工具，1.6.10版本后重定义为商用嵌入式GUI系统[12-13]。

显示子系统主要完成的是图像显示功能，相比上述3种程序框架，GTK+开发相对简单，可以显著节省开发时间，让编程人员可以将更多精力集中在项目的核心部分上，故显示子系统采用GTK+框架进行开发。显示子系统主要包括以下两个窗体：

(1) 网络连接窗体。通过获取用户输入的IP地址和端口号来进行TCP连接，如连接成功，则跳转到图像显示窗体界面[14]。窗体设计如下：

① 创建垂直布局容器，用于定义窗体的整体布局方式，存放后续所有的控件。

② 创建水平布局容器，并绘制登录图片。

③ 创建水平布局容器，分别绘制服务器IP地址和端口标签，以及对应的编辑框。

④ 创建水平布局容器，创建“确定”“取消”按钮，并分别联按钮点击事件connect_handler和gtk_main_quit。该窗体最终效果如图7所示。

图7 网络连接窗体

(2) 图像显示窗体。跳转到图像显示窗体后，通过调用通信子系统来获取图像接口，并将图像、帧格式、尺寸、速率等信息进行实时显示。窗体设计流程如下：

① 判断是否连接上服务器，如连接上则获取服务器IP地址和端口地址，否则报错。

② 创建图像显示区域和功能显示区域，功能显示区主要包含图像帧格式、图像尺寸、传输速率等信息[15]。

③ 将解析的图像在图像显示区域进行实时显示，并在功能区显示相应的信息。

3 实验分析

基于EPOLL机制进行视频监控系统的设计和实现，实验采用2台Intel-i5和2台分别ARM9、ARM11架构的设备。首先分析阻塞I/O、SELECT、POLL、EPOLL等架构处理能力，其次分别在Intel、ARM平台下实现视频监控系统，最后对基于EPOLL机制视频监控系统进行分析。

多线程、多进程虽然可以改进模型的处理效率，但是并没有对网络编程模型进行实质性改善。故服务端实验环境采用单线程处理模式，分别在阻塞I/O、SELECT、POLL、EPOLL等架构下进行单Byte传输，客户端成功完成读写操作的连接请求数如图8所示。

图8 网络连接窗体

4种模型函数调用所占用时间见表2。

表2 I/O、SELECT、POLL、EPOLL函数占时比 %

由图8可见，模型处理能力由高到低的排序是阻塞I/O、EPOLL、POLL、SELECT。由于实验采用一次性交互的短连接，该场景是捕获一个请求后即刻进行读写操作，传统的阻塞I/O效率最高，EPOLL模型效率要优于POLL模型和SELECT模型。

主函数进行Socket网络编程，结合表2数据，SELECT模型在主函数占用时间更多，是因为每次进行SELCET都需要对监听池里的事件进行遍历，这也导致相比其他模型，SELECT模型连接性能最差。

视频监控系统基于高并发处理服务器，阻塞I/O模型、SELECT只能通过引入多线程提高传输效率，而不能达到高并发的状态。故只考虑POLL和EPOLL模型面对长连接时的性能比较。对服务器连接数分别为3 000和20 000时，POLL和EPOLL模型性能见表3。

表3 POLL、EPOLL函数占时比 %

通过表3 POLL和EPOLL模型对比可看出，当最大连接数为3 000时，POLL模型的传输效率高于EPOLL模型。随着连接数的增加，最大连接数达到20 000时，EPOLL模型主函数所耗时间低于POLL模型，说明传输效率高于POLL模型。EPOLL模型函数调用率基本保存不变，而POLL模型主函数调用率由12.11%上升至64.65%，读写操作分别由36.93%、48.15%降低至3.73%、4.87%，说明EPOLL传输稳定性更强。由于视频监控系统的传输数据大，且面向多用户连接的网络通信，所以EPOLL架构来实现视频监控系统是合理的，相对于其他模型，该模型传输效率更高，稳定性更好。

本文客户端使用Intel-i5处理器，采用通信子系统和显示子系统设计方法进行搭建。服务端分别使用Intel-i5、ARM9、ARM11设备，采用图像采集子系统和传输子系统设计方法进行搭建。通信效果如图9所示。

图9 EPOLL架构视频监控系统

4 结 语

本文针对大数据量的视频采集传输研究高效的实时传输方案。通过对传统EPOLL模型进行优化，实现在Intel、ARM架构下的摄像头数据采集，并通过网络进行图像的显示。

实验表明，采用单线程网络服务器进行单Byte数据交互时，阻塞I/O对单线程短连接传输效率高。采用大数据长连接交互时，EPOLL模型函数调用率基本保持不变，POLL模型主函数调用率上升52.54%，读写操作分别降低33.2%、43.28%。说明EPOLL模型架构传输效率优于POLL模型，该机制制作视频监控系统的传输效率更高，稳定性更好，适用性强。

本文提出的基于EPOLL机制应用通过实验数据得出，EPOLL模型传输效率相比POLL、SELECT和阻塞I/O传输效率都要好，传输质量高，可应用于实时视频采集、视频监控等场景。