轻量级摄像头与监控系统的设计实现*
2022-01-18胡小春黄陆路
胡小春,黄陆路,陈 燕,3**
(1.广西财经学院信息与统计学院,广西南宁 530007;2.广西大学计算机与电子信息学院,广西南宁 530004; 3.广西多媒体通信与网络技术重点实验室(广西大学),广西南宁 530004)
0 引言
近年来随着生活水平的日益提高,人们对安全的需求也不断提升。随着宽带网络和网络监控摄像头的普及,尤其是廉价宽带进入家庭以及网络监控摄像头的多样化,家庭日常生活的视频监控成为监控行业的一个新领域。办公室、家庭、幼儿园、中小微企业等中小型监控场景,对成本控制比较敏感,不适宜采购大型视频监控设备。另外,由于目前智能手机的普及,通过用户APP实现视频监控成为一种急迫的需要。
随着视频监控系统[1-3]不断演进和流媒体技术[4-7]逐渐成熟,结合流媒体的视频监控系统得到广泛运用。目前,流媒体代表技术有Live555[4]和 Darwin Streaming Server[7,8]。杨耀森[2]构建一种流媒体传输存储的专用嵌入式平台并为其设计加密方案,致力于为新型智能的流媒体发展提供一种可靠的硬件选择。此外,目前已有大量视频图像分析算法的研究[1,6-8],因此,通过轻量级摄像头快速获得质量较好的图像可为后期的视频应用提供技术支撑。
本研究以中小型企事业单位或家庭日常生活的监控需求为背景,以Darwin的流媒体转发为核心,设计摄像头的数据采集层嵌入式程序,实现Android手机APP的视频监控,进一步实现一种轻量级、较高分辨率、多功能、易安装、易配置的摄像头和监控系统。
1 系统的总体设计
1.1 系统架构设计
系统由流媒体转发服务器、数据采集的设备和手机监控APP 3个部分组成。系统架构如下:设备侧的数据采集程序集成在嵌入式摄像头的单板内,服务侧的流媒体转发程序运行在云端,用户侧的监控程序为手机APP (图1)。
图1 系统架构图Fig.1 System architecture diagram
(1)设备侧的摄像头端嵌入式程序主要实现数据采集、编解码及传输。该程序可实时录制、存储监控信息在摄像头SD卡中,还可定时上传监控信息至远端云存储服务器,同时支持向现场发送语音,实现实时对话沟通。
(2)服务侧转发来自摄像头的流媒体数据包至用户APP,提供开启视频流、停止视频流、开启辅视频、开启缩略图视频和实时双向语音对讲等功能。
(3)用户侧的手机APP实现对用户和摄像头的管理功能,以及对设备的控制功能。使用者通过手机APP可自行注册监控用户,实现对个人信息和摄像头设备的管理,获取、访问远端摄像头,满足实时观看视频、实时音频对讲和历史录像回放等需求。
1.2 系统性能要求
所设计的监控系统可灵活部署于云端服务器上。摄像头支持H264视频编码格式,G711、AAC等多种音频编码格式,实现视频、音频信号的采集与编解码;采用AES加密算法对H264数据包进行加密。摄像头可推送1 080 P的视频数据流,其码率至少为2 Mbps,服务器可同时对100个终端的流媒体进行转发处理,百兆网络即可支持50台摄像头同时推送流媒体数据,同时可保证数据的安全传输。用户可通过手机APP监控并对设备进行管理。
2 系统详细设计与实现
系统业务逻辑层使用RestfulAPI消息接口,实现用户端和摄像头之间的控制、管理功能。
2.1 转发服务的设计与实现
转发服务的设计包括控制信令和流媒体数据的存储转发两个部分。通过转发用户APP的控制信令至摄像头,与数据采集端对接,实现实时视频一对多的转发、录像文件一对一的限定转发、双向语音实时对讲的功能。控制信令用于用户注册、管理,其数据存储在远端的阿里云服务器。
流媒体转发流程如图2所示:在Darwin架构的基础上,利用Live555的RTSP[5]流媒体传输协议,修改部分接口和数据结构以适应信令传递;设计信令的执行顺序流程,实现摄像头和监控APP的数据交互,保证流媒体的高效转发。
图2 流媒体转发流程图Fig.2 Flow chart of streaming media forwarding
CMS实现对接入的网络摄像头进行管理和功能操作,支持多设备接入和多级管理。信令转发服务:对流媒体转发服务器进行负载均衡管理,将音频数据当作信令转发。Redis[9]作为内存数据库支持CMS和Darwin[10]的信息互发现,支持摄像头信息管理:添加、删除、修改、与他人共享摄像头。Darwin支持RTSP协议的流媒体转发,可对不同请求端进行一对一、一对多或多对一的数据转发。
摄像头有主视频流、辅视频流和缩略图视频流3个数据推流通道。摄像头推送不同类型的数据流时,在发送请求信令中添加channel关键字,分别取值1,2,3用于区分不同通道。
2.1.1 主视频流转发模块
主视频流转发时序如图3所示,实现的具体步骤如下:(1)Darwin运行后,向Redis数据库写入自己的信息,同时查询CMS的信息;(2)CMS运行后,向Redis数据库写入自己的信息,同时查询Darwin的信息;(3)摄像头设备上线后自动注册到CMS设备管理中,保持一个TCP长连接;(4)用户端从CMS获取在线的摄像头列表;(5)用户端要查看某摄像头的实时视频,以摄像头id为参数向CMS发出请求;(6)CMS通过摄像头id向设备发送信令,推流到Darwin服务器;(7)摄像头设备开始推流到Darwin服务器;(8)CMS回应用户端,并提供RTSP流的地址;(9)用户端得到RTSP流地址后,播放RTSP流;(10)Darwin收到流请求,询问CMS,获取当前请求的转发规则并转发。
图3 主视频转发时序图Fig.3 Sequence diagram of main video forwarding
2.1.2 辅视频流转发模块
辅视频流用来传输视频录像回放信号,主视频流可以一对多转发,而辅视频流只能一对一转发。辅视频的转发与主视频流的转发流程基本一致,只需在第5步操作进行修改:用户端向CMS发出请求时,CMS先向Redis数据库查询是否已有其他用户请求辅视频。如果有其他用户在请求,则表示已有他人在观看,CMS将向用户端返回请求失败消息。
2.1.3 缩略图视频流转发模块
摄像头每隔一段时间(如1 s)采集当前的画面并编码成连续的视频作为缩略图。缩略图仅提供用户感受当前摄像头是否在工作,以及获取拍摄区域大致情况,不需要太高画质。因此,编码后的视频可以压缩成较小的分辨率,并可以去除P帧,以获得更好的网络传输表现。缩略图视频流的请求流程与主视频完全相同,仅在请求时将channel关键字赋值为3区分。
2.1.4 实时音频转发模块
用户观看实时视频时,可通过手机实现语音对话。语音可编码成数据包后发送到摄像头,摄像头收到语音数据后解码并通过自身的扬声器播放。摄像头的声音采集设备实时采集周围声音,并随实时视频画面打包到RTSP流传输给手机监控程序,从而实现双向实时语音交互。
实时音频对讲功能的时序如图4所示。(1)用户端接听摄像头捕获的实时音频:摄像头的音频编码成G711数据包,连同编码后的视频数据,通过RTSP协议推送到Darwin服务器,然后由Darwin服务器做成RTSP流转发给用户端。(2)摄像头接收到用户端的语音并可播放出来:将用户端的语音编码成G711数据包,通过信令发送给CMS,然后再由CMS转发给对应的摄像头。
图4 实时音频对讲功能时序图Fig.4 Sequence diagram of real-time audio intercom function
2.1.5 停止推流功能
用户应当可根据需要停止正在播放的任一媒体流。当用户停止播放时,播放端和解码器自行断开接收,同时须按以下流程通知服务器回收资源:用户端将要停止的摄像头uuid和媒体流通道号发送至EasyCMS;CMS从Redis数据库中查询当前视频流通道观看人数,如果为0,则通知摄像头关闭正在推送的媒体流;Darwin自行回收该媒体流停止后的资源。停止推流时序如图5所示。
图5 停止推流时序图Fig.5 Sequence diagram of stopping push-flow
2.2 设备采集功能的设计与实现
摄像头嵌入式程序实现视频和音频的实时信号采集、数据流加密、RTSP数据推流[11]、SD卡本地录像存储。基于MSTAR-AIT8328平台设计实现摄像头与服务器的信令交互。设备支持H264视频编码格式以及G711、AAC等多种音频编码格式,实现视频、音频信号的采集与编解码;同时,采用AES加密算法对H264数据包进行加密,保证数据传输的安全性,提高用户的隐私保护。
摄像头功能如下:负责对采集到的图像数据进行编码、打包成RTSP数据包,并传输到流媒体转发服务;循环录制实时视频,收到请求后采集实时视频的I帧,编码成缩略图视频流;实时双向语音对讲,接收用户从APP回传的音频并播放(图6)。
图6 摄像头嵌入式程序功能用例图Fig.6 Use case diagram of camera embedded program function
2.2.1 RTSP媒体推流设计
RTSP媒体推流库外部共有6个接口,分别如下:创建推流实例;释放推流实例;设置事件回调函数;设置日志回调函数;开始推流,创建信令交互;停止推流,终止信令交互。
设计一个主循环线程的状态机实现握手和协商命令的交互。主循环线程状态机有空闲(PUSH_IDLE)、初始化(PUSH_INIT)、开启(PUSH_START)、重启(PUSH_RESTART)、循环(PUSH_LOOP)、停止(PUSH_STOP) 6种状态。根据外部命令,主循环线程在6种状态之间切换以实现推流。
摄像头的进程要推送媒体数据时,先实例化推流模块,然后调用推流模块的“开始推流”方法。方法被执行后,模块将进行参数初始化,并启动主循环线程,在线程内进行RTSP数据包的推送工作。
2.2.2 本地录像设计
摄像头默认24小时循环往本地SD 卡写入录像文件。在启动录像之前,须执行SD卡检测状态流程,防止录像无法创建等异常问题。当录像线程创建完成后,开始调用FFMPEG库进行录像文件写入。定义单次录影时长为5 min,当一个录像时长达到5 min时,就会创建一个新的文件。具体实现过程如下:(1)用av_register_all()、avformat_alloc_output_context()、av_new_stream()初始化FFMPEG库的基本对象,并关联起来,然后使用avio_open()打开文件并写入文件头;(2)编码视频,并将编码后的数据通过av_write_frame()写到文件中,其中视频包从MSTAR的AIT8328平台提供的共享内存获取,不需要再另行编码;(3)写入文件尾,并清理ffmpeg对象。
2.2.3 媒体加解密设计
为保证RTSP流媒体的安全传输,采用AES加密算法对视频帧进行加密。H264数据包的NALU头的几种典型取值如下:0x65表示I帧,0x61表示P帧,0x67表示序列参数集,0x68表示图像参数集。参数集包括图像类型、序列号等所有分片信息,而且在解码前传输无需加密,因此只需对I帧和P帧加密。
当媒体包被加密后以RTP方式发送,RTP包中的序号必须指向正确的NALU 分片顺序,发送期间不能插队发送其他NALU。在网络接收方,NALU必须按照 RTP包的序号重新组装。
接收方收到RTP包后,将根据NALU类型判断是否直接解密。方法为读取RTP头部之后的第一个字节,并判断后五位的类型码。根据类型码确定该RTP包是单一NALU载荷、组合载荷还是分片载荷,提取出每个完整的载荷进行AES解密,还原真正的H264数据。
2.2.4 云存储的上传和下载功能设计
采用阿里云OSS云存储方案,将已生成存储在SD卡的录像文件上传云空间。向阿里云上传录像文件,先要获得阿里云的AccessKey 和 token。监控程序也可以直接从云空间下载和观看已上传的录像文件。
2.3 监控APP的功能设计与实现
手机监控APP实现的功能分为管理功能和控制功能。管理功能包括用户账号的创建、登录、注销,对摄像头设备进行添加、删除、修改配置、分享权限等操作。用户通过手机号注册,系统须向用户手机发送验证短信以通过注册。控制功能包含对摄像头进行播放、停止、语音对讲操作。用户可观看摄像头的实时视频、录像回放,与摄像头进行双向对讲。
手机监控APP基于BOSS[12]二次开发,设计与APP监控交互的接口和消息定义,采用HTTPS接口管理用户信息和设备信息;设计Android手机APP程序,实现手机短信注册、后台数据管理与维护、信令与消息转发、用户实时监控的功能。
2.3.1 用户管理模块设计
用户必须使用手机号码注册,系统调用短信业务平台发送验证码。输入验证码后调用APIverifyEmailSMSCode进行验证。
用户登录过需要调用SmartHome BOSS API[13]检索账号的用户名和密码令牌信息,再通过LOGIN_API检索账号的member code和用户名。用户对已存在的账号进行注销操作,注销后删除数据库内的相关信息并解绑摄像头设备。
2.3.2 设备管理设计
用户建立监控账号并获得一个新摄像头设备时,须为摄像头配置网络并与账号绑定。用户登录后,显示该账号链接的摄像头列表;可添加、修改、分享、删除摄像头。配置属性有个性化名称、视频分辨率、录像模式、日期显示模式等。用户可分享当前可查看的摄像头给其他用户,分享后的权限仅支持视频观看,不支持配置修改、删除等操作。每个用户都拥有自己的member code,APP以二维码形式呈现给其他用户,其他用户通过扫描该二维码可分享获得观看该摄像头视频的权限。
2.3.3 运动侦测事件模块设计
摄像头可通过运动传感器检测附近区域中的物体运动。当检测到运动物体时,摄像头向BANDOTT和监控软件双方发送通知。BANDOTT通过Bronci的IPNS服务器接收通知,监控APP则通过GCM或APNS接收通知。
2.3.4 APP监控软件接口定义
由于系统的前端和后台的实现是基于不同的框架,因此需要通用的接口格式,以实现跨平台通信。本研究采用HTTP协议[14],通过SSL或TLS加密处理数据、验证对方身份以及数据完整性保护,以保护用户的隐私信息[15]。此外,实时视频可以一对多转发,录像回放只能一对一转发,即同一时间只能有一个用户请求观看一个摄像头的录像回放。
用户登录后可点击某个摄像头查看实时视频流。摄像头收到请求后持续向用户端推送实时视频和音频。用户可回放摄像头录制的历史视频,播放时可随意拖动进度条快速定位播放起点。用户可点击停止播放按钮,也可直接使用手机的返回操作退出播放页面。停止实时视频播放时,整个系统仅停止从流媒体转发服务器推向该用户的连接端口。如果同时有多个用户观看一个摄像头,当停止某用户请求时,整个系统其他用户的观看不受影响。只有当系统记录到最后一个用户也停止观看时,才关闭摄像头向流媒体转发服务的端口。停止录像回放时,由于不存在其他用户的影响,整个系统当即停止此次播放相关的所有端口。
3 系统测试
系统由数据采集、流媒体转发和手机端APP 3个子系统构成,其中数据采集集成程序在嵌入式单板内,流媒体转发程序运行在云端。系统测试的流媒体服务器为3.4 GHz CPU,RAM 32 G, DDR31333,硬盘SATA 1 TB,Ubuntu16.04,5个安卓7.0的手机,20个摄像头。系统操作功能主要通过手机端的APP展示。如图7所示,用户输入用户名和密码登录成功后,可看到已添加的摄像头列表。点击某个摄像头后,进入实时视频播放界面。图8为其中的录像回放界面。用单元测试中的黑盒测试法对每个模块进行功能测试,系统稳定性测试则通过压力测试体现。经过72 h的长时间不间断测试,各子系统功能正常,且无内存溢出,表明该系统稳定可靠。
图7 摄像头列表界面图Fig.7 Diagram of camera list interface
图8 录像回放界面图Fig.8 Interface diagram of video playback page
4 结论
本研究实现的轻量级、实时、高效的小型应用场景视频监控系统可灵活部署于实体服务器或云端服务器上。系统摄像头可推送1 080 P的视频数据流,其码率至少为2 Mbps;服务器可对100台以内的媒体流进行转发处理,百兆网络可支持50台摄像头同时推送媒体数据。通过实验测试表明,系统具有稳定性、可靠性,在轻量级、实时、高效方面取得较好效果,所设计实现的摄像头与监控系统具有通用性,可向全社会广泛推广。