CN114024941A - 一种基于WebRTC多终端多路实时视频监控方法 - Google Patents

Abstract

本发明提供一种基于WebRTC多终端多路实时视频监控方法，包括步骤一：根据摄像头视频流的接入方式配置摄像头信息；步骤二：启动所有后端服务程序响应前端视频请求并为前端提供统一的视频流监控控制服务并处理客户端的异常退出；步骤三：前端加载配置信息并解析为配置对象，完成与后端的身份元数据交互并建立基于WebRTC的端到端的视频数据传输并完成视频控制；本发明基于WebRTC协议和HTML5技术，提供统一通用的视频协议转换服务，将各类视频数据并将其转换为WebRTC协议直接用于WEB页面无插件播放视频；能更好的完成如视频巡检、视频组播、视频轮播、视频分析等各类视频应用。

Description

一种基于WebRTC多终端多路实时视频监控方法

技术领域

本发明属于城市轨道交通领域，具体可应用于城市轨道交通行业综合监控系统(ISCS)的闭路电视系统(CCTV)实时监控、安防系统实时视频监控、应急指挥系统实时视频的监控、智慧车站运管系统视频监控等领域。

背景技术

随着互联网技术、信息化管理技术的不断深化以及城市轨道交通行业各应用系统的不断发展。城市轨道交通行业各应用系统如SCADA系统、智慧运管系统、应急指挥系统及集成安防平台等系统的架构正逐步从C/S模式向B/S模式转变或采用B/S架构设计，以便更好的应用互联网、信息化、智能化等新技术和优势，实现各系统间更有效的融合、支持各类智慧应用，同时为未来系统云化部署奠定基础或提供便利条件。

随着城市轨道交通系统的集成需求越来越高，CCTV已经成为地铁系统中实现自动化调度和管理必不可少的部分，无论是在城市轨道交通行业的综合监控系统还是智慧运管系统、应急指挥系统、安防集成平台，都需要将包括车载及地铁站内的成百上千的高清视频采集的海量多媒体数据在WEB前端页面进行低延时的播放。

目前，在城市轨道交通行业内已实施的相关系统前端的视频播放功能还大多采用Flash插件技术。最近，国内某铁路车务段官方发布信息宣称受Flash停用影响车务段部分新购置并安装最新Flash版本的电脑无法通过浏览器访问统计现在车系统。一位长期从事铁路通信信号信息化建设的人士称，该车务段降低Flash版本使用，仍属于暂时解决方案，并没有从根本上解决问题，隐患仍然存在。“根治之道在于优化或重新搭建系统，使其运行和使用不依赖Flash。目前HTML5等技术已成熟，可以作为Flash内容的替代方案。但优化或重新搭建系统确实需要一定时间磨合。同样的，在轨道交通SCADA系统、轨道交通安防集成平台、轨道交通应急指挥系统等领域的实时视频监视功能同样面临B/S架构下视频接入的问题。而前端视频播放器插件多是基于Flash插件，虽然有些前端视频播放器插件在兼容原Flash的同时提供HTML5新技术，但是这样就需要在系统中引入插件，系统的可靠性或某些功能的实现都有可能受到插件的影响或限制。另外，有些视频播放器在基于B/S模式的单应用程序中，是否能完全适用处理多终端、多用户、同一视频源的同时访问等方面的需求目前都无法充分验证。因此，在安全性、可靠性要求比较高工控系统领域内并不是优选方案。

另外，工程实施现场视频源的接入方式多种多样，多数视频厂商提供便于C/S架构系统集成的SDK来对接其视频服务器，那么对于基于B/S架构的系统往往很难通过SDK的方式直接对接视频厂家的视频服务器。

发明内容

基于上述问题，本方案提出的一种基于WebRTC多终端多路实时视频监控方法，基于目前成熟的WebRTC协议和HTML5技术，直接用于WEB页面无插件播放视频，而且提供统一的视频协议转换处理服务，还提供了多终端多路监控视频的管理及处理方法。可同时实时在线播放多路视频且不影响对视频的控制，从而能更好的完成如视频巡检、视频组播、视频轮播、视频分析等各类视频应用，同时利用少量控制流数据高效稳定的实现全部与CCTV的接口功能。

为了实现上述目的，本发明采用的技术方案为：一种基于WebRTC多终端多路实时视频监控方法，包括以下步骤：

步骤1：根据摄像头视频流的接入方式配置摄像头信息；

步骤2：启动所有后端服务程序响应前端视频请求并为前端提供统一的视频流监控控制服务并处理客户端的异常退出；

步骤3：前端加载配置信息并解析为配置对象，完成与后端的身份元数据交互并建立基于WebRTC的端到端的视频数据传输并完成视频控制。

进一步的，所述步骤1中的设计关键配置项：stations，该配置项设计为一个数组结构，数组中的每一个元素为控制中心或车站或车辆段或停车场的配置对象，记为StationConfObj。

由于控制中心需要接入车站视频流，因此需区分控制中心和车站的摄像头列表的配置。所述stations数组的元素索引号被设计为控制中心和车站的索引号，索引号为0表示控制中心，然后车站或车辆段或停车场索引号从1开始编号。

所述StationConfObj对象主要包括type、machines、cctvInitPlaySetting、cctvDeviceList、trainList配置项。

所述StationConfObj对象type配置项取值：[1,2,3,4,5,6]。1表示控制中心、2表示变电所、3表示车辆段、4表示停车场、5表示地下站、6表示地面站。

当所述StationConfObj对象type的取值为1时，需要配置所述的trainList配置项，该配置项设计为数组结构，数组中的每一个元素为字符串类型，用于表示列车的名字。

所述machines配置项为数组结构，数组中的每一个元素为工作站的主机名，用于判断访问服务器的工作站是所属控制中心还是具体哪一个车站。

所述cctvInitPlaySetting配置项设计为对象结构。该配置项用于配置中心或车站或车辆段或停车场监视画面初始化时默认接入打开的摄像机，其主要配置项包括：name、InitcctvDeviceList。其中，name配置项用于配置描述信息；InitcctvDeviceList配置项设计为数组结构，数组中的每一个元素为一个配置项对象，记为InitcctvCameraConfObj。

所述InitcctvCameraConfObj主要包括的配置项为：accessMethod、type、name、channelId。其中，accessMethod用于标识视频流的接入方式，取值为[1,2]。当accessMethod＝1时，表示直接连接摄像头基于RTSP协议拉取视频流；当accessMethod＝2时，表示基于RTMP协议从流媒体服务器上获取视频流。该配置项不配置时，等效于accessMethod＝1，即默认基于RTSP协议拉取视频流。

所述InitcctvCameraConfObj的type配置项用于标识摄像机类型，取值为[1、2]，type取1时表示枪机，取2时表示球机。该配置项不配置时，等效于type取值1，即摄像机类型为枪机。

所述channelId用于唯一标识摄像机信息，该配置项的取值取决于accessMethod配置项的取值。当accessMethod＝1时，该配置项配置为摄像头的IP地址，当accessMethod＝2时，该配置项配置为摄像机通道号(由视频厂家提供)，形如"1807-Camera-334a5b6ac3cb4e6f94c7785bb71e839a:1@1807"。

所述cctvDeviceList配置项设计为数组结构。当所述StationConfObj对象type配置项取值为1(即为控制中心)时，cctvDeviceList数组中的每一个元素为一个数组，该数组中的元素与上述trainList配置项的元素一一对应，该数组的每一个元素为一个配置项对象，记为trainCameraConfObj。该配置对象也主要包括type、name、channelId配置项，每个配置项的配置方式与所述InitcctvCameraConfObj配置对象的每个配置项的配置相同。当所述的StationConfObj对象type配置项取值不为1(即不为控制中心)时，cctvDeviceList数组中的每一个元素设计为一个配置项对象，记为staionCameraConfObj，同样的该配置对象主要包括type、name、channelId配置项，每个配置项的配置方式与所述InitcctvCameraConfObj配置对象的每个配置项的配置相同。

设计关键配置项：Connection，该配置项设计为一个对象结构，用于前端视频流通道自动切换配置。前端程序通过该配置完成服务器是否在线的检测工作。Connection配置对象包含Heartbeat和Servers配置项。Heartbeat配置项为一个配置对象，包含Enabled、ActiveServerInterval以及InactiveServerInterval配置项。其中，Enabled表示是否开启心跳检测服务器状态功能，取值true表示开启，false为不开启，且只有Enabled配置为true时，ActiveServerInterval和InactiveServerInterval设置才有意义。ActiveServerInterval用于配置在线服务器检测时间间隔，单位是毫秒。InactiveServerInterval用于离线服务器检测时间间隔，单位是毫秒。Server配置项用于设置客户端可连接的服务器主机名。

配置对象可序列化后基于数据库存储，也可基于文件存储，基于文件存储时，需要提供中心到车站的文件同步功能。一般在中心修改配置文件，保存修改后分发到各车站。

进一步的，所述步骤二：启动所有后端服务程序响应前端视频请求并为前端提供统一的视频流监控控制服务并处理客户端的异常退出。

所述后端程序主要包括：视频请求代理服务程序、视频协议转换服务、基于SDK的视频转码服务，RTMP流媒体服务。

所述视频请求代理服务程序，该程序具备承前启后的作用，采用Websocket通信技术作为WebRTC端到端的信令服务并提供会话心跳检测服务，同时提供WeRTC服务功能。

所述视频请求代理服务程序，接收前端ClientWebRtcEndPoint基于SDP格式的WebRTC握手元数据的请求，并创建于其对应的ServerWebRtcEndPoint，来接收保存前端的WebRTC握手元数据，同时将ServerWebRtcEndPoint的元数据发送到前端ClientWebRtcEndPoint，完成端到端之间的身份数据交互，之后双方可基于WebRTC进行端到端的视频数据传输。

所述视频请求代理服务程序负责创建视频流接入对象PlayerEndPoint，该对象负责从所述视频协议转换服务获取基于RTSP协议的视频流或基于RTMP协议的视频流。

所述视频请求代理服务程序还负责创建视频流管线对象VideoPipeline，视频流管线的负责管理维护所述的ServerWebRtcEndPoint对象和PlayerEndPoint对象。VideoPipeline对象和PlayerEndPoint对象一一对应，一个VideoPipeline对象可以对应多个ServerWebRtcEndPoint对象，实现多个客户端播放同一视频流的需求。PlayerEndPoint对象将获取视频流数据输入到VideoPipeline对象；与VideoPipeline对象绑定的多个ServerWebRtcEndPoint对象从VideoPipeline中获取视频流并于其对应的ClientWebRtcEndPoint进行端到端的视频传输。

所述视频请求代理服务程序接收到前端定时间隔的数据检测心跳请求，然后基于该会话ID将该心跳请求的时间戳信息【sessionID，timestamp】保存到heartbeatStatus结构中，并像前端返回唯一的Token信息。

前端每次收到后台反馈后都校验后台返回的token是否和上次返回的token是否一致，若不一致，说明后台程序意外重启过。如果前端在指定的时间间隔内无法重新建立连接，则在前端主动切换WebSocket尝试备用通道连接，并重新请求所有打开的视频流。

对于推流方式视频流需要重新发起视频请求，并由后端重新生成并RTMP流地址，同时重新将摄像头视频流推送到nginx RTMP流媒体服务器，之后，前端可自动重播视频，从而解决因后台服务程序意外终止后，导致前端视频停止播放的问题。

所述视频请求代理服务程序维护视频流标识和引用客户端计数的数据结构，记为chCount；视频流标识与视频频流管线的映射数据结构，记为mediaVideoPipelines；会话ID和视频流标识的映射数据结构，记为simSession2Ch。

所述视频流标识采用摄像机的通道号channelId，对于SDK方式的该标识可为摄像机的通道Id(ChanelId)，该ChanelId由视频厂家的视频服务器提供。对于从摄像头基于RTSP拉取的流可以是摄像头的IP地址。

所述视频请求代理服务程序负责接收前端的视频云台控制RESTful请求，并根据所述视频流标识区分不同控制方式请求，然后转发基于ModBus协议或基于onvif协议的控制请求分别到基于SDK的视频转码服务或摄像机。

当不同的客户端发起请求时，首先，记录该客户端的SessionID和其所请求的ChanelId到simSession2Ch。

其次，检查chCount中是否包含本次请求的ChanelId，若未包含，将本次请求的ChanelId以及初次计数1保存到chCount中，若包含，则将本次请求ChanelId对应的计数加1。

然后，根据本次请求的ChanelId从mediaVideoPipelines获取VideoPipeline对象。若不存在，第一步，创建VideoPipelines对象；第二步，创建与其一一对应的PlayerEndPoint对象并于其进行关联，第三，将本次请求的ChanelId和VideoPipelines对象保存至mediaVideoPipelines并返回PlayerEndPoint对象。若存在，直接返回本次请求ChannelId对应的mediaVideoPipelines对象所关联的PlayerEndPoint对象。

最后，创建用于本次端对端WebRTC视频通信的ServerWebRtcEndPoint对象并和PlayerEndPoint对象建立关联。

所述视频请求代理服务程序所创建的定时检查线程在定时器所设置的超时时间到达时，检查heartbeatStatus中心跳异常的会话ID，然后从simSession2Ch中获取所有的会话对应的ChannelId，然后检查chCount中是否存在该ChannelId，若有其对应的计数减1，当计数减为0时，释放该ChannelId对应的mediaVideoPipelines对象。

所述视频请求代理服务程序监听WebSocket断开连接的消息，用于处理客户端网页异常关闭或刷新时的后端资源释放。当出现这些情况时，所述视频请求代理服务程序对heartbeatStatus中的所有会话Id进行如上所述的定时器超时所进行的操作处理。

所述基于SDK的视频转码服务主要利用视频厂家提供的SDK打开视频流并对视频流数据进行解析抽取其裸码流，并将裸码流转换成RTMP协议格式，然后将其推送至所述的RTMP流媒体服务。

所述基于SDK的视频转码服务负责接收所述视频请求代理服务程序发送的基于Modbus协议的视频控制请求，完成视频云台控制功能。

所述RTMP流媒体服务用于响应视频协议转换服务的请求为其提供基于RTMP协议的视频流。

所述视频协议转换服务根据客户端请求参数是RTSP还是RTMP分别从摄像机拉取RTSP协议的视频流或从流媒体服务请求RTMP视频流，然后将视频流发送至所述视频请求代理服务程序的PlayerEndPoint对象，然后由其再发送至mediaVideoPipelines对象，再由于其绑定的一个或多个ServerWebRtcEndPoint对象负责与其对应前端的ClientWebRtcEndPoint完成端到端的视频数据交互。

进一步的，所述步骤三：前端加载配置信息并解析为配置对象，完成与后端的身份元数据交互并建立基于WebRTC的端到端的视频数据传输并完成视频控制。

前端创建配置文件解析及管理对象，在前端完成配置文件的加载，然后对配置文件进行解析反序列化为配置对象。前端通过所述的配置文件管理提供获取步骤一所述的stations配置对象、根据请求工作站主机名确定请求工作站是否控制中心或车站；根据站索引获取特定站对象等功能。

前端根据步骤一所述的关键配置项Connection获取Heartbeat和Servers配置项，然后会基于WebSocket尝试和每一个运行服务器建立通道检测心跳连接，并以此来维护一个可用服务器列表。若当前客户端在检测周期内和其进行数据通信的服务器失去心跳连接时，会清除当前连接通道并从可用服务器列表中获取一个可用的服务器重新与其建立连接，并重新向步骤二所述视频请求代理服务程序建立基于WebRTC的端到端的视频流通信。

前端支持冗余通道主动切换功能，从而方便对某台服务器的升级维修时不影响业务运行。

前端提供不同宫格布局方式的视频流显示布局功能以及不同布局的切换功能。

前端视频源选择功能依赖于当前登录地点是控制中心还是车站。前端摄像机可选列表可以自动根据工作站的主机名区分是中心和车站，完整对应摄像机列表的过滤。当前登录地点为控制中心是，可以选择列车的车载摄像机、全线所有车站的摄像机信息；若当前登录地点为某车站，那么前端只允许选择该车站的视频源信息。

前端支持视频点播模式、视频快捷组播模式以及视频轮播模式。所述布局中的每一个视频播放窗口都可进行视频点播、快捷编组播放、视频轮播。

所述快捷编组播可以通过组播配置功能完成快捷组播中视频源设置以及所采用的宫格布局的设置。启动一个快捷编组播配置项时，该功能会根据宫格布局的设置信息，自动在用于视频播放的宫格自动播放所配置的所有视频源。

所述视频轮播可以通过轮播配置功能完成轮播视频源、轮播顺序、轮播间隔的设置。使用该功能时，首先在用于视频播放的宫格选择一个播放功能，然后选择一个轮播配置项并启用，启用后轮播功能会根据所配置视频源及轮播顺序、轮播间隔在当前播放宫格中循环轮播。

前端可根据摄像机类型是否为球机，判断是否可对选定摄像头进行云台操作。另外，在视频轮播模式下不允许视频云台控制操作。

前端可对正在播放的视频的摄像机进行预置位读取、修改及重命名操作。

所述视频点播模式、视频快捷组播模式以及视频轮播模式中的每一个视频源的视频流的请求及释放都是一个向所述视频请求代理服务程序建立或释放基于WebRTC的端到端的视频流通信的过程，且每一个端到端的视频流建立时所基于WebSocket建立的信令服务也都会和所述视频请求代理服务程序保持一个数据心跳，以便视频请求代理服务程序能在前端异常或刷新退出时自动关闭释放端到端的视频流。

与现有技术相比，本发明的优点在于：本发明基于目前成熟的WebRTC协议和HTML5技术，直接用于WEB页面无插件播放视频，而且提供统一的视频协议转换处理服务，还提供了多终端多路监控视频的管理及处理方法。可同时实时在线播放多路视频且不影响对视频的控制，从而能更好的完成如视频巡检、视频组播、视频轮播、视频分析等各类视频应用，同时利用少量控制流数据高效稳定的实现全部与CCTV的接口功能。

附图说明

图1为本发明多终端多路实时视频监控方法的整体数据流图。

图2为本发明多终端多路实时视频监控方法的配置数据结构示意图。

图3为本发明多终端多路实时视频监控方法的整体功能架构图。

图4为本发明多终端多路实时视频监控方法的流程示意图。

具体实施方式

为了使本领域技术人员能进一步了解本发明的特征及其技术内容，请参阅以下有关本发明的详细说明与附图，附图提供参考及说明并非用来限制本发明。

下面结合附图，对本发明的特征和技术实施方案进行描述。

本实施例为B/S架构部署，分为客户端和服务端。客户端和服务端通信方式采用wss协议的WebSocket，其整体数据流如图1所示。

另外，为方便处理，在本实施例中，摄像头信息采用配置文件形式，示例配置文件如图2所示。对于视频快捷组播及轮播配置数据存储在MySql数据库中。

视频请求代理服务程序(VideoRequestAgentService)提供基于WebRTC端到端通信建立前的信令服务、WebRTC端到端通信服务端视频流端点、视频管线、播放视频流的创建管理以及数据心跳、通道心跳服务，整合基于onvif协议的云台控制并接收处理前端的云台控制请求，最后该程序还整合了基于FFMPEG的协议转换服务用于处理H265编码的视频流。对于H264编码且采用RTSP协议直接拉取视频流到WebRTC协议转换采用Kurento进行搭建，进程服务为视频协议统一转换服务KMSServer。

一般对于云台控制工程实施现场可采用基于ModBus协议的通信接口实现控制数据流或基于onvif协议的方式实施。

VideoRequestAgentService服务负责接收前端的控制RESTFul请求，并根据不同控制方式转发基于ModBus协议或基于onvif协议的控制请求分别到基于SDK的视频转码服务或摄像机。

本实例中视频控制数据通过RESTFul方式并基于onvif协议的方式实施视频云台控制功能。

本实施例中采用了某厂家的视频服务器，并采用基于SDK的视频转码服务调用其SDK打开并解析其视频流，形成裸码流后，基于RTMP协议推送到Nginx服务器并向返回RTMP协议地址，视频请求代理服务程序通过该地址获取基于RTMP协议视频流并负责将其转为WebRtc协议。

本实施例中，后台RTMP流媒体服务采用Nginx搭建。

本实施例的整体功能架构如图3所示。

具体实施步骤，如图4所示，具体如下：

步骤一：根据摄像头视频流的接入方式配置摄像头信息。

Step1、配置中心接入摄像头的配置信息。

Step1_1配置stations数组中的第一个配置对象，该配置对象在数组中的索引为0，表示为配置中心的配置项，并配置其主要子配置项name、type、trainList、machines。其中，name配置项用于配置名称，如图2所示，配置为OCC控制中心的缩写；type配置项配置为1，其取值区间[1,2,3,4,5,6]。1表示控制中心、2表示变电所、3表示车辆段、4表示停车场、5表示地下站、6表示地面站；trainList配置项为控制中心特有配置用于配置所有列车的名称，为一个字符串数组；machines配置项用于配置所访问的服务器主机名用于判断访问服务器的工作站是所属控制中心还是具体哪一个车站。

Step1_2配置Step1_1所述配置对象的子配置项：cctvInitPlaySetting配置对象。该配置项用于表示等用于在控制中心登录系统时，实时视频监控采用的布局以及自动播放的摄像头。该配置对象为一个对象数组，其中每一个元素为一个摄像机配置对象，其配置子项：name，InitcctvDeviceList，其中name用于配置描述信息。

Step1_3配置Step1_2所述摄像机配置对象的配置子项InitcctvDeviceList，该对象配置子项：name，accessMethod，channelId，type。其中name配置为摄像机名称；取值为[1,2]。当accessMethod＝1时，表示直接连接摄像头基于RTSP协议拉取视频流；当accessMethod＝2时，表示基于RTMP协议从流媒体服务器上获取视频流，若该配置项不配置则默认基于RTSP协议拉取视频流。channelId用于配置唯一标识摄像机信息，该配置项的取值取决于accessMethod配置项的取值。当accessMethod＝1时，该配置项配置为摄像头的IP地址，当accessMethod＝2时，该配置项配置为摄像机通道号(由视频厂家提供)，形如"1807-Camera-334a5b6ac3cb4e6f94c7785bb71e839a:1@1807"；type配置项用于标识摄像机类型，取值为[1、2]，type取1时表示枪机，取2时表示球机。该配置项不配置时，等效于type取值1，即摄像机类型为枪机。

Step1_4配置Step1_1所述配置对象的子配置项：cctvDeviceList。该子配置项为二维数组，数组中的每一个元素为一个数组，该数组中的元素与Step1_1所述trainList配置项的元素一一对应，该数组的每一个元素为一个列车摄像头配置对象，用于配置列车摄像头配置信息。

Step1_5配置Step1_4所述列车摄像头配置对象，该配置对象也包括name，accessMethod，channelId，type配置子项，各子配置项的配置含义及取值和Step1_3所述的配置子项InitcctvDeviceList的配置方式类似。

Step2、配置车站接入摄像头的配置信息

Step2_1根据实际车站的数量从stations数组索引为1的位置依次配置，每一个数组元素为一个配置对象，该配置对象包括子配置项：name，type、cctvDeviceList和machines。nam配置项用于配置车站名称；type配置项的取值和Step1_1所述type配置项的取值相同；machines配置项含义和Step1_1中所述machines配置项含义相同。

Step2_2配置Step2_1所述的cctvDeviceList配置项，该配置项为一个一维数组，数组中的每一个元素为一个车站摄像头配置对象，用于配置车站摄像头配置信息。每一个车站摄像头配置对象包括name，accessMethod，channelId，type配置子项各子配置项的配置含义及取值和Step1_3所述的配置子项InitcctvDeviceList的配置方式类似。

Step3、配置冗余通道及通道心跳检测间隔配置项Connection，该配置项配置子项：Heartbeat，Servers。

Step3_1配置Step3所述的Heartbeat配置项。该配置项需要配置Enabled、ActiveServerInterval以及InactiveServerInterval子配置项。其中Enabled表示是否开启心跳检测服务器状态功能，取值true表示开启，false为不开启，且只有Enabled配置为true时，ActiveServerInterval和InactiveServerInterval设置才有意义。ActiveServerInterval用于配置在线服务器检测时间间隔，单位是毫秒。InactiveServerInterval用于离线服务器检测时间间隔，单位是毫秒。

Step3_2配置Step3所述的Servers配置项。该配置项用于设置客户端可连接的服务器主机名。

Step4、将配置文件分发至冗余服务器。

步骤二：启动所有后端服务程序响应前端视频请求并为前端提供统一的视频流监控控制服务并处理客户端的异常退出。

Step1、在冗余服务器上依次启动视频协议统一转换服务KMSServer、视频请求代理服务程序(VideoRequestAgentService)、基于SDK的视频转码服务和RTMP流媒体服务。

Step2KMSServer服务启动后，等待Step1所述VideoRequestAgentService服务的视频管线对象(PipeLine)、服务端点(WeRTCEndpoint)，流播放对象(PlayerEndPoint)的创建及操作请求。

Step3、VideoRequestAgentService启动及服务处理。

Step3_1VideoRequestAgentService首先加载解析步骤一所述的摄像头配置信息解析提取channelId、accessMethod等关键配置信息。

Step3_2、VideoRequestAgentService监听客户端通信通道的心跳检测请求并对其进行响应。

Step3_3、VideoRequestAgentService监听ClientWebRtcEndPoint基于SDP格式的WebRtc握手元数据的请求，并创建于其对应的ServerWebRtcEndPoint来接收保存前端的WebRtc握手元数据，同时将ServerWebRtcEndPoint的元数据发送到前端ClientWebRtcEndPoint。完成端到端之间的身份数据交互，之后双方可基于WebtRtc进行端到端的视频数据传输。

Step3_4、VideoRequestAgentService统一处理客户端的视频请求。

接收客户端的视频打开释放请求，首先判断视频数据的来源.

若视频数据的来源取至于视频厂家提供的视频服务器，则把请求转发至基于SDK的视频转码服务。该服务通过调用视频厂家的视频SDK完成视频流的打开、关闭以及转码服务，解析出裸码流转换成RTMP协议推送至Nginx流媒体服务器并将RTMP流地址返回给VideoRequestAgentService，并由其发送至KMSServer，最后由KMSServer从Nginx流媒体服务器获取视频流再将其转成WebRtc协议返回给VideoRequestAgentService。

若视频源直接取至于摄像头，则依据视频数据的编码方式分别进行处理，若视频编码方式为H264则直接将请求发送至KMSServer完成RTSP到WebRtc协议的转换；若视频编码方式为H264则将请求交给VideoRequestAgentService的基于FFMPEG的协议转换服务子模块，由其将RTSP先转成RTMP，然后推送至Nginx流媒体服务器并返回RTMP流地址，最后再将RTMP流地址发送至KMSServer，最后由KMSServer从Nginx流媒体服务器获取视频流再将其转成WebRtc协议。

Step3_5、VideoRequestAgentService端到端视频流的传输及管理。

Step3_5_1、VideoRequestAgentService首先，创建视频流接入对象PlayerEndPoint，该对象负责从所述视频协议转换服务获取基于RTSP协议的视频流或基于RTMP协议的视频流；其次，创建视频流管线对象VideoPipeline，视频流管线的负责管理维护所述的ServerWebRtcEndPoint对象和PlayerEndPoint对象；最后将VideoPipeline对象、PlayerPoint对象和ServerWebRtcEndPoint对象建立关联：VideoPipeline对象和PlayerPoint对象一一对应，一个VideoPipeline对象可以对应多个WebRtcEndPoint对象，实现多个客户端播放同一视频流的需求。PlayerPoint对象将获取视频流数据输入到VideoPipeline对象；与VideoPipeline对象绑定的多个ServerWebRtcEndPoint对象从VideoPipeline中获取视频流并于其对应的ClientWebRtcEndPoint进行端到端的视频传输。

Step3_5_2、VideoRequestAgentService接收到前端定时间隔的数据检测心跳请求，然后基于该会话ID将该心跳请求的时间戳信息【sessionID，timestamp】保存到heartbeatStatus结构中，并像前端返回唯一的Token信息。

VideoRequestAgentService维护视频流标识和引用客户端计数的数据结构，记为chCount；视频流标识与视频频流管线的映射数据结构，记为mediaVideoPipelines；会话ID和视频流标识的映射数据结构，记为simSession2Ch。

所述视频流标识采用摄像机的通道号channelId，对于SDK方式的该标识可为摄像机的通道Id(ChanelId)，该ChanelId由视频厂家的视频服务器提供。对于从摄像头基于RTSP拉取的流可以是摄像头的IP地址。

当多个不同的客户端发起请求时：

首先，记录该客户端的SessionID和其所请求的ChanelId到simSession2Ch。

其次，检查chCount中是否包含本次请求的ChanelId，若未包含，将本次请求的ChanelId以及初次计数1保存到chCount中，若包含，则将本次请求ChanelId对应的计数加1。

然后，根据本次请求的ChanelId从mediaVideoPipelines获取VideoPipeline对象。若不存在，第一步，创建VideoPipelines对象；第二步，创建与其一一对应的PlayerPoint对象并于其进行关联，第三，将本次请求的ChanelId和VideoPipelines对象保存至mediaVideoPipelines并返回PlayerPoint对象。若存在，直接返回本次请求ChannelId对应的mediaVideoPipelines对象所关联的PlayerPoint对象。

最后，创建用于本次端对端WebRTC视频通信的ServerWebRtcEndPoint对象并和PlayerPoint对象建立关联。

当VideoRequestAgentService的定时检查线程在定时器所设置的超时时间到达时，检查heartbeatStatus中心跳异常的会话ID，然后从simSession2Ch中获取所有的会话对应的ChannelId，然后检查chCount中是否存在该ChannelId，若有其对应的计数减1，当计数减为0时，释放该ChannelId对应的mediaVideoPipelines对象。

Step3_6、VideoRequestAgentService监听WebSocket断开连接的消息，用于处理客户端网页异常关闭或刷新时的后端资源释放。

步骤三：前端加载配置信息并解析为配置对象，完成与后端的身份元数据交互并建立基于WebRTC的端到端的视频数据传输并完成视频控制。

Step1前端创建配置文件解析及管理对象，在前端完成配置文件的加载，然后对配置文件进行解析反序列化为配置对象。前端通过所述的配置文件管理提供获取Stations列表对象、根据请求工作站主机名确定请求工作站是否控制中心或车站；根据站索引获取特定站对象等功能。

Step2前端根据Step1所述的关键配置项Connection获取Heartbeat和Servers配置项，然后会基于WebSocket尝试和每一个运行服务器建立通道检测心跳连接，并以此来维护一个可用服务器列表。若当前客户端在检测周期内和其进行数据通信的服务器失去心跳连接时，会清除当前连接通道并从可用服务器列表中获取一个可用的服务器重新与其建立连接，并重新向步骤二所述视频请求代理服务程序建立基于WebRTC的端到端的视频流通信。

Step3组播、轮播设置

Step/3_1组播设置，通过组播配置功能完成快捷组播中视频源设置以及所采用的宫格布局的设置；

Step3_2轮播设置：通过轮播配置功能完成轮播视频源、轮播顺序、轮播间隔的设置。

Step4视频点播操作。

Step4_1视频源设置，当前登录地点为控制中心时，可以选择列车的车载摄像机、全线所有车站的摄像机信息；若当前登录地点为某车站，那么前端只允许选择该车站的视频源信息。

Step4_2视频播放宫格布局设置及播放宫格选择，本实施例中可进行1，4，9宫格三种布局方式的切换。

Step4_3向VideoRequestAgentService发送信令请求，然后与其建立基于WebRTC协议的端到端的视频数据传输。

Step5启动一个快捷编组播配置项，该功能会根据宫格布局的设置信息，自动在用于视频播放的宫格播放所配置的所有视频源。

Step6启动一个轮播配置项，会根据所配置视频源及轮播顺序、轮播间隔在当前播放宫格中循环轮播。

Step7云台控制操作，根据摄像机类型是否为球机，判断是否可对选定摄像头进行云台操作。另外，在视频轮播模式下不允许视频云台控制操作。

Step8正在播放的视频的摄像机进行预置位读取、修改及重命名操作。

Step9停止其中一台冗余服务器上运行的VideoRequestAgentService服务，前端正在播放的视频此时会重新和备用的VideoRequestAgentService服务进行信令身份元数据的互认，然后建立基于WebRTC协议的端到端的视频数据传输。

本实施例提供的一种基于WebRTC多终端多路实时视频监控方法，基于目前成熟的WebRTC协议和HTML5技术，直接用于WEB页面无插件播放视频，而且提供统一的视频协议转换处理服务，还提供了多终端多路监控视频的管理及处理方法。可同时实时在线播放多路视频且不影响对视频的控制，从而能更好的完成如视频巡检、视频组播、视频轮播、视频分析等各类视频应用，同时利用少量控制流数据高效稳定的实现全部与CCTV的接口功能。

以上的实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。

Claims (10)

1.一种基于WebRTC多终端多路实时视频监控方法，其特征在于：包括以下步骤：

步骤1：根据摄像头视频流的接入方式配置摄像头信息；

步骤2：启动所有后端服务程序响应前端视频请求并为前端提供统一的视频流监控控制服务并处理客户端的异常退出；

步骤3：前端加载配置信息并解析为配置对象，完成与后端的身份元数据交互并建立基于WebRTC的端到端的视频数据传输并完成视频控制。

2.根据权利要求1所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤1包括：

步骤1-1：配置中心接入摄像头的配置信息；

步骤1-2：配置车站接入摄像头的配置信息；

步骤1-3：配置冗余通道及通道心跳检测间隔配置项Connection；

步骤1-4：将配置文件分发至冗余服务器。

3.根据权利要求2所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤1-1具体为：

步骤1-1-1：配置数组stations中的第一个配置对象，该配置对象在数组中的索引为0，表示为配置中心的配置项，并配置其子配置项name、type、trainList和machines；其中，name配置项用于配置名称，type配置项配置为x，x的取值区间为1-6，1表示控制中心、2表示变电所、3表示车辆段、4表示停车场、5表示地下站、6表示地面站；trainList配置项为控制中心特有配置用于配置所有列车的名称，为一个字符串数组；machines配置项用于配置所访问的服务器主机名用于判断访问服务器的工作站是所属控制中心还是具体哪一个车站；

步骤1-1-2：配置步骤1-1-1中所述配置对象的子配置项：cctvInitPlaySetting，该配置项用于表示等用于在控制中心登录系统时，实时视频监控采用的布局以及自动播放的摄像头；所述cctvInitPlaySetting配置对象为一个对象数组，其中每一个元素为一个摄像机配置对象，其配置子项：name，InitcctvDeviceList，其中name用于配置描述信息；

步骤1-1-3：配置步骤1-1-2中所述摄像机配置对象的配置子项InitcctvDeviceList，该对象配置子项：name，accessMethod，channelId，type；其中name配置为摄像机名称，accessMethod表示视频流的获取途径，channelId用于配置唯一标识摄像机信息，type配置项用于标识摄像机类型；

步骤1-1-4：配置步骤1-1-1中所述配置对象的子配置项：cctvDeviceList，该子配置项cctvDeviceList为二维数组，数组中的每一个元素为一个数组，该数组中的元素与步骤1-1-1所述trainList配置项的元素一一对应，该数组的每一个元素为一个列车摄像头配置对象，用于配置列车摄像头配置信息；

步骤1-1-5：配置步骤1-1-4中所述列车摄像头的配置对象。

4.根据权利要求2所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤1-2具体为：

步骤1-2-1：根据实际车站的数量从stations数组索引为1的位置依次配置，每一个数组元素为一个配置对象，该配置对象包括子配置项：name，type、cctvDeviceList和machines；其中，name配置项用于配置车站名称；type配置项配置为y，y的取值区间为1-6，1表示控制中心、2表示变电所、3表示车辆段、4表示停车场、5表示地下站、6表示地面站；machines配置项用于配置所访问的服务器主机名用于判断访问服务器的工作站是所属控制中心还是具体哪一个车站；

步骤1-2-2：配置步骤1-2-1中所述的cctvDeviceList配置项，该配置项为一个一维数组，数组中的每一个元素为一个车站摄像头配置对象，用于配置车站摄像头配置信息，每一个车站摄像头配置对象包括name，accessMethod，channelId，type配置子项，其中name配置为摄像机名称，accessMethod表示视频流的获取途径，channelId用于配置唯一标识摄像机信息，type配置项用于标识摄像机类型。

5.根据权利要求2所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤1-3中配置项Connection的配置子项包括Heartbeat和Servers，具体为：

步骤1-3-1：配置所述配置子项Heartbeat，该配置子项需要配置Enabled、ActiveServerInterval以及InactiveServerInterval子配置项，其中Enabled表示是否开启心跳检测服务器状态功能，取值true表示开启，false为不开启，且只有Enabled配置为true时，ActiveServerInterval和InactiveServerInterval设置才有意义；ActiveServerInterval用于配置在线服务器检测时间间隔，单位是毫秒；InactiveServerInterval用于离线服务器检测时间间隔，单位是毫秒；

步骤1-3-2：配置所述配置子项Servers，该配置子项用于设置客户端可连接的服务器主机名。

6.根据权利要求1所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤2具体包括：

步骤2-1：在冗余服务器上依次启动视频协议统一转换服务KMSServer、视频请求代理服务程序VideoRequestAgentService、基于SDK的视频转码服务和RTMP流媒体服务；

步骤2-2：KMSServer服务启动后，等待步骤2-1所述视频请求代理服务程序VideoRequestAgentService服务的视频管线对象PipeLine、服务端点WeRTCEndpoint和流播放对象PlayerEndPoint的创建及操作请求；

步骤2-3：视频请求代理服务程序VideoRequestAgentService启动及服务处理。

7.根据权利要求1所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤2-3具体为：

步骤2-3-1：视频请求代理服务程序VideoRequestAgentService首先加载解析步骤1所述的摄像头配置信息，解析提取channelId和accessMethod配置信息；

步骤2-3-2：视频请求代理服务程序VideoRequestAgentService监听客户端通信通道的心跳检测请求并对其进行响应；

步骤2-3-3：视频请求代理服务程序VideoRequestAgentService监听ClientWebRtcEndPoint基于SDP格式的WebRtc握手元数据的请求，并创建于其对应的ServerWebRtcEndPoint来接收保存前端的WebRtc握手元数据，同时将ServerWebRtcEndPoint的元数据发送到前端ClientWebRtcEndPoint，完成端到端之间的身份数据交互，之后双方可基于WebtRtc进行端到端的视频数据传输；

步骤2-3-4：视频请求代理服务程序VideoRequestAgentService统一处理客户端的视频请求；

步骤2-3-5：视频请求代理服务程序VideoRequestAgentService端到端视频流的传输及管理；

步骤2-3-6：视频请求代理服务程序VideoRequestAgentService监听WebSocket断开连接的消息，用于处理客户端网页异常关闭或刷新时的后端资源释放。

8.根据权利要求7所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤2-3-4具体为：

接收客户端的视频打开释放请求，首先判断视频数据的来源；

若视频数据的来源取至于视频厂家提供的视频服务器，则把请求转发至基于SDK的视频转码服务，该服务通过调用视频厂家的视频SDK完成视频流的打开、关闭以及转码服务，解析出裸码流转换成RTMP协议推送至Nginx流媒体服务器并将RTMP流地址返回给VideoRequestAgentService，并由其发送至KMSServer，最后由KMSServer从Nginx流媒体服务器获取视频流再将其转成WebRtc协议返回给VideoRequestAgentService；

若视频源直接取至于摄像头，则依据视频数据的编码方式分别进行处理，若视频编码方式为H264则直接将请求发送至KMSServer完成RTSP到WebRtc协议的转换；若视频编码方式为H264则将请求交给VideoRequestAgentService的基于FFMPEG的协议转换服务子模块，由其将RTSP先转成RTMP，然后推送至Nginx流媒体服务器并返回RTMP流地址，最后再将RTMP流地址发送至KMSServer，最后由KMSServer从Nginx流媒体服务器获取视频流再将其转成WebRtc协议。

9.根据权利要求7所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤2-3-5包括：

步骤2-3-5-1：首先，创建视频流接入对象PlayerEndPoint，该对象负责从所述视频协议转换服务获取基于RTSP协议的视频流或基于RTMP协议的视频流；其次，创建视频流管线对象VideoPipeline，视频流管线的负责管理维护所述的ServerWebRtcEndPoint对象和PlayerEndPoint对象；最后将VideoPipeline对象、PlayerPoint对象和ServerWebRtcEndPoint对象建立关联：VideoPipeline对象和PlayerPoint对象一一对应，一个VideoPipeline对象可以对应多个WebRtcEndPoint对象，实现多个客户端播放同一视频流的需求；PlayerPoint对象将获取视频流数据输入到VideoPipeline对象；与VideoPipeline对象绑定的多个ServerWebRtcEndPoint对象从VideoPipeline中获取视频流并于其对应的ClientWebRtcEndPoint进行端到端的视频传输；

步骤2-3-5-2：视频请求代理服务程序VideoRequestAgentService接收到前端定时间隔的数据检测心跳请求，然后基于该会话ID将该心跳请求的时间戳信息sessionID-timestamp保存到heartbeatStatus结构中，并像前端返回唯一的Token信息。

10.根据权利要求1所述的基于WebRTC多终端多路实时视频监控方法，其特征在于：所述步骤3包括：

步骤3-1：前端创建配置文件解析及管理对象，在前端完成配置文件的加载，然后对配置文件进行解析反序列化为配置对象；前端通过所述的配置文件管理提供获取Stations列表对象、根据请求工作站主机名确定请求工作站是否控制中心或车站；根据站索引获取特定站对象的功能；

步骤3-2：前端根据步骤1中所述的关键配置项Connection获取Heartbeat和Servers配置项，然后会基于WebSocket尝试和每一个运行服务器建立通道检测心跳连接，并以此来维护一个可用服务器列表；若当前客户端在检测周期内和其进行数据通信的服务器失去心跳连接时，会清除当前连接通道并从可用服务器列表中获取一个可用的服务器重新与其建立连接，并重新向步骤2所述视频请求代理服务程序建立基于WebRTC的端到端的视频流通信；

步骤3-3：进行组播和轮播设置；所述组播设置为：通过组播配置功能完成快捷组播中视频源设置以及所采用的宫格布局的设置；所述轮播设置为：通过轮播配置功能完成轮播视频源、轮播顺序、轮播间隔的设置；

步骤3-4：进行视频点播操作；首先进行视频源设置，当前登录地点为控制中心时，选择列车的车载摄像机和全线所有车站的摄像机信息；若当前登录地点为某车站，那么前端只允许选择该车站的视频源信息；其次，视频播放宫格布局设置及播放宫格选择；最后，向视频请求代理服务程序VideoRequestAgentService发送信令请求，然后与其建立基于WebRTC协议的端到端的视频数据传输；

步骤3-5：启动一个快捷编组播配置项，该功能会根据宫格布局的设置信息，自动在用于视频播放的宫格播放所配置的所有视频源；

步骤3-6：启动一个轮播配置项，会根据所配置视频源及轮播顺序、轮播间隔在当前播放宫格中循环轮播；

步骤3-7：云台控制操作，根据摄像机类型是否为球机，判断是否可对选定摄像头进行云台操作；另外，在视频轮播模式下不允许视频云台控制操作；

步骤3-8：正在播放的视频的摄像机进行预置位读取、修改及重命名操作；

步骤3-9：停止其中一台冗余服务器上运行的视频请求代理服务程序VideoRequestAgentService，前端正在播放的视频此时会重新和备用的视频请求代理服务程序VideoRequestAgentService进行信令身份元数据的互认，然后建立基于WebRTC协议的端到端的视频数据传输。

Images