一种基于webRTC的移动摄像头人脸识别低延迟解决方法与流程

本发明涉及视频编解码相关技术领域，尤其是指一种基于webrtc的移动摄像头人脸识别低延迟解决方法。

背景技术：

在开发手机端人脸监控项目中，发现用手机端发送rtmp流到服务器用于人脸识别时，发现画面延迟过大的问题，且手机端距离越远，走公网流的延迟会更高会达到十多秒。

技术实现要素：

本发明是为了克服现有技术中存在上述的不足，提供了一种能够有效缩短延迟时间的基于webrtc的移动摄像头人脸识别低延迟解决方法。

为了实现上述目的，本发明采用以下技术方案：

一种基于webrtc的移动摄像头人脸识别低延迟解决方法，具体包括如下步骤：

(1)移动端发起人脸检测请求；

(2)由监控服务器向转码器发起转码任务；

(3)转码器向rtc服务器发起请求建立聊天房间；

(4)rtc服务器返回房间号给转码器；

(5)转码器告诉监控服务器房间号；

(6)监控服务器再告诉移动端房间号；

(7)移动端通过房间号连接rtc服务器加入房间；

(8)rtc服务器与通信云建立同房间的数据传输节点，基于webrtc进行时间低延迟数据传输；

(9)移动端开始发送数据经通信云给转码器；

(10)转码器建立一进两处任务，实现人脸抓拍和实时透传任务。

采用上述基于webrtc的移动摄像头人脸识别的低延迟解决方法，能够有效的实现降低画面延迟问题，利用opecv显示通过解码视频转成rbg24的数据，可以得出延迟结果大概在200ms到300ms之间，理论可以降到100ms以内；手机采用4g网络也差不多是这个延迟时间。

作为优选，在步骤(8)中，基于webrtc中具体包括rtcmessage、communication、通信云和硬件，其中rtcmessage是作为一个信令集，用于移动端向通信云发起请求创建房间或者加入房间，通信云创建房间成功后，再和移动端建立communication的通讯连接，由硬件采集音视频数据送向通信云或者接受通信云的数据。

作为优选，在步骤(10)中，转码器在建立一进两处任务时，采用了底层转码技术，继承了dshow框架进行实现，具体实现如下：首先由source模块接入rtc服务器获取移动端视频数据，再由inftee模块分发数据到视频数据解码器decoder和视频拼针模块framewrapper，第一分支视频数据解码器decoder解析码流数据，再传给视频编码器encoder编译成rgb24图，传给人脸识别模块进行特征对比，从而抓拍人脸；第二分支视频拼针模块framewrapper传给flvmux模块，生成rtmp直播流，添加音频静音包，进行实时透传。

作为优选，在步骤(10)中，收到视频数据，解码成h264裸数据，再把h264视频数据转化成rbg24图，用opencv的cv::imshow方法将图不停刷新显示出来，达到实时观看的效果。

作为优选，在步骤(10)中，人脸抓拍包括人脸检测、人脸跟踪、人脸识别和活体验证四个部分，人脸检测指的是检测静态图片人脸并返回人脸框坐标、landmark坐标以及质量分数信息；人脸跟踪指的是对复杂场景下的监控或动态视频实现毫秒级的人脸跟踪检测，实时获得每一帧中所有人脸的人脸框坐标、landmark坐标以及质量分数信息，且不受人脸遮挡、模糊、侧脸因素的影响；人脸识别指的是用于1:1以及1：n的人脸识别比对，其中1:1比对在召回率96％的情况下误识率低于十万分之一，1：n比对在大规模不限人种、不限年龄的人像数据底库上实现毫秒级的检索；活体验证指的是验证移动端摄像头前是否为真人操作。

本发明的有益效果是：能够有效的实现降低画面延迟问题，利用opecv显示通过解码视频转成rbg24的数据，可以得出延迟结果大概在200ms到300ms之间，理论可以降到100ms以内。

附图说明

图1是本发明的方法流程图；

图2是基于webrtc的示意图；

图3是底层转码技术的示意图。

具体实施方式

下面结合附图和具体实施方式对本发明做进一步的描述。

如图1所述的实施例中，一种基于webrtc的移动摄像头人脸识别低延迟解决方法，具体包括如下步骤：

(1)移动端(mobileapp)发起人脸检测请求；

(2)由监控服务器(monitorserver)向转码器(transcoder)发起转码任务；

(3)转码器(transcoder)向rtc服务器发起请求建立聊天房间；

(4)rtc服务器返回房间号(sessionid)给转码器(transcoder)；

(5)转码器(transcoder)告诉监控服务器(monitorserver)房间号(sessionid)；

(6)监控服务器(monitorserver)再告诉移动端(mobileapp)房间号(sessionid)；

(7)移动端(mobileapp)通过房间号(sessionid)连接rtc服务器加入房间；

(8)rtc服务器与通信云建立同房间的数据传输节点，基于webrtc进行时间低延迟数据传输；

如图2所示，基于webrtc中具体包括rtcmessage、communication、通信云和硬件，其中rtcmessage是作为一个信令集，用于移动端向通信云发起请求创建房间或者加入房间，通信云创建房间成功后，再和移动端建立communication的通讯连接，由硬件采集音视频数据送向通信云或者接受通信云的数据。

(9)移动端开始发送数据经通信云给转码器；

(10)转码器建立一进两处任务，实现人脸抓拍和实时透传任务；

转码器在建立一进两处任务时，采用了底层转码技术，继承了dshow框架进行实现，如图3所示，具体实现如下：首先由source模块接入rtc服务器获取移动端视频数据，再由inftee模块分发数据到视频数据解码器decoder和视频拼针模块framewrapper，第一分支视频数据解码器decoder解析码流数据，再传给视频编码器encoder编译成rgb24图，传给人脸识别模块进行特征对比，从而抓拍人脸；第二分支视频拼针模块framewrapper传给flvmux模块，生成rtmp直播流，添加音频静音包(且因为采用的是纯视频的传输机制，从而消除了av同步所需要的时间)，从而适应一定需要音频的rtmp流播放器，进行实时透传。

directshow是一个windows平台上的流媒体框架(本方法继承了该框架并在linux下实现)，提供了高质量的多媒体流采集和回放功能。它支持多种多样的媒体文件格式，包括asf、mpeg、avi、mp3和wav文件，同时支持使用wdm驱动或早期的vfw驱动来进行多媒体流的采集。directshow整合了其它的directx技术，能自动地侦测并使用可利用的音视频硬件加速，也能支持没有硬件加速的系统。directshow大大简化了媒体回放、格式转换和采集工作。但与此同时，它也为用户自定义的解决方案提供了底层流控制框架，从而使用户可以自行创建支持新的文件格式或其它用途的directshow组件。以下是几个使用directshow编写的典型应用：dvd播放器、视频编辑应用、avi到asf转换器、mp3播放器和数字视频采集应用。

收到视频数据，解码成h264裸数据，再把h264视频数据转化成rbg24图，用opencv的cv::imshow方法将图不停刷新显示出来，达到实时观看的效果。

人脸抓拍包括人脸检测、人脸跟踪、人脸识别和活体验证四个部分，人脸检测指的是检测静态图片人脸并返回人脸框坐标、landmark坐标以及质量分数信息，在fddb测试集上，检测效果达到业界领先水平；人脸跟踪指的是对复杂场景下的监控或动态视频实现毫秒级的人脸跟踪检测，实时获得每一帧中所有人脸的人脸框坐标、landmark坐标以及质量分数信息，且不受人脸遮挡、模糊、侧脸因素的影响；人脸识别指的是用于1:1以及1：n的人脸识别比对，其中1:1比对在召回率96％的情况下误识率低于十万分之一，1：n比对在大规模不限人种、不限年龄的人像数据底库上实现毫秒级的检索，动态复杂场景下可以实现多路视频、多人脸的实时识别与告警，在lfw测试集上，准确率达到99.87％；活体验证指的是验证移动端摄像头前是否为真人操作，防止利用高清照片、三维模型、视频录像、换脸等仿冒行为，满足敏感行业对人脸识别的安全需求。

采用上述基于webrtc的移动摄像头人脸识别的低延迟解决方法，能够有效的实现降低画面延迟问题，利用opecv显示通过解码视频转成rbg24的数据，可以得出延迟结果大概在200ms到300ms之间，理论可以降到100ms以内；手机采用4g网络也差不多是这个延迟时间，移动端在远距离采用4g延迟会稍高在2s左右。